TCP for the unix-pc

[Gil Kloepfer Jr.]

In article <1909 at umbc3.UMBC.EDU> mark at umbc3.umbc.edu.UMBC.EDU (Mark Sienkiewicz) writes:
>4. My favorite idea would be to have a bi-directional parallel interface
>that talks the the machine on the next table.  Then one of them would
>gateway things onto a serial bus network.  I think with the right
>hardware, you could push it to around 100k bps without too many problems.

I'm currently working on this idea.  Mike Thompson is working on a SCSI
port, which essentially is the same thing (but better).

Some observations on the overall tone of the quoted article:

First, it is unwise to make a bidirectional parallel interface that is
entirely interrupt-driven.  I already tried this and it *does* swamp
the CPU with interrupts.  You'll end up with spirious interrupts because
there will be an interrupt coming-in as you're in the process of returning
from the interrupt service routine.  This isn't good.

Second, using a buffered UART to perform I/O is not worth the effort if
all you're doing is adding a 16 byte buffer.  To gain more throughput and
keep the CPU from being overwhelmed, a packet-based protocol should be
used with the packets transferred to/from off-board RAM (say, 2K or so)
using the 256K address space allocated to an expansion slot (see next
paragraph).  Off-board, some kind of intelligent controller should be
used to transfer the data packet in this RAM off through the UART (or
parallel interface chip, such as the 8251).  This takes the load off
the 3B1's CPU and provides greater (and more reliable) throughput.  You
could use DMA to the 3B1, but this could hold the bus for an unreasonable
period of time.

Third, it is not my recommendation to wire anything to the bus through
chips on the motherboard -- stick to expansion slots.  Like you, I
didn't have the right connector so I wired straight to the slot connector.
There are signals coming out of the expansion slot, as well as the
proper addressing schemes, which should be adhered to so that all
peripherals may peacefully coexist.  If this doesn't sound good enough
for you, let it be known that I/O timing and other CPU timing is
different on the 3B1.  Unless you have circuitry that can operate
at the full processor speed even with the kludgy wiring off a chip,
you will experience definite problems with prop. delay.

My true feeling is to wait a few months for Mike and the crew to come up
with a public-domain SCSI port.  Since schematics and software will be
all available, you can make with this what you want.  If all you want
is a serial network, then you'll probably get the best throughput
with the on-board serial port and a special driver.  I have a feeling
though that this SCSI idea will be real good for something, even if
the software isn't quite right.

-----
| Gil Kloepfer, Jr.
| ICUS Software Systems/Bowne Management Systems (depending on where I am)
| {decuac,boulder,talcott,sbcs}!icus!limbic!gil   or    gil at icus.islp.ny.us