TCP for the unix-pc

[Mark Sienkiewicz]

Some observations on hardware for Alex's network stuff.  I know a diddly
about harware (I could probably get away with 2 or 3 diddlys if I had to).

---

1. The built in RS232 loses.  If you yell at it at 9600 baud, the
machine spends all of it's time doing interrupt handling and none
running your program.  I'm sure a lot of this is because of the line
discipline, but doing special drivers probably won't help as much as
you hope it will.

Implementing a driver on this hardware is probably necessary for people
who don't want to hack on their machine.  It is also a fantastic way to
get things up and running for REAL CHEAP.  It just won't be very fast.
To quote /usr/include/sys/termio.h:
#define	B38400	0000017 /* added to pass SVVS.  we dont support 38K baud */

---

2. If you still want to go with RS232, you should look in to a National
Semiconductor chip called NS16550.  It is upward compatible from the 16450 
which is upward compatible from the 8250b which you've seen in IBM PC 
clones everywhere.

The neat thing about this device is it is a complete UART with a built
in 16 byte FIFO.  You can select how full the FIFO gets before you
get an interrupt.  This means you can reduce the number of interrupts 
to 1/14th.  You could either have a much less busy machine, or run
14 times as fast.

This also has the advantage of being able to talk to machines that
use the built in serial port

I know other devices like this have got to exist, but I've never
seen any.

---

3. You could use a real dumb UART in combination with a FIFO to go 
one better on the 16550.  It would be a major hassle to implement all
the functions of a UART, but we only need SEND DATA, RECV DATA, and
NETWORK FAILURE.  If you read some of the EE type magazines, you will
see dozens of ads saying how wonderful Brand X fifo chips are.

---

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'd like to run the parallel interface all through the house, but I can't
afford that much shielded cable.

-----

Of course, in the ideal world, you would like to build this thing in
layers.  If you build the software-hardware interface right, you
could have a driver for any of the above types of hardware.  If you
get real fancy, you could even do the gateway style stuff in the drivers.

Since we have a less than ideal world, you can also suppose that an rs232
interface that uses less overhead could be built without using the expansion
bus.  It works like this:  Find a decoded but unused address on the motherboard.
0xe20000 comes to mind.  Divide it up into 8 of 64k chunks with 74138 or 
something.  Find a nearby place with some data and address lines (the
floppy controller and dma controller, I think).  Run all this to a pair
of 14 or 16 pin DIP sockets.  Then you have a cheap 8 bit I/O bus.
(If you do this, write the software so it is easy to change the memory
addresses used -- my hardware might not quite match yours...)

---

At work, they have a network called TOPS running on the Mac's.  It looks
like it uses RS232 or Appletalk.  (I also see people selling it:  e.g.
Mt. Xinu for BSD 4.3)  It also runs on Mac's and PC's.  I suspect this
makes it unlikely that you can do much with it for free.

I do notice that it looks like a bus with a little box at each station
except at the end.  The box is about 4x2x1 inches.  I bet it doesn't
have much in it.  Anybody know?

=====

About protocols:

There are a few things to give serious consideration to when you choose
protocols:

1 - It should be source code compatible with the BSD TCP stuff.  Specifically,
	AF_INET should exist and work as advertised.  This gets you an
	portable interface.  I don't have to learn AF_RANDOM styles of
	thinking or anything like that.

2 - There should be a protocol that is easy enough to implement that it
	could be ported to other machines.  "other machines" includes
	things like Mac's, PC clones, and even CPM or dumber.  This is
	almost guarenteed to be both stupid and proprietary.

3 - At least one protocol that goes off machine to other UnixPc's should
	be implemented soon enough that it doesn't look like vapor-ware.

4 - proprietary (or non-standard) protocols suck only if they don't catch
	on.  Free source code catches on quite nicely.

5 - because nobody can ever agree on protocols, it should be possible to
	run more than 1 protocol on the same hardware.

If anybody out there has any pet protocols, lets hear from you.

			Mark S.

uunet!umbc3!nerwin!zilla!mark
nerwin!zilla!mark at umbc3.umbc.edu	<- one of these is
nerwin!zilla!mark at umbc3.umd.edu		<- supposed to be right.

Miskatonic University
Ex ignoratia ad sapientiam.
Ex luce ad tenebras.