Date : Tue, 07 Aug 2007 09:44:26 +0100
From : dominic@... (Dominic Beesley)
Subject: Emulating Econet hardware?
----- Original Message -----
From: "Johan Heuseveldt" <johan@...>
To: <bbc-micro@...>
Sent: Monday, August 06, 2007 9:01 PM
Subject: Re: [BBC-Micro] Emulating Econet hardware?
[snip]
>
>> thoughts were on finding sufficient numbers[1], emulating one with
>> other off-the-shelf bits, or using some sort of programmed device for
>> the emulation. I don't think the Econet chip was a particularly complex
>> device;
>
> I think it is.
> Probably in the same region as FDCs?
> (or a FDC being the simple one?! :-)
>
> After all, it's an 'Advanced Data Link Controller' (ADLC)
>
When I looked there was the issues of doing the extra 5th zero bit
insertion thing required by the protocols and the CRC calculation
quickly on the fly with modern (cheap) microcontrollers probably
just able to keep up doing only that flat out.
>> it was just more convenient to do it in one larger chip than a
>> handful of common TTL/line drivers/whatever.
>
> Probably needing a PCB as big as the Beeb itself?
> Just guessing.
>
> OTOH there is the SJ Research design - in its MDFS - with only a
> Z80 SIO, and lots need to be done in software. I'm not familiar with
> that serial device, so don't know how much it can do in hardware, and
> what's left to be done in software.
>
> It /is/ known that the MDFS is very fast, and I can fully confirm
> that! :-)
> Which makes it very intriguing: how can a software solution be
> faster than its hardware version that it is emulating. Processor
> speed is 6 Mhz ('B' versions of the Z80 family), which is certainly
> not faster than a 2Mhz 6502. As I said, very intriguing!
>
When I last looked there was a chip for the Z80 that did a lot of this
but with DMA (IIRC) which would leave the CPU free to do a lot more
than in the beeb where it gets troubled by NMIs almost constantly
during econet traffic. On Z80s it is relatively simple to get DMA
going during the Z80's fairly predictable "bus free" clock cycles.
>> If the chip needs to be emulated and needs some sort of programmed device
>> to do it, then it starts to make a "keep it simple, just use a parallel
>> port" approach a little less viable anyway.
There may be mileage in a parallel port plus a couple of shift registers
option though rather than the parallel having to but bang every bit
it could hoover up a decent number at a time into a small buffer?
>
> There are things which can be left out, like
>
> * different size for data bytes; 5-8 bits,
> as Econet always uses 8bits only.
> * no need for loop control.
> * no need for DMA
> * Several configurations for special control fields at the start
> of a frame/packet, which can be set to one or two bytes.
> Econet only uses a single 8 bits 'Address' field (station number)
>
> Necessary at least is
>
> * zero bit insertion in the data bit stream,
> so there are never more than 5 consecutive '1' bits, which serves
> recognition of flag bytes, abortion, flag fill
> * sychronise the bit data stream to bytes
> * ignore rest of packet when instructed
> (no interrupts occur, until the start of next packet)
> * 3 bytes FIFO, both receiving and transmitting, keeping in sync with
> * CRC calculation, and insertion as last two byte in the packet
> * CRC calculation, and comparing with received last two CRC bytes
> * flag filling between packets
>
> (just at the top of my head, most likely incomplete)
>
>
I think thats right, though it may be the case to do the CRC in software
Dom