Acorn Level 4 Fileserver Issue 3

[philpem]

Cool, cheers - I have V2.12 up and running on the Arch running the demo version patched

The demo version, patched?

I didn't hit any demo version limits when I was trying it - I'm curious what you patched!

[dandoore]

The README says it's to upgrade L4FS Issue 3 -- if you try to upgrade v1.24, it crashes with an Address Exception on start up.

Just tried this on top of v1.30 and it works so I now have v1.33 up and working too

So it appears the versioning scheme is --

• Less than v1.20: Issue 1
• V1.20 to V1.29: Issue 2
• V1.30+: Issue 3

Looking at the readme of AdvL4S it says as part of the installation that it is a drag-and-drop-over replacement for L4FS as of November 1997, and the datestamp on V1.33 is Sept 1995 and for V1.30 December 1993, also the wording implies that at the time of writing in 1997 v1.33 was the last:

The old Acorn Level 4 Fileserver refers to versions up to 1.33. The Advanced Level 4 Server starts
at version 2.00

So that kind of suggests (to me anyway) that V1.33 was the last release before Acorns shift to AUN/Ethernet and that AdvL4FS was a last turn of the screw with Acorn giving over the source to Network Solutions to develop an upgrade if anyone wanted it, levering the Xemplar partnership to flog it to schools that hadn't migrated to RM Nimbus PC's

That would make it possibly:

• Less than v1.20: Issue 1
• V1.20 to V1.29: Issue 2
• V1.30 to V1.33: Issue 3
• V2.00 to V2.12: Advanced Level 4 Server

Dan.

[dandoore]

Cool, cheers - I have V2.12 up and running on the Arch running the demo version patched

The demo version, patched?

I didn't hit any demo version limits when I was trying it - I'm curious what you patched!

It was the Demo Version 2.11 from the Wayback you linked, with the update 2.12 also linked plopped over the top - it says 'Demo Version' for the serial on the info box so that's where I took it from

Dan.

[philpem]

Another idea reading some earlier posts...make sure the net number and station number of the file server is set correctly on the user station.

If the file server is station 123 do *FS 0.123 on the user station. Sometimes omitting the net number (0, meaning local net) can result in a junk number being set as the network number. For example if you do *FS 123 and read it back with just *FS it may say "File server is 47.123" or something like that.

I've got the fileserver set as 0.123 in the CMOS (*Configure FS 0.123) and that's what was popping up in the login screen too (after clicking the Net icon).

Also try logging on specifying net and station number of the file server - *I AM 0.123 SYST etc.

No difference

I'm not sure if there's a version of NetMon for 32-bit stations, using that will show the packets being transmitted and may pinpoint where the transmissions are being lost.

I found one that Phil Blundell wrote called "Quickmon" -- http://web.archive.org/web/200101050507 ... acorn.html. The source is on Github: https://github.com/philb/newmon -- apparently written with an assembler called "ARMMaker" which I can't find hide nor hair of. I ran Quickmon on the A3000 while the A4000 and Risc PC had a conversation...

This is with Level 4 FS 1.33 running on the RISC PC.

I've attached two logs:

"LOG.TXT" is in Quickmon's default log format -- any text it can find is displayed between 0x87/0x80 character pairs, while everything else is hex. It shows the A4000 connecting to the fileserver, opening the URD, opening the root ($), and trying to read !NetUtils.!Boot.

After the file data is sent from 123->10 (and before the 10->123 scout frame), there's a fairly long delay. Then the 10->123 scout frame is sent, followed by the rest of the file.

"LOGHEX.TXT" shows an attempt to copy !NetUtils.!Boot off the fileserver, entirely in hex. Same story as above, long delay followed by a blast of data.

Sadly my knowledge of Econet doesn't extend to the protocol level... so I have no idea how to analyse the trace.

I'm going to grab the Master 128 shortly and see if Acorn's Netmon shows any difference -- assuming I can get it to log to a file.

Cheers
Phil

[philpem]

Here's the output from Netmon... hopefully someone can see what's going on...

Code: Select all

>*NETMON
Econet Monitor 020

i
7B000A0080v99 0A007Bv00 7B000A002012030104052148656C70v0D 0A007Bv00 i
0A007B0080v20 7B000Av00 0A007B0000000146FFFFFFE08D2A577505000Cv00 7B000Av00 i
7B000A0080v99 0A007Bv00 7B000A00210603010401012148656C70v0D 0A007Bv00 i
0A007B0080v21 7B000Av00 0A007B000000v02 7B000Av00 i
7B000A0080v99 0A007Bv00 7B000A002212030104052148656C70v0D 0A007Bv00 i
0A007B0080v22 7B000Av00 0A007B0000000146FFFFFFE08D2A577505000Cv00 7B000Av00 i
7B000A0080v99 0A007Bv00 7B000A00230C03010402v01 0A007Bv00 i
0A007B0080v23 7B000Av00 0A007B0000007505v00 7B000Av00 i
7B000A0080v99 0A007Bv00 7B000A00240C03010402v02 0A007Bv00 i
0A007B0080v24 7B000Av00 0A007B0000000006v00 7B000Av00 i
7B000A0080v99 0A007Bv00 7B000A002512030104052148656C70v0D 0A007Bv00 i
0A007B0080v25 7B000Av00 0A007B0000000146FFFFFFE08D2A577505000Cv00 7B000Av00 i
7B000A0080v99 0A007Bv00 7B000A00260A27010402007505000000v00 0A007Bv00 i
0A007B0080v26 7B000Av00 0A007B0000v00 7B000Av00 i
0A007B0080v27 7B000Av00 0A007B00202020202020202020202020202020v73 7B000Av00 i

(long pause here)

7B000A0080v99 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
7B000A0080v99 0A007Bv00 7B000A002807030104v02 0A007Bv00 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v27 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v26 i
0A007B0080v28 7B000Av00 0A007B0000v00 7B000Av00 i
7B000A0080v99 0A007Bv00 7B000A002907030104v00 0A007Bv00 i
0A007B0080v29 7B000Av00 0A007B0000v00 7B000Av00 i

[BeebMaster]

From the Econet Advanced User Guide pp32-33:

The Netmon log looks to me like it is showing that the user station is correctly communicating with the file server on port &99, but the user station is asking the file server to respond on the wrong ports. The user station should ask the file server to reply on port &90, but it starts by asking for a reply on port &20, and increments till it gets to &27. As it's then opened 8 ports, it or the file server or both probably fall over.

The file server tries to transmit on port &27 repeatedly but gets no reply from the user station until the user station appears to recover and asks for a reply on port &28. Then the file server carries on with &27, then decreases to &26, until it finally transmits on port &28, the user station replies straight away and asks for the next reply on &29!

None of that should be happening, communication from user station to file server should be on port &99 and file server to user station on &90. So it's not clear whether it's a problem with the user station or the file server station. I think it's possible that the user station could request use of more than one port for file server replies, but it shouldn't be incrementing it every time.

If this sort of thing only happens when the RISC PC is the file server, maybe the data packet has been corrupted by the suspect Econet NIC by the time it appears on the Netmon screen.

One theory might be that somehow when receiving a data packet it shifts a bit left in the reply port byte and mucks up the number:
&90 = 1001 0000
Shift left by one bit and you have
(1) 0010 0000 = &20

That wouldn't really explain an increment each time though. Maybe it replaces the port number with a counter by mistake? I'm not quite sure how this could be done by the Econet NIC itself though, unless there's a bug in the ROM, which as we've speculated above, wouldn't really require the board to be returned to Acorn for repair, or a bug in the custom chip IC8, which might be more likely to need an Acorn repair.

[philpem]

One theory might be that somehow when receiving a data packet it shifts a bit left in the reply port byte and mucks up the number:
&90 = 1001 0000
Shift left by one bit and you have
(1) 0010 0000 = &20

That wouldn't really explain an increment each time though. Maybe it replaces the port number with a counter by mistake? I'm not quite sure how this could be done by the Econet NIC itself though, unless there's a bug in the ROM, which as we've speculated above, wouldn't really require the board to be returned to Acorn for repair, or a bug in the custom chip IC8, which might be more likely to need an Acorn repair.

That sounds almost like it's missing a clock pulse and losing sync...

Cheers
Phil.

[BeebMaster]

I'm not sure this is the answer after all. I've done some testing with NetMon.

Here's some communication between two Masters - Station 114 (&72) is the user station, 200 (&C8) the file server. Station 114 communicates with the file server on port &99, requests reply on port &90, and the file server duly replies on &90, all the way through. All completely normal.

Next we introduce the RISC PC, station 60 (&3C), as Level 4 file server. This machine has an Econet Module Podule. Station 114 communicates with the file server on port &99, requests reply on port &90, and the file server duly replies on &90, all the way through. All completely normal.

Now the RISC PC is the user Station and Station 200 is the file server.

Here the RISC PC communicates with file server on port 99 but requests an incrementing port number for the reply for every transaction. In this example it starts at &2C and goes to &31. The communication works fine as the file server replies on the requested port each time. In fact, the process begins at port &10, increments to &8F and then loops back to &10.

I haven't got another RISC OS machine here to test RISC OS <> RISC OS transactions, but looking at the earlier logs I think it's safe to assume that this is a feature of RISC OS stations; they like to use a different reply port for each transaction. It's still looking like the RISC PC file server can't cope with transmitting a reply on a different port each time, but I can't easily test that here at the moment.

[philpem]

Thinking about hardware issues...

I've attached the A3020/A4000 Econet Module schematic, from the A4000 document pack on Chris's Acorns.

So here's what we know.

• The issue seems to manifest when sending file data, but not when sending directory listings.
• It also manifests only when the Risc PC is sending data.
• Directory listing transfers are shorter than file data transfers.
• The Econet interface has a 74LS123 monostable (IC8) which generates two things: DCD/CTS from the incoming clock; and Driver Enable for the 26LS30 data driver.
• Comparing the part designators on the A3020 interface to the AEH60 (RISC PC) interface -- they're identical for any parts present on both interfaces. So Acorn probably used the A3020 interface as a base for the AEH60.

Continuing the thinking out loud...

• The LS123's driver enable 'half' is there for a simple reason: so that a single machine can't 'babble' forever and hang up the Econet due to a software crash. It'll time out after a while and have to wait for the monostable to reset.
• Going by the photos on Beebmaster's website (http://www.beebmaster.co.uk/32bit/RPCNet4.html) -- the 74LS123 chip has been replaced with a 74HCT123 on the RISC PC interface board.

My A4000 Econet plug-in module has a Motorola 74LS123 installed. The delay on that chip is...

Code: Select all

tw = K * Rext * Cext

tw: Timer in nanoseconds
Rext: Resistance in kilohms
Cext: Capacitance in picofarads

Constant "K" depends on the capacitor value, supply voltage and temperature. Suffice it to say, there's a wide variation between parts.

Transmit timeout and clock detect analysis

The On Semiconductor 72LS123 datasheet (https://www.onsemi.com/pub/Collateral/SN74LS122-D.PDF) doesn't give the value of K for a 47uF timing capacitor. The nearest estimate based on the curve is around 2.8 seconds.

Texas Instruments quote K=0.33 for C>1uF (in https://www.ti.com/lit/an/sdla006a/sdla006a.pdf), giving a time of 3.4 seconds. Correcting for capacitor effect on K (fig. 10), K ~= 0.36, which is around 3.7 seconds.

For the Nexperia 74HCT123 (https://assets.nexperia.com/documents/d ... HCT123.pdf), K=0.45. That gives us a max transmit time of around 4.7 seconds.

Flipping this around, the clock detect timer varies from ~39us (~25.9 kHz) on the 74HCT to ~30us (~33.3 kHz). So if you go much below 50kHz Econet clock, you're going to have a bad time (and not just because of the painfully slow data rate).

Further consideration

So if the transmit time isn't the issue, what is?

Nexperia's 74HCT123 datasheet gives us a hint:

3: The time to retrigger the monostable multivibrator depends on the values of REXT and CEXT. The output pulse width will only be extended when the time between the active-going edges of the trigger input pulses meets the minimum retrigger time. If CEXT>10 pF, the next formula (at VCC= 5.0 V) for the setup time of a retrigger pulse is valid (snip)

On Semi's 74LS123 datasheet is a little more succinct:

Retriggering of the part, as shown in Figure 3, must not occur before Cext is discharged or the retrigger pulse will not have any effect. The discharge time of Cext in nanoseconds is guaranteed to be less than 0.22 Cext (pF) and is typically0.05 Cext (pF)

Applying that formula gives a 330ms reset time, for Rext=220k and Cext=47uF.

For the OnSemi 74LS part, the reset time is around 10 milliseconds.

To put that in perspective: if two Econet packets are sent back-to-back with less than 330ms between them on an Econet adapter with a 74HCT123, the transmit time-out timer will fail to fully reset. This means the timeout will be shorter for the following packet.

If the host keeps sending packets with short delays, the constant failures to fully reset the timer could cause a transmit failure after around 5 seconds. The data transmit line driver (the 26LS30) will cut off mid-packet.

Homework -- your help needed!

Can anyone with a RISC PC Econet card please check what parts are fitted for --

• IC8 (74xx123)
• C3 (47uF tantalum)
• R5 (220k chip resistor)

It appears that BeebMaster's board has a Philips (now Nexperia) 74HCT123D fitted, while Chris Whytehead's had a Harris (now TI) 74HCT123.

Cheers,
Phil.

[BeebMaster]

Interesting...so it's looking like the change from 74LS123 to 74HCT123 on the RISC PC Econet card is causing a timing issue resulting in lost transmissions?

Meaning that mine possibly doesn't work properly (it's currently in the A7000 which isn't here)!

There's another thing I might be able to do. I have the prototype BeebMaster Econet Module which is all socketed, so I could replace the 74LS123 with a 74HCT123 and see if that stops the RISC PC working properly (by changing the module on the Econet Module Podule). Only I don't think I've got an HCT one.

[philpem]

Exactly that. After a stream of packets being exchanged, this happens:

• The RISC PC's babble timer runs out because it's not resetting properly. Leading to...
• The data bus idles to '1' mid-packet (thanks to the babble timer).
• 16 clocks later, the client's ADLC notices a surprising lack of stuffed zeroes, times out and flags an idle bus.
• The client times out the receive and (I assume) starts sending NAKs or scouts back to the fileserver. "Oi mate, I was talking to you! Hey!"
• the RISC PC tries to respond to the client's retry requests, but this only makes things worse by preventing the babble timer from resetting.
• Eventually the client gives up, the RISC PC settles down, CTS goes low (and stays low) and the timer finally resets.
• A few seconds later the RPC can talk again.

"Mister Anderson, what use is a phone call if you are unable to speak?"

I've just put in an RS order for some Hirose DF11 connectors for the A4, and chucked a couple of 74LS123s on there to pad it up to £30. When they turn up, I'll swap one in for my AEH60's HCT123. It can't make it any worse...

You might find a 74HC will do similar, but it seems like it's very brand-dependent. The 74xx123 chips are notorious for huge variations in timing value between manufacturer and logic series. They're about as bad as (or possibly worse than) 555s.

[BeebMaster]

Just looking at my A4 Econet interfaces...shocking pictures, and the original camera images from 2003 and 2009 aren't any better:

First one, serial number 322, clearly(ish) showing LS123 at IC2.



Second one, but earlier serial number 142. It's impossible to make out the part number of IC2, but could it be a replacement looking at the top row of legs? If we think we've discovered that the "mistake" with early RISC PC Econet NICs was to use an HCT instead of an LS, maybe Acorn made the same mistake with the A4?

[IanS]

There was a very specific note about not using HC123 in some econet document which described the "chatter disconnect" (Sorry, I don't remember which doc this excert came from, also think it's been badly OCR'd at some point)

[philpem]

IanS -- that's the A500 Hardware Guide from Chris Whytehead's website: http://chrisacorns.computinghistory.org ... wGuide.pdf

My RS order just arrived - so on my lunch break I whipped the Econet card out of the RISC PC.

Here's the offending Harris HCT123:

Replaced with a Texas Instruments 74LS123:

And here's my unnamed A4000 browsing the Level 4 server on the RISC PC:

I've just had it load ClearView and QTM (and several songs) off the SARPC quite happily. 200kHz Econet clock, rock stable.

FYI, Acorn glued the chips down to the board (they're wave soldered) so they're a bit harder than usual to swap. Once the chip warms up, though, the glue will let go.

I've kept the Harris HCT125 around for testing when I have a few minutes. Need to find some 47uF tantalum caps...

Back on topic for the thread (*grin*) -- I've tried Advanced Level 4 too, it works fine (with no config changes). Seems like support for MailMan was removed, though I expect many were using InterTalk or similar tools by that point.

BeebMaster -- I think you could be right about the A4 Econet card. I don't have one (wish I did!) -- were there issues on that too?

Cheers
Phil.

[BeebMaster]

It looks, then, like the "RISC PC Econet interface doesn't work in a file server" problem has been solved, and that Acorn knew about it for 8 years before the RPC came out!

As far I can recall, my own Econet NIC hasn't been used in a machine running the L4 file server, so as it also has the HCT 123, it probably wouldn't work. Possibly a workaround might be changing all the Econet timeouts using the SWI call?

Wild speculation on my part really on the A4, as I hadn't heard about this issue till this thread, and not being able to see the part number doesn't help. The circuit diagram gives it as 74LS123 though.

I'm still interested in why RISC OS stations use an incrementing reply port number for every transmission.

[richw]

Wow, well done chaps! Makes total sense why they had to modify mine.

Absolutely amazing that the A4 could have had the same issue. Mind you, would anyone even have tried to use an A4 as a server? Probably not.