Date : Thu, 28 Jul 2005 17:51:22 +0200 (BST)
From : Johan Heuseveldt <johan@...>
Subject: Re: Econet-Ethernet bridge
Hi Jules,
On Thu 28 Jul, Jules Richardson wrote:
> On Thu, 2005-07-28 at 11:32 +0200, Johan Heuseveldt wrote:
> > 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,
That's correct. The byte for station number can be extended to two
bytes. That is, the ADLC really 'knows' that the first two bytes
are an extended station number.
> 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.
The second byte of the frame is the net number, so addressing is
still 16 bits! :-)
TBH, I don't think that's a real issue. When I imagine the relative
low speed of Econet and having 500-1000 machines - which is still
modest in view of more than 65000 possible - on a single Econet net....
Nah, users wouldn't like it (the effect on responsiveness) I reckon.
I think the concept of byte wide nets and stations is a lot more
elegant, and seems to be thought over quite well.
> > 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?
(hope I understand you correctly)
No need, as it is completely taken care of by the ADLC. After instructing
the ADLC to ignore the frame, NFS sets up its NMI handler for receiving a
fresh new frame. It would not get /any/ interrupt at all from the ADLC
regarding the current frame on the net.
My impression is that the ADLC is literally ignoring the frame: no
serialisation is taken place for retrieving the data, perhaps for
its own internal use: It knows when a new frame ends and starts.
When a new frame starts, NMIs get active again, and NFS get informed
just in line how NFS had setup itself previously.
The ADLC knows about a new frame because of the flag byte which is
not part of the data in the frame but just in front of it. This
flag byte has at least 6 '1' bits in a row in that byte. Normal data
has never more than 5 '1' bits in a row. (NB: data bytes on the net!)
If data to be sent has somewhere in the byte 5 '1's in a row, a '0' bit
is inserted by the sending ADLC and removed by the receiving ADLC. So,
on the Econet net, there are also 9 bits bytes in the data stream!
(this concept is known as 'Zero Insertion')
> (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)
(don't think there is something as passive mode, but most likely
I just don't understand what you're trying to say, sorry)
It is the very first action of the NMI handler to determine if a
frame is destined for this machine. Change that NMI handler, not
performing that look up, and you can build your sniffer application
around it. Well, actually, you don't have to do that yourself, as
Acorn has provided for one. The (Net)Monitor just works in this way.
Both Econet level 1 & 2 has this on their discs. Level 4 dito.
It's all quite advanced.
But TBH, it's also everything I know off. Techniques evolved from there
are a bit too much for me I think:
I have downloaded, printed with high quality and ring binded the
'Product Data Sheet' of the Ethernet device CS8900A - from
Cirrus Logic) - already mentioned here. Although I can understand
most of it, and it even triggers some ideas how to adapt for our
beloved 6500 Beeb system, I thought it unwise to continue with it.
> > > 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.
I'm not giving this any more serious thoughts, as I really think the
whole interrupt system will the bottle neck, just as EcoLink on ISA.
(The onboard processor isn't there for being pretty!)
Not only the practical side, as the availablility of signal lines - as
you say, but atm I don't see a problem there - but I'm getting to have
serious doubts about the interrupt aspects of such a design with the
parallel port, and the difficulty how to genrate the necessary signals.
Allthough everyone is entitled to prove me wrong! :-)
> > 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.
Shoulf be enough. Point is, can they be addressed quick enough?
Even more important: are they of the right kind, if not, can they be
changed to suit our needs?
So, the 8bits interface of the 'parallel' port, including the extra
signals, must be designed as a higher hardware layer for accessing not
only the ADLC, but also the hardware around it.
But that seems not enough:
* Adress decoding through the parallel bus? Possible, but would have
a speed penalty for sure.
* Swtching NMI on/off to the ACK signal can be implemented by a one
of the output lines available on the 'parallel'?
(two are used in the original design, so we gain one)
* Is the ACK fast enough to the system, and is there a system overhead
penalty (software), like ISA?
* Probably the address decoding can be done from the extra lines as
mentioned (1rst *), but how to synchronize with E and R/nW
* There is no R/nW, so that has to be created from nRD and nWR, in
conjunction with the E
* and must be in sync with the address decoding
Not sure how all of you are now, but I'm getting a headache. :-)
> > 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.
NFS uses the highly advanced features of prioriterized interupts of
the ADLC.
* The first byte in the frame is the station number, and the ADLC will
interrupt on that. Other interrupts could be raised too, but
reading the Status will show it's the station number interrupt, as
it has a higher priority than others.
* As soon as that byte is read, this state of interrupt is cleared, and
another one is raised, because it was already generated.
* NFS is still in its own handler for the first byte (the station),
but for now I don't know what happens with the real IRQ output of
the ADLC: Will it be deasserted, to be directly asserted again?
(glitches?)
And there are several priotirized interrupts.
Also to watch out for are the slight differences in behaviour between
several different production masks of the chip.
[snip: free running E not possible]
> 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!
Yes, read on. (EcoLink)
As I said before, the more I think about it, the more problems I see
coming up.
Is it only darkness around here. No I see some light. In fact, thanks to
all the thoughts expressed on the list, I clearly see another way, still
using the the 'parallel', and that's the EcoLink way:
Make a dedicated board with ROM, RAM, a 6502-ish and the ADLC, just as
the EcoLink does. But change the ISA interface for the 'parallel'.
That must simplify quite a lot, both on hardware [*] and software, and
should make everything a lot more reliable, as there are no timing
issues anymore (for a start).
[*] The quantity of hardware is more, but most of the design
difficulties for the 'parallel' are gone! (Phew!)
greetings,
Johan
(headache allmost gone, although that could be caused by the
length/time-taken of/for the story too :-) )
--
Johan Heuseveldt <johan@... >
aka waarland
The best place is a Riscy place
Everything takes longer than you think it will.