New Econet device

discuss both original and modern hardware for the bbc micro/electron
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

New Econet device

Post by arg »

Looks like a piece of classic Econet hardware:
sktbox2.jpg
Except it's got a USB socket on the side...
bbc.jpg
And it's alive!
philb
Posts: 725
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: New Econet device

Post by philb »

Very nice!
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: New Econet device

Post by arg »

Here's what's inside:
top2.jpg
bot2.jpg
HDLC (flag framing, bit stuffing) done by the PIO machine in the RP2040; rest done conventionally in software.

Programming that PIO with its limit of 32 instructions gives you the real 8-bit experience of squeezing your code and rewriting and it still doesn't fit and re-do it another way and it just fits and then you need another instruction to fix a problem....

Circuit is just the classic LM319/75159 Econet circuit connected to pins on the Pico in place of a 6854, though I've also slipped in a switchable terminator (and used the spare half of the 75159 for an optional clock).
Coeus
Posts: 2250
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: New Econet device

Post by Coeus »

Very nice.
User avatar
danielj
Posts: 8752
Joined: Thu Oct 02, 2008 5:51 pm
Location: Manchester
Contact:

Re: New Econet device

Post by danielj »

Tidy! :)
stevebubs
Posts: 83
Joined: Thu Mar 09, 2017 1:01 am
Location: Berks
Contact:

Re: New Econet device

Post by stevebubs »

Nice...very nice! presumably the USB is for storage?

Any consideration to sticking an Ethernet / Wifi module onboard (or connected via USB) and maybe using a Windows / NFS share?
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: New Econet device

Post by arg »

There's a SDcard socket for local storage (though I haven't tried it yet). USB is intended for connecting to a PC (and also supplies power).

Current state of play is that I've written the HDLC/framing/CRC/line-turnaround layer, with an API to higher layers intended to support bridging as well as local processing; that bit is 'finished'. Then on top of that is a flaky local-RxCB layer for testing; this needs re-writing once I've figured out the right process/interrupt structure; I'm currently trying to work out how the Pico's USB device stack (TinyUSB) works so that it can all fit together. My aim is that the bottom hardware layer can then support combinations of:
  • Local RxCBs - being a station in its own right.
  • PC apps able to act as an Econet station (eg. existing stuff I have that used to work with the PC Econet card). This is my initial goal, and could be implemented as just an API over the USB link for the PC to set up RxCBs within the Pico, except that it could be subsumed within the next item.
  • Bridging up the USB link to virtual econet on the PC. Not sure how good the performance is going to be (USB latency), but if it's not too bad this covers the native PC apps too.
  • Bridging to internal emulated devices.
  • Bridging to other physical Econets (the Pico can support multiple PIO instances, though obviously not on this board unless I do a butterfly assembly of one Pico on two of my current PCBs)
Things that this board could do (not necessarily going to do all of these myself):
  • As above, PC RxCB/TxCB API via USB so that this just acts as an Econet interface. Unlocks fileserver to serve the PC's filesystems, BBCtermD for BBCs as terminals to unix (telnet-style) etc.
  • Bridging to virtual Econet within the connected PC. This is the holy grail - emulated machines on the PC able to act as real Econet stations on physical Econet.
  • Fileserver using SDcard - either a new native one or Z80 emulation to run a real MDFS binary (there's just enough RAM). Or no doubt you could do 6502 emulation to run FileSnore code if you wanted to (I don't!).
  • Dynamic clock rate. The very last SJ bridges did a very crude version of this - they could speed up the clock when talking to one specific station. But you could go much further - set the clock rate based on source and destination, so Archimedes and BBCs could mix on the same network without having to push the clock rate right down.
  • Immediate ops - this code supports immediate ops, unlike the classic PC cards. Should be able to PEEK and POKE the Pico itself
    for debug. Likewise *REMOTE or *VIEW a BBC from the PC, and PEEK a BBC or Arc for remote debugging.

Things that might be interesting to do with the Pico Econet with different hardware (again, I'm not planning to do all this myself, but happy to collaborate with others who fancy giving any of them a shot):
  • Replacement module for Master/Arc. The Pico is not much bigger than a 68B54, so would easily fit if you did the rest in SMT (even though
    it will require a couple of level converters for the 5V bus). It would be hard work to provide a cycle-accurate 6854 emulation, but there's
    no real point in going to that level. It would be straightforward to do one that directly ties the emulated 6854 to events on the Econet
    and so would be indistinguishable from the real thing in actual use. Alternatively, you could write one less tightly coupled that also
    bridges in traffic from the USB port. This would drop a little bit of performance in the BBC/ARC<->Econet case due to added delay, but
    give a lot of extra flexibility (and you could probably run a higher Econet clock speed to offset the performance loss). The PCB could even have a footprint with the signals on 6854 pinout so you could use it to upgrade a BBC-B rather than fitting all the Econet components.
  • Econet<->USB in a DIN plug? Once naked RP2040 chips become available rather than having to buy the Pico module, I think it should just about be possible to squeeze the whole thing into a DIN plug so you could have a cable with USB on one end and Econet on the other. Obviously requires moving away from the classic 75159/LM319 Econet circuit; this is easy for Tx/Rx and I have ideas for ways to do miniaturised collision detect.
  • The Pico PIO unit supports 4 instances of the HDLC logic, so it would be possible to build a 4-way bridge (or 8-way if you use both
    PIOs, though you run out of pins). Not sure what you would use such a beast for nowadays, though. Econet switching rather than CSMA/CD?
  • Cuthrough bridge? Classic bridges are always store-and-forward, so halving performance for transfers via the bridge. In principle, if you
    know that the two clocks are the same (or you know the relative speeds), you can start transmitting the packet on the other side before it has finished reception, so cutting out most of the performance loss. Clock speeds are easily measured on the Pico setup where Econet clock feeds a PWM unit in counter mode. I have written the low-level frame handling to facilitate partial frame handling, as the same issue arises to avoid latency up the USB link.
  • Naked Pico? While I wouldn't countenance using ordinary logic output pins like those on the Pico to drive a full Econet (I consider the WFF
    clock objectionable), to connect just a single machine over a couple of centimetres of cable and no termination it may be plausible.
    Drive only D+ and CLK+ (leaving the -ve open or might need to be biassed with a reisistor), couple of resistors on the D+ to limit the voltage
    and it would probably work. I'd still prefer to do it properly (ie. some actual line drivers) for regular use.
  • Ethernet? It would be easy enough to strap something like a W5500 on the side for Ethernet, but PhilB already has a project on the go to do Econet<->Ethernet and it's not clear that this would offer any advantage. Some scope to share code maybe?
Last edited by arg on Sat May 29, 2021 9:18 pm, edited 1 time in total.
User avatar
jgharston
Posts: 4458
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: New Econet device

Post by jgharston »

stevebubs wrote:
Fri May 28, 2021 11:30 am
Nice...very nice! presumably the USB is for storage?
It should be for whatever networking you want to do, not just for connecting to a file server. A file server is just one specific system communicated over via a network, you shouldn't be designing a network system to refuse to do anything other than connect to one specific application thought of beforehand, killing off the future. Yes, Amcom, I'm talking about you. A network device should just pass whatever networking packets the clients connected to it send on to other clients.

You should be able to *NOTIFY clients over the network, not because the network device supports *NOTIFY, but because the network device passes on the network packets that the NOTIFY program sends data in - and any other program that choses to send such packets, regardless of whether they are a NOTIFY program or not. You should be able to *TALK to other clients, not because the network device knows what *TALK is, but because it just purely and simply passes on the packets that *TALK chooses at startup to use to send data to other clients.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
jgharston
Posts: 4458
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: New Econet device

Post by jgharston »

[*]Bridging to virtual Econet within the connected PC. This is the holy grail - emulated machines on the PC able to act as real Econet stations on physical Econet.
That is the true holy grail. Being able to use my Windows PC and *I AM JGH into my MDFS. :)

(Edit: I think I'm drooling :D )
[*]Immediate ops - this code supports immediate ops, unlike the classic PC cards. Should be able to PEEK and POKE the Pico itself for debug. Likewise *REMOTE or *VIEW a BBC from the PC, and PEEK a BBC or Arc for remote debugging.
You'll need a machine ID allocation to respond to MachineType. The convention is b8-b15 is the "manufacturer" type, we've got &00=Acorn, &01=Torch, &02=Reuters, &10=JGH, &50 'P'=Philip Blundell, &FF=SJ Research. I'd recommend picking the ascii code of one of your initials, eg &41 'A', &52 'R', &47 'G'.

The low byte happens to have ended up as non-overlapping values, I don't know if that's be design or accident, but it makes MachineType to human readable name translation easier. So avoid &0x, &1x, &4x, &5x, &Fx.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: New Econet device

Post by arg »

jgharston wrote:
Fri May 28, 2021 7:08 pm

You'll need a machine ID allocation to respond to MachineType. The convention is b8-b15 is the "manufacturer" type, we've got &00=Acorn, &01=Torch, &02=Reuters, &10=JGH, &50 'P'=Philip Blundell, &FF=SJ Research. I'd recommend picking the ascii code of one of your initials, eg &41 'A', &52 'R', &47 'G'.

The low byte happens to have ended up as non-overlapping values, I don't know if that's be design or accident, but it makes MachineType to human readable name translation easier. So avoid &0x, &1x, &4x, &5x, &Fx.
I'm considering it to be an SJ Research product for this purpose, so at present have taken the next lower value (0xff, 0xf7), though conceivably this should vary depending what software is loaded (indeed, if there's no local service and it's only acting as a bridge then it can't respond to MCpeek at all as there's no local station number).
philb
Posts: 725
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: New Econet device

Post by philb »

arg wrote:
Fri May 28, 2021 7:33 pm
I'm considering it to be an SJ Research product for this purpose
Given that it literally says "SJ Research" on the box, I think that's fair :D
User avatar
jgharston
Posts: 4458
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: New Econet device

Post by jgharston »

arg wrote:
Fri May 28, 2021 7:33 pm
I'm considering it to be an SJ Research product for this purpose, so at present have taken the next lower value (0xff, 0xf7), though conceivably this should vary depending what software is loaded (indeed, if there's no local service and it's only acting as a bridge then it can't respond to MCpeek at all as there's no local station number).
A bridge or gateway doesn't need to not have a station number. The Acorn Econet/Ethernet Gateway ran on a normal RISC OS client machine, so would have a network number on each side of the network. And, from memory, anything on the Ethernet side has to have a station number anyway. (I still remember at AFE it was 2.236 on one side and 3.236 on the other.)

From memory Paul Fellows mentioned testing the NetFS file server protocols by having a machine snooping the network and grabbing packets sent to &xxFE instead of to itself, displaying debug messages and then sending them onwards to some other client with the file server running on it. I wrote a "SerialNet" gateway that does similar, grabbing packets addressed to &7xxx and forwarding them over the serial port.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
awilliams
Posts: 70
Joined: Sun Feb 22, 2015 10:51 am
Location: Adelaide, Australia
Contact:

Re: New Econet device

Post by awilliams »

Arg,
that's fabulous!

I will immediately stop trying to invent that wheel myself as I really hadn't got much further than laying out the breadboard and working out that no way in hell would the PIO have the resources to do address matching or CRC.

Image

I was trying a couple of SN75176 RS485 line driver receivers rather than bothering with the whole LM319 rigmarole.

I guess its early days yet but are you intending to make the source available?, It would be interesting to test it in my more minimal hardware but also I have some FS code written in 'C' which I started long ago after !awServer, which I was intending to port.

I was intrigued by the idea of running a z80 emulator and MDFS code. I have another project about as far advanced as my attempt at this, ie nowhere, which is a TinyFPGA BX and the same SN75176 (I have a tube of them for no good reason, I have a tube of 75159s too but they only do half the job). I was hoping to run a 6502 core in it with the Ecolink code adapted for USB DMA & thus avoid much of the pain of having to implement Econet protocols again for a USB-Econet interface but your work is looking much more promising for that too.

I was LOL at your reference to FileSnores mine have been snoring for the last 15 years, Inspired by Philb in another thread I am trying to get them working again but all my Rodime drives are now finally dead so I was distracted from from pico econet by the idea of using a pico+sd card on the Filestore bus (internal to EO1).

Anyway I am watching this space with keen interest & would be very interested in testing the code on my breadboard version.

A truly outstanding effort.

Alan
Attachments
Screen Shot 2021-06-09 at 5.47.09 pm.png
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: New Econet device

Post by arg »

awilliams wrote:
Wed Jun 09, 2021 9:22 am

I was trying a couple of SN75176 RS485 line driver receivers rather than bothering with the whole LM319 rigmarole.
Yes, I think my next attempt will use MAX3061E (which is much better than the 75176 or the many equivalents, as it has much higher impedance and so permits up to 256 devices on the bus, while the 75176 etc are only rated for 32). There's then the question of how to do collision detect - I think it can be done cheaply with an INA381 current sense in the power pin of the line driver; it may need to be calibrated according to the termination on the particular Econet, but the Pico can easily do that on startup (set a PWM output for the level) and then it just has a binary collision detect equivalent to the LM319 version.

However, for this first version I went with the classic circuit.
I guess its early days yet but are you intending to make the source available?, It would be interesting to test it in my more minimal hardware but also I have some FS code written in 'C' which I started long ago after !awServer, which I was intending to port.
Absolutely, though I was wanting to get just a little further before inviting people to have at it.
I was LOL at your reference to FileSnores mine have been snoring for the last 15 years, Inspired by Philb in another thread I am trying to get them working again but all my Rodime drives are now finally dead so I was distracted from from pico econet by the idea of using a pico+sd card on the Filestore bus (internal to EO1).
I took a quick look at the available SCSI replacements (SCSI2SD, BlueSCSI, RASCSI) and found them all wanting (SCSI2SD closed source, BlueSCSI drives the SCSI bus with GPIO pins that are beyond rated load with one SCSI termination and don't work at all with a properly terminated bus, RASCSI looks good but the hardware doesn't support arbitration which means it can't do disconnect/reconnect which means it can't emulate MDFS tape drives).

So I was doodling a Pico->SCSI as well (having got into a mood where all problems look Pico-shaped!), but I think I need to get this first one out of the door first.
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: New Econet device

Post by arg »

awilliams wrote:
Wed Jun 09, 2021 9:22 am
no way in hell would the PIO have the resources to do address matching or CRC.
CRC is a bit irritating. RP2040 does have a hardware CRC unit, but only one, built into the DMA - so it can accumulate the CRC 'on the way past' as it loads data into the PIO (for example).

For Econet, this would work well for Tx - you could DMA all the data (in multiple chunks if necessary, eg. for header vs body) then at end of packet just pull the last 2 bytes out of the CRC unit. For Rx it's not so good as you don't know the packet length in advance; in my architecture, the values coming out of the PIO have high bits set to show flag/idle conditions so if you accidentally suck one of those into the DMA your CRC is rubbish. Conceivably I could signal the trailing flag in some other way so that software could abort the DMA at that point, but it's not easy: initially I was signalling idle via the PIO interrupt, but it was too hard to keep synchronisation between events in the data stream in the FIFO vs asynchronous interrupts - unless you assume the CPU interrupt response is blindingly fast, but if you assume that your CPU can't be working very hard, so why are you bothering to optimise things with DMA?

Also an issue that having finally squeezed the PIO code to only need one PIO instance and hence have the possibility to run more than one Econet engine at once (ie. mutiple interfaces for bridging), it seems a shame to throw that away and use a CRC scheme that can only support one instance.

Another possibility would be to do the CRCs in 'batch mode' - ie. at the point where the packet is sitting in memory, before Tx or after Rx - but it's not clear this is really an optimisation, especially if you end up with the CPU hanging around waiting for the DMA to complete.

So at the moment I don't use DMA at all and do the CRC in software 'on the fly' while reading/writing the FIFOs. Adding DMA and auto-CRC for Tx (only) is a possible future enhancement, though probably not really worth the bother.
wiggy
Posts: 97
Joined: Fri Feb 12, 2021 12:19 pm
Contact:

Re: New Econet device

Post by wiggy »

arg wrote:
Wed Jun 09, 2021 9:48 am

Yes, I think my next attempt will use MAX3061E (which is much better than the 75176 or the many equivalents, as it has much higher impedance and so permits up to 256 devices on the bus, while the 75176 etc are only rated for 32). There's then the question of how to do collision detect - I think it can be done cheaply with an INA381 current sense in the power pin of the line driver....
There are a few line drivers around which have something very similar built in - They're a bit hard to work out what the different manufacturers call them, but one such is the LTC1482 - unfortunately that's also a full-load device (32 on the bus), but it's got the right idea (and the modern high-ESD protection, too).

The current-sense idea is a neat one (you'll probably find that using, say, a BCM856BS matched-pair as a current mirror is cheaper), but I have a nasty feeling that the current draw from a fully-loaded (i.e. 32 full-load receivers) properly terminated bus is much the same as that from a contended bus (you'll likely be into the drivers' current-limiting), particularly if the contention is only one some bits - you might be looking to need a peak detector with a carefully determined time constant to be able to distinguish between an edge and a bit....

I'm not going to promise, but I might see what I've got in the junk box and can lash up later on....
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: New Econet device

Post by arg »

wiggy wrote:
Wed Jun 09, 2021 10:56 am
(you'll probably find that using, say, a BCM856BS matched-pair as a current mirror is cheaper)
You are probably right, but the INA381 isn't expensive and you also get a comparator for your money - unlike some competitors, the RP2040 has neither an analogue comparator, nor a digital threshold mode in the ADC. You could just run the ADC flat out and process all the results with the CPU, but that feels a bit wasteful - though you only need collision detect during the scout packet so it could probably be made to work without totally compromising the overall system.
, but I have a nasty feeling that the current draw from a fully-loaded (i.e. 32 full-load receivers) properly terminated bus is much the same as that from a contended bus (you'll likely be into the drivers' current-limiting), particularly if the contention is only one some bits - you might be looking to need a peak detector with a carefully determined time constant to be able to distinguish between an edge and a bit....
I was resigned to having to calibrate for the amount of load/termination on the bus (though with a faint hope it might not be necessary), but that should be fairly constant so a calibrate-on-startup should suffice (and repeat the calibration if you suddenly start getting loads of collisions). There will need to be some edge-limiting to smear the edges over a bit time or so; hopefully that can be just a fixed capacitor.

So I'm not completely sure it's going to work, but it feels like it's got a reasonable chance (and of course the original circuit probably doesn't work 100% across all these different scenarios). The most likely failure mode (for both this and the original) I suspect is simply failing to detect the collision at all when there's lots of cable resistance and the stations far apart.

Fortunately there's not too much issue of compatibility between this and the classic collision detect - you only need to detect your own collisions (ie. when you are transmitting), so it doesn't matter what the detector on receiving stations does, and that at transmitting stations are going to be primarily affected by their own drivers. There will be a problem (even sticking to the classic circuit on the new design) if a newly-chosen driver has radically different current limit under contention - just possible the switch to a 3V-supply driver will spoil things here.

Lots of research needed....
awilliams
Posts: 70
Joined: Sun Feb 22, 2015 10:51 am
Location: Adelaide, Australia
Contact:

Re: New Econet device

Post by awilliams »

I am more than happy to be flamed at this point but I have come to the view regarding collision detection that its not worth the effort of bothering at all for most modern use cases.

I have at most, including a bridge, eight currently operational devices with Econet interfaces but its rare that any more than two are on at any time.

A collision detection circuit is going to detect a collision marginally earlier than the CRC error will. Given that 50% of all transmissions are to the fileserver and thus have the same destination and port numbers two stations simultaneously transmitting are not going to generate a signal state detectable as a collision until over three bytes into the scout. If it was stations 1 and 2 then very nearly four bytes into the scout, and it might be 6 bytes to the end of the closing flag. So the collision detection circuit is going to save you six bytes a collision over having to detect it with the CRC. On a flat out network maybe you get on collision a second.
Maybe the stack detects and retries marginally faster with the collision detection signal than it will on a CRC error and a time out, but still its a lot of messing about for an event that's going to be about as rare as hens teeth on most remaining Econets.

Granted all later Acorn implementations, the BEEB and the System4/5 did have collision detection circuit but I have a an original Acorn ADF 10 module and a South Australian clone of it, hundreds of which would have been used here that do not have that circuit at all. I don't remember anybody ever complaining that collisions were a problem.

Anyway I am happy to be proven wrong but I think for modern use cases its a case of severely diminishing returns.
wiggy
Posts: 97
Joined: Fri Feb 12, 2021 12:19 pm
Contact:

Re: New Econet device

Post by wiggy »

awilliams wrote:
Wed Jun 09, 2021 2:01 pm
two stations simultaneously transmitting ...
The bug in your maths is that two stations simultaneously transmitting are unlikely to be also synchronised. (Obviously the bit periods are aligned, but it's rather less likely that the bytes align). Thus you would expect to trip the collision detect somewhere during the flag "byte" (at least during that of the second station to attempt a transmit).

That said, yes the CRC test is the fallback, so a partially-effective collision detect should still be better than none. And, yes, if you only ever have a couple of stations on at any time then you're unlikely to see anything anyway.

Does anybody have a definitive list of what prefers/needs/doesn't care about collision detect? I know it's fitted on the Model B, optional on the B+ and completely missing on the Bridge... but I seem to recall the manuals saying it depends more on the software being used?
philb
Posts: 725
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: New Econet device

Post by philb »

wiggy wrote:
Wed Jun 09, 2021 2:56 pm
Does anybody have a definitive list of what prefers/needs/doesn't care about collision detect? I know it's fitted on the Model B, optional on the B+ and completely missing on the Bridge... but I seem to recall the manuals saying it depends more on the software being used?
I don't think the software particularly cares, at least on 68B54-based platforms. The collision detect circuit deasserts CTS# to the ADLC when it senses bad data, and the software will notice that this has happened. But if the collision detect comparators aren't there, the ADLC just always sees CTS# valid all the time and as far as the software is concerned everything is good.

I have a dim recollection that Brian Robertson deleted the collision detect on the Master modules to save a bit of component cost and the early ones shipped without it (in fact I have one sitting next to me at the moment) but it was added back in fairly soon thereafter because big networks turned out to not be reliable enough without that circuitry. That's not to say the reliability couldn't have been fixed in software of course.

I think one point that is possibly missing from Alan's analysis is that if you have collision detect then the transmitting station knows it has collided and it should back off and retry. The CRC check allows the receiver to tell that the frame was bad, but the transmitter has no way of knowing that anything went wrong so you're then dependent on just the normal upper-level protocol retries.
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: New Econet device

Post by arg »

Broadcasts are the main justification for retaining collision detect.

If you don't have CD, then broadcasts are much less reliable: in the absence of collision, they are pretty reliable (general error rate due to noise etc is low), but a collision means it's not received and if you don't know that it's happened you don't know to do extra retries.

Separately, there is an issue for modern implementations about what you should do for collision arbitration (regardless of whether you have CD hardware, you should do CA after any failed scout Tx) - it's supposed to be a delay proportional to station number before retrying. However, that delay is not well specified and (looking at the source code) not currently very consistent between different implementations. So it's fine for the common case of homogeneous machines bashing the fileserver, not so good with lots of new implementations that do it differently (and I think on BBC micro it's worse than that because the OSWORD call doesn't do retries, so you've got the arbitrary loop delay in the calling application).

I have been starting to collect data on this and other dirty secrets of Econet implementation as I come across them; this document is meant to be a manifesto for interoperation of various new stuff: the main part of it isn't written yet, but the annex on BBC implementation contains quite a lot of detail now:

https://docs.google.com/document/d/1Bd1 ... sp=sharing
wiggy
Posts: 97
Joined: Fri Feb 12, 2021 12:19 pm
Contact:

Re: New Econet device

Post by wiggy »

That makes sense.

I've finally tracked down the paragraph I was thinking of, which is in the B+ Service manual (in the Econet upgrade instructions, Part 2 para 6.3):
IMPORTANT NOTE: Collision detect circuitry is not included in the model B+ ECONET upgrade. It has been found, following exhaustive tests, that this feature is not required when a BBC Microcomputer is operating within an ACORN ECONET environment. However, it may be required where an ECONET machine is used with equipment which does not include the ACORN NFS software and provision is made for this circuitry to be fitted to the PCB. See below.
... and yes, the basic NFS Filing System doesn't really do broadcasts - at least not for the core operation.

(on the way to finding that, I noted that there's a bit of write-up of this in the document that starts with the ISO/OSI layer mapping that ties up rather well with Alan's analysis, although this was as the "you don't need collision detect" stage, before the "oops, we need to put it back again" point)
philb
Posts: 725
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: New Econet device

Post by philb »

Here's the Master module with no CD that I had on my desk. It must be quite early because it's labelled "B Econet", although it also seems to be at issue 2 so it can't be all that early!
IMG_20210609_201316.jpg
User avatar
arg
Posts: 267
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: New Econet device

Post by arg »

I wonder how many B+ actually had CD vs not. I've a suspicion early production had it (or perhaps early production was mostly with no econet at all and people were just fitting the upgrade kit from the model B (since circuit on the PCB didn't change).

Certainly I don't remember becoming aware of this change until the master interfaces came out (but probably we upgraded our B+ ourselves).

The first version of this cost reduction exercise not only scrapped the collision detect, but also replaced the two LM319-based receivers by an AM26LS34 standard RS485 line receiver - papering over the issue that these only supported 32 devices per bus by optimistically inserting 12K resistors in series with the receiver inputs and hoping this didn't affect the performance too much. Unfortunately the bridge went to production with this abomination; my memory says that the very earliest Master interfaces were the same (though they might only have been prototypes).

So the Master fairly soon got changed, but the bridge remained without CD until production was taken over by SJ about 5 years later - when the new version bridge went back to the classic LM319 circuit including CD.

Aha - just seen Phil's photo. That one is "ISS2", so "ISS1" was probably the version with AM26LS34.
philb
Posts: 725
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: New Econet device

Post by philb »

Yes, that sounds plausible. If issue 2 followed issue 1 rather quickly then it might explain how the reference to "Project B" survived on the silkscreen. I would have expected that to have been expunged once the Master was launched.

I hadn't heard about the AM26LS34 thing, obviously I never looked closely enough at an Acorn bridge.
User avatar
BeebMaster
Posts: 4345
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: New Econet device

Post by BeebMaster »

I don't think I have an issue 1 "B Econet" (incidentally if you dismantle a Compact monitor stand PSU it's marked "Baby B PSU") but I do have the hand-built Acorn prototype Econet modules and they have 26LS34 and 26LS30:

Image
Image
User avatar
jgharston
Posts: 4458
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: New Econet device

Post by jgharston »

arg wrote:
Wed Jun 09, 2021 5:11 pm
I have been starting to collect data on this and other dirty secrets of Econet implementation as I come across them; this document is meant to be a manifesto for interoperation of various new stuff: the main part of it isn't written yet, but the annex on BBC implementation contains quite a lot of detail now:

https://docs.google.com/document/d/1Bd1 ... sp=sharing
Some terminology that is useful to keep consistant:
Bridge: joins two similar networks. Econet-to-Econet is a bridge, Ethernet-to-Ethernet is a bridge.
Gateway: joins two dissimilar networks: Econet-to-Ethernet is a gateway.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
awilliams
Posts: 70
Joined: Sun Feb 22, 2015 10:51 am
Location: Adelaide, Australia
Contact:

Re: New Econet device

Post by awilliams »

wiggy wrote:
Wed Jun 09, 2021 2:56 pm
awilliams wrote:
Wed Jun 09, 2021 2:01 pm
two stations simultaneously transmitting ...
The bug in your maths is that two stations simultaneously transmitting are unlikely to be also synchronised. (Obviously the bit periods are aligned, but it's rather less likely that the bytes align).
Maybe and maybe not. If you think about a busy net, the bastion of the collision, then my hypothetical stations 1 & 2 are both waiting for the line to go idle. They will see that simultaneously, they will send opening flags the destination station and net bytes any zeros that need inserting and be six bits into the source station address before they drive the line in opposite directions signalling a collision.

After the collision they will back off for a delay based on the station number to try to avoid doing exactly the same thing again.

To be honest I have not studded this in detail personally I am just tabling it as it was explained to me by some Acorn body, but I forget who.

Alan
User avatar
BeebMaster
Posts: 4345
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: New Econet device

Post by BeebMaster »

Is the net number taken into account when calculating the collision delay? For example, what happens if two stations with the same station number, but on different nets, try to transmit at the same time?

Presumably in any event because of physical location of the stations, cable length etc. one of the stations will "get there first" if only fractionally.
Image
philb
Posts: 725
Joined: Sat Aug 05, 2017 7:05 pm
Location: Cambridge, GB
Contact:

Re: New Econet device

Post by philb »

No. Each net is its own collision domain (you can't collide across a bridge, at least not in the conventional sense) and older/simpler clients (model B for example) don't know what their own net number is anyway.
Post Reply

Return to “8-bit acorn hardware”