Econet *I AM messages

[Winston]

I'm not entirely sure which forum I ought to be posting this in (it's either hardware or programming)...

Doing some tinkering with my RISC-V Econet project, and I've run into something a bit baffling. My system handles the *I AM logon command, looking at how it works on an emulated econet (using b-em and aund), when the client machine does an *I AM, first it sends an immediate machine peek to the server, then it sends the I AM command.

My stuff handles both of these (both the machine peek and I AM). I'm using ANFS 4.25 (loaded into sideways RAM on my BBC Master, I don't have a real ROM). When I ctrl-break, then do *I AM FOO on the Master, it will report "Station 254 not present" after a pause of a second or so. I've put some debugging code in on the other end to turn on an LED when it sees a machine peek, but it's not seeing anything.

However, if I then do *ADFS, then *NET (and literally nothing else), then do the *I AM, it works fine! Then *I AM continues to work fine until I do a Ctrl-Break, at which point we get back to the behaviour where it seems to do nothing but time out. Also, running a simple BASIC program to do a machine peek shows the machine peek is always working.

What also works fine (without the need to do *ADFS then *NET) is I implemented a command that just returns an error code - the full econet sequence happens with that and a message is displayed on the Master.

So my question is: is it expected that *I AM will send anything else that the server has to handle, other than the machine peek then the request?

[arg]

One thing that I believe it does - that you don't have to handle but the presence of it might possibly confuse you - is a bridge query to find what the current network number is. It's perfectly legitimate to have no bridge and just local net of zero, but those packets should be there on the net.

Do you have anything to run a net monitor? If you've only got the one BBC, then writing one to run on your hardware may be profitable.

[jgharston]

Are you sending the correct response to the I AM request? The client could be getting confused if the reply is wrong.

Have you tried manually including the server address in the I AM command? ie: *I AM 0.254 FRED to bypass the client's defaults. You say you're using ANFS 4.25, so you're using a Master - if this fixes the problem it is likely the NVRAM FS configuration is wrong. Something people do *CONFIGURE FS 254 when you actually should do *CONFIGURE FS 0.254 - ie a fully qualified address.

Do you have a BBC you can test with NFS 3.xx, it doesn't preface an I AM with a NetPeek, so that would eliminate that part of the issue.

Can you get any debugging messages from your server? Almost all servers are capable of spewing out huge amounts of useful material, you want to be able to see something like:
0.020>0.254 *I AM FRED
0.254>0.020 Logon &03,&01,&02,&04
0.020>0.254 Openin !BOOT
0.254>0.020 Open not found

etc... Also, another machine with a verbose netmonitor is often crucial for debugging client-server transactions, as it will show the low-level network traffic. My preference is SJMon (I stopped writing my own version when I got hold of a copy).

[Winston]

> Are you sending the correct response to the I AM request? The client could be getting confused if the reply is wrong.

I'm not even getting that far! I've put some debug printfs in the code (and a debug LED turn on in the driver code too, which turns the LED on when a machine peek is received) and I'm not getting anything at all.

Unfortunately I've only got the two stations (I wonder if anyone can sell me the econet kit needed for my BBC Micro when I go to the LAN party at Bletchley, so I can have another station). At the moment I'm trying to avoid the ballache of hooking up my logic analyser to the line drivers on my project board which is currently the only way I can see what's going on (decoding the serial data by hand!) - although I've got some PCBs on the way for my project so I can build a couple of boards and use one just for monitoring when my order comes back from PCBWay. Which is probably going to be essential when I get deeper into NetFS territory.

My project currently does not do anything with broadcast messages by the way except ignoring them.

On the BBC Master end, this is what it looks like - see how it starts working if I just do *ADFS then *NET.

This behaviour by the way returns any time I do a Ctrl-Break and try another *I AM, so I'm assuming it's transmitting something I don't handle and expecting some kind of response...although it does seem a bit odd that doing *ADFS/*NET then seems to make it start working.

[cr12925]

The “not present” means it got no reply to the MachinePeek immediate request. Had that succeeded and some part of the 4-way logon request had not come back you’d get “not listening” (no scout ack) or “net error” (no final ack received).

So this is falling at the first hurdle.

@arg is spot on that the m128 will spit out a bunch if pirt &9c WhatNet queries on break. NFS3 doesn’t.

Possible clock/termination issue?

Do you have an oscilloscope? Stick it on data+ and gnd on the network and see what’s going out on the wire maybe? I’ve spent too many hours doing that

(Shameless plug alert) The PiEconetBridge might be worth a look - and it has a built in L3-ish fileserver. https://guthub.com/cr12925 - and @KenLowe on here can sell you both the required HAT and differently presented but identical board which is effectively an ADF10 clone. He also has Econet hubs…

Best

C

[awilliams]

While we are on shameless plugs.. or at least open source NetFS servers.

I uploaded a listing to !awServer a Filestore 1.23 ish NetFS server in BASIC a short while ago.

https://www.stardot.org.uk/forums/viewt ... er#p420527

Natively its Archimedes BBC BASIC, but now you have me wondering if it could conceptually work on the BASIC in the RISC V emulated 2nd processor in pi tube direct, if it had all its SWI calls replaced by whatever mechanisms it has to call the BEEB OS.

For reference source that I know of, in roughly historical order there is my BASIC one, AUND (ARM clients only), the Arduino one, and the PiEconetBridge one. SoftMDFS is a fork of mine, supporting Atom clients and presents the user with more SJ like commands.

I have been thinking we should make a list with platforms, features & downloads links etc.

Alan

[BeebMaster]

It's an interesting problem, I'm not entirely sure why changing filing systems would resolve a "Station xxx not present" error. The only thing I can think is that, as JGH mentions, the configured station number includes a network number other than 0, so it's looking for Station 254 on a different network, and somehow leaving (A)NFS and coming back again resets the network number to zero.

I think we need to see the result of *STATUS FS (to show the configured file server number) and also a log on attempt where *FS (to report the current file server number) is done after the Station not present error, and again after the *NET.

Is it only ADFS which resolves the problem, or other filing systems (DISC/TAPE/ROM etc)? Or even just doing a *NET whilst already in Net, or forcing Net using service call 18 (*FX143,18,5)?

I suppose it's possible there is a glitch in the ANFS ROM image being used, can it be checked against a known good image?

[BeebMaster]

Configuring the file server number with a non-zero network number always gives the network number in the Station not present error, so I don't think it's a configuration problem.

There is some weirdness with ANFS and network numbers, there was a discussion on here a while back where people were having difficulty referring to different networks on Masters which wasn't happening on BBC B. It's also referred to, a bit obliquely, in the SJ MDFS manual. I will try to dig out the details.

Other than that I wonder if something else in the machine, or the initial exchange of packets resulting in the apparent lack of response from the file server itself, might be corrupting the ANFS workspace which gets refreshed when Net is re-selected?

[Winston]

The “not present” means it got no reply to the MachinePeek immediate request. Had that succeeded and some part of the 4-way logon request had not come back you’d get “not listening” (no scout ack) or “net error” (no final ack received).

So this is falling at the first hurdle.

[...]

Possible clock/termination issue?

The clock/termination should be fine, I have an external clock (the one based on an AVR microcontroller, I don't remember where I got it but it seems to work reliably) plus genuine SJ Research terminators. I can have a BBC BASIC transmit program (the one out of the econet advanced user guide) run in a loop forever firing off messages, and I receive all of them correctly. I also wrote a program to do a MachinePeek in BASIC and thiis reliably works right from the get go. And I can run my machine peek program, and it succeeds, then try the *I AM straight afterwards, and it fails with "Station 254 not present" even though I've demonstrated that the MachinePeek works!

The RGB LED on my board should turn red when a MachinePeek packet is received, but it doesn't - well, not until I do *ADFS/*NET on the Master and try again. (The caveat here is my implementation does some of the econet frame decoding in hardware, it doesn't raise a CPU interrupt unless the frame is addressed to us and the CRC passes. As such broadcast messages just get ignored at the moment. At some point I need to implement a monitoring mode where it interrupts on all frames, but that doesn't yet exist. This is all implemented in a Lattice up5k FPGA. I don't think the state machine is getting in some weird state because I can run the MachinePeek program or the Transmit program immediately after the *I AM fails, and these all work correctly).

I probably ought to hook up my logic analyser to the test point on the board I provided for this purpose and see what is on the wire (although this does mean manually decoding the bitstream...)

[cr12925]

I probably ought to hook up my logic analyser to the test point on the board I provided for this purpose and see what is on the wire (although this does mean manually decoding the bitstream...)

Welcome to my world

Sounds like the M128 might have something odd wrong with it?

C

[arg]

The clock/termination should be fine, I have an external clock (the one based on an AVR microcontroller, I don't remember where I got it but it seems to work reliably) plus genuine SJ Research terminators.

While it's almost certainly not your problem, that combo is NOT fine at all! The AVR driving the clock without a line driver chip (if it is indeed that one) is an abomination, and the SJ terminators require a clock which applies a DC bias to the clock signal (so even AVR+driver won't be satisfactory unless designed for this purpose with an 8V power rail).

The caveat here is my implementation does some of the econet frame decoding in hardware, it doesn't raise a CPU interrupt unless the frame is addressed to us and the CRC passes. As such broadcast messages just get ignored at the moment.

Much more likely some problem in this area. Aside from the HDLC frames, the presence/absence of line idle and the turn-around sequence between frames is critical with Econet and hard to get right on non-original hardware.

Getting a network monitor is really the only way to debug this - you want to see what other stations are viewing as the activity on the line, which may not be obvious from your internal measurement. I could potentially lend you one of my RP2040 boards if you are desperate (goes in the post more easily than a BBC, but not quite as authentic).

[Winston]

The caveat here is my implementation does some of the econet frame decoding in hardware, it doesn't raise a CPU interrupt unless the frame is addressed to us and the CRC passes. As such broadcast messages just get ignored at the moment.

Much more likely some problem in this area. Aside from the HDLC frames, the presence/absence of line idle and the turn-around sequence between frames is critical with Econet and hard to get right on non-original hardware.

For the avoidance of doubt, line idle and turnaround timings are (at least attempted - it's more than possible I've got it wrong) to be respected, the hardware itself doesn't ignore frames not for us (or that failed CRC), it just doesn't bother the CPU about frames that aren't for us (or failed CRC)

As for the clock, I'll have to take the lid off to see what's inside, but I would bet it's the bare AVR. Perhaps once I've replaced the diodes with the correct ones in the termination circuit, I'll just use the software-enabled clock on my board, which has a line driver (I've used your econet front end verbatim).