Xref: utzoo unix-pc.general:2837 comp.sys.att:6337
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!umbc3!wolf.umbc.edu!alex
From: alex@wolf.umbc.edu (Alex Crain)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: TCP for the unix-pc
Keywords: 3b1 7300 TCP SLIP Appletalk network
Message-ID: <1989@umbc3.UMBC.EDU>
Date: 3 May 89 21:53:12 GMT
References: <11635@s.ms.uky.edu> <1892@umbc3.UMBC.EDU> <1909@umbc3.UMBC.EDU> <479@limbic.UUCP>
Sender: newspost@umbc3.UMBC.EDU
Lines: 76

In article <11635@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes:

> BUT I can't afford to tie up the parallel ports on either the 3b1 or
> the Amiga.  I've got serial ports to spare .. but as people have
> pointed out they give lots of interrupts and generally kill the machine.

	I've been looking into the serial line driver, and I
think that I can do something with the speed. Right now, the 
sequence for servicing the UART goes something like:

	Receive interrupt
	Vector processor off the interrupt stack
	Save all 16 registers
	figure out what caused the interrupt (which channel)
	Jump to that handeler procedure
	Save the registers that were going to use.
	read the uart and stick the byte in a clist
	wake up the clist handler
	restore some registers
	so some cleanup
	restore all 16 registers and fixup the stack pointer
	return from interrupt

I figure that by dedicating the tty port to a packet based 
protocol, that sequence could be reduced to a state machine that
either:

	1) starts a new packet, initializes the recieve buffer, 
	etc.
	2) moves a byte from the UART to ther receive buffer.
	3) terminates the packet, wakes up the buffer handler.

with a fixed buffer size, we would spend most of our time doing
#2, which would look basically like this:

	get interrupt
	vector to our routine
	save %d0, %d1 and the stack pointer
	if this is not from the serial port, branch to the 
		default handler.
	read the uart into %d0
	read our global buffer pointer to %d1
	write %d0 to (%d1)+
	write %d1 back out
	restore %d0, %d1 and %sp
	return from interrupt.

This ought to be fast enough to run at 9600 baud without slowing 
the machine down much, offhand I'd guess that it can be made to 
work in about 50000 machine cycles per second, running full out,
not bad for a 10Mhz machine (of course, that doesn't count 
transmit)

	I'm thinking that some careful buffer management could
make a ring network practical, since the machine should be capable
of packet pass-thru without sacraficing speed. ie: the buffer
manager would check the addresses of packets and send them back 
out if neccessary. Alternately, the interrupt handeller could 
chaeck addresses on the X'th byte, and if necessary notify the
transmit side to start feeding them back to the UART. Or, we
could freeze the receiveing side while we feed the packet header
into the UART, and then add a state which reads one side of the 
uart and writes to the other side until the end of the packet. 
Or.....

	In any case, I think that the serial port is useable,
and its to cheap to ignore. 
	
BTW: I've got the system call interface and the AF_UNIX domain
code about finished, and I'll be tossing it out for beta testing
*real*soon*now*, so watch this space.

					:alex
Alex Crain
Systems Programmer			alex@umbc3.umbc.edu
Univ Md Baltimore County		umbc3.umbc.edu!nerwin!alex