Date   : Thu, 28 Jul 2005 10:35:14 +0000
From   : Jules Richardson <julesrichardsonuk@...>
Subject: Re: Econet-Ethernet bridge

On Thu, 2005-07-28 at 11:32 +0200, Johan Heuseveldt wrote:
> > I just grabbed the 68B54 datasheet, and it looks like the whole thing is
> > byte-accessed anyway, and the chip itself handles
> > serialisation/deserialisation to/from a bit stream. 
> 
> In that respect, the chip is like any other serial device, but already a
> bit more than that: TxData, RxData, TxClk, RxClk, RTS, CTS, DCD.
> (only DTR isn't used)
> 
> I've always had the feeling that people (I talked to in the past) did't
> fully appreciate the special features of the ADLC. There were other
> designs for a network using a normal serial chip

You're right in that it certainly does some useful stuff which would
otherwise have to be done in software...

> If NFS has determined from the first byte (or two) that this packet isn't
> addressed to this machine, it gives the 68B54 a command to completely
> ingore that frame.

Yes, I hadn't realised that before, but the docs seem to imply that the
protocol's capable of handling more than 256 devices, but Acorn chose
not to do this I believe (I'm not aware of any Acorn machines that can
have a station ID > 255). I haven't read the datasheet fully yet though,
just skimmed through it.

> . Any new interrupt is from a new frame coming in,
> completely freeing the processor from any overheads of the invalid frame.

Presumably any kind of acknowledgement / timeout is done at a higher
protocol level? (In other words a packet sniffer would be possible
because the ADLC can run in purely passive mode and read entire packets
destined for other stations)

> > Main problem might be the lack of output lines (other than the 8 data
> > bits) of a parallel port - seems like the 68B54 needs quite a few
> > control lines as well as the data bus: RS0, RS1, R/-W, -RESET, -CS, and
> > E.
> 
> And additional hardware for clocking the 68B54 from the clock remote
> signals, and sensing clock presence (nDCD input), and contention logic
> (nCTS input), and the line drivers of course.

>From memory I think there are 4 output lines (other than data) on the
parallel port, 4 input control lines, plus an input IRQ line. 

> In addition to that, it must be possible to 'disconnect' or 'mask' the NMI
> from the system NMI line. This is done by not propagating the low NMI signal
> from the 68B54 to the system's NMI line with extra hardware again.

Could that be done in software though? OK, it's wasteful... depends on
how often the chip sets NMI when the system technically doesn't need to
respond though.

> > (although I think E can just be a free-running local clock, and it
> > *might* be possible to hold -CS permanently active)
> 
> Hm, you need to check the docs on that, now you have them! :-)
> 
> But I think the answer is no: In an 6500/6800 environment the trailing
> edge of E (which is the leading edge of the next cycle) is used to clock,
> or latch the data in the selected register, which should be addressed (CS)
> in relation to that E clock to meet all the timings!
> E and CS are closely /related/ to each other!

Hmmm... that's probably going to make it tricky. It implies that the
clock needs to be totally driven by the system (using a toggled output
line) rather than it being on-board. 

This is starting to look less and less possible without additional
hardware - I'm starting to see why the rumour is that Acorn's VAX Econet
interface was actually a BBC doing the network processing and hooked up
to the VAX by a different interface!

cheers

Jules