[Coco] DriveWire virtual serial ports - multiball success (2)

[Aaron Wolfe]

It works!  I have /T1 - /T4 talking with four different PTYs on my
linux box.   Thanks for the tip about system DP vars Boisy.

They say a picture is worth 1000 words.. so I attached one, hope it
comes through. <-- It didn't.
Otherwise I'll post on my project page, http://aaronwolfe.com/coco

Now that proof of concept is done, I seriously have to clean up the
driver and server side code for efficiency.  still need to add
signaling and status things, right now it's the bare minimum
implementation of my spec required to see it in action.  As I tried to
implement the changes I proposed in my RFC, I found some things worked
better laid out a bit differently.  Also, I think it's going to be
better to move the logic for traffic prioritization out into the
server.  I want the driver to be small and efficient as possible.

Apologies to anyone who's tried to use the code on my web page.  I let
things get out of sync and some combinations of the code there will
not work with each other, as Mr. Furman let me know yesterday.  This
will be sorted out today.

Revised spec 11/16/09:


SERREAD  (this is the poller, occurs 10 times per second currently but
can certainly change)

 1 byte command (just the opcode)

 2 byte response:

  byte 1:
     first 2 bits: type of reply
             00 - normal serread response, either nothing waiting or
a single byte for port specified in lowest 3 bytes
             01 - status change for port, new status is data byte
             10 - unused
             11 - multiread request - see below

     third bit - 1 = server would like driver to send another SERREAD
immediately after processing this one.  driver is not required to do
this
     bits 4,5 = MSB of data waiting on server in a multiread req..
kind of clumsy having them in the middle but it fits.
     bits 6,7,8 = port number

  byte 2:  type 00 - data byte for port
              type 01 - status byte for port
              type 11 - LSB of data waiting on server

The major change here is that the SERREAD response only tells the
driver about one port instead of all of them.  This means the logic
for which port gets attention by the driver about is completely done
in the server.  It eliminates the extra exchange of a GETSTAT during
multi reads, which I really did not like.  Since many times we'd be
using only 1 port, and would want that port to be as fast as possible,
I think this is a better design.

The multiread request tells the driver how much data is waiting for
the port, but does not provide a byte in the reply.  It takes the
logic of when to do a SERREADM away from the os-9 driver and puts the
decision solely in the server code.  I think this is a better place
for it, as the server knows the rate data is actually coming in, knows
about whats happening on all the various ports, etc.  Since I pass
very little data between port handlers on the os9 side, they don't
easily have a view into this.


SERGETSTAT - inquire port status,
2 byte command
      op code
      argument byte = 3 bits for port #, have lots of room for other
things, possibly a code for system status request?

2 byte response
      waiting data size for requested port..  if max buf is 1024, 6
bits left for RI, DCD, CTS, mode (data/interactive), etc

?       system status
      0, seven bits for which ports are initialized
      1, seven bits for port mode (data/interactive)


SERSETSTAT - Open, close, change mode of a port

2 byte command
      op code
      5 bits
              mode (interactive/stream)
              RTS/CTS
              DCD/DSR
              etc
      3 bits port selector, 7 = all?

1 byte response = echo arg byte back = confirmation, some
unlikely/impossible set of bits + remaining could indicate failure and
reason
setting the port to its exact current status could indicate a termination

Finally, SERREADM's arguments have to be extended to accomodate values
larger than 255 anyway, so the extra 3 bits for port select cost
nothing.

SERREADM
3 byte command
      opcode
      3 bits port #, msb,lsb amount (max 1024 due to limits in SERREAD)

      response = X data bytes