Path: utzoo!attcan!uunet!lll-winken!ames!netsys!ziggy!scotty
From: scotty@ziggy.UUCP (Scott Drysdale)
Newsgroups: comp.sys.amiga
Subject: Re: Multiple Serial Ports (Re: vt100 v2.9)
Message-ID: <147@ziggy.UUCP>
Date: 8 Jan 89 16:57:20 GMT
References: <8812150227.AA09671@postgres.Berkeley.EDU> <14049@oberon.USC.EDU> <554@sunkisd.CS.Concordia.CA> <3241@sugar.uu.net>
Reply-To: scotty@ziggy.UUCP (Scott Drysdale)
Organization: Un*x Link,Frederick Md.
Lines: 83

In article <3241@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes:
>To anyone who might be developing a multiport serial board, two things:
>
>1) Consider using the NEC 16550A's rather than 8250's or whatever, because
>the 16550's have a 16-byte typeahead buffer.  At high speeds, it is very
>difficult to get out and get all the data on the Amiga.  For example, at
>MIDI speeds, bytes come in every 333 microseconds.  It's hard to catch
>them all, indeed impossible, as the exec seems to sometimes leave interrupts
>off for longer than that.  With 16550's, the minimum time the system has
>available between the UART receiving a data byte and the system reading
>it before getting an overrun is widened by a beefy 16X, for MIDI to about
>5 ms.
>
>2) Please support MIDI as well as RS-232.  Supporting MIDI requires only
>a couple of things:  One is that you need to be able to produce data at
>31250 kilobits (1 megahertz / 16) per second.  The other is that you produce 
>0 and 5 volts for logic 0 and 1 rather than the -12 and +12 for RS-232 and 
>that you use an opto-isolator capable of a few microseconds switching times
>on the input data wire.
>-- 
>-- uunet!sugar!karl  | "We've been following your progress with considerable 
>-- karl@sugar.uu.net |  interest, not to say contempt."  -- Zaphod Beeblebrox IV
>-- Usenet BBS (713) 438-5018

first of all, anyone who develops a multiport serial board that doesn't have
it's own CPU on board is absolutely nuts.  using interrupts from the UARTs
is also grounds for the electric chair.  i've done this before - the board was
an intel SBC547, which is a multibus I card with and 80186, 4 zilog SCCs, and
some rom and ram.  the firmware that came with the board really sucked, so
we rewrote it and made it compatible with the device drivers that normally
worked with the 547 (running intel's firmware).  the final solution was
basically as follows:

 - all operations are polled.
 - communication requests from the host (multibus) generate an interrupt
 - the host manages it's transmit queue in our memory (32K of dual port RAM)
 - we manage the receive queue.
 - a 1 millisecond timer interrupt causes the 8 uarts to be polled for
   receive and transmit until they're empty or full.
 - minimal other work is done in the 1ms interrupt (xon/xoff checking for
   instance).
 - the 1ms interrupt fills and empties a set of secondary circular queues.
 - the main (idle loop, non interrupt) portion of the software merely
 - keeps an eye on requests from the multibus and the states of the uart
   transmit/receive queues and shuffles stuff back and forth between the
   dual port ram and the secondary queues.  we also decided to put polling
   for hardware handshakes here (CD, RTS, etc).

we measured the performance of the interrupt handler and when it had a full
pile of work to do (3 bytes in each uart for receive, 2 bytes to transmit to
each uart, xon/xoff checking) it took around 600 microseconds.  that's 60%
usage, allowing the host interface idle task to have 40% time even when the
machine is doing 19.2K TX/RX at full blast on all 8 ports.
because the host interface is sort of a background task, interesting things
happen as far as loading of the host.  the busier the board gets, the more
efficient host transactions become.  fewer interrupts (cuz the main loop
goes through fewer cycles) with more data available per interrupt (since
it's piling up due to the slow loop).

as to midi, i suppose it would work as it stands for light traffic (assuming
that no more than 3 bytes arrive on a given port per millisecond).  to make
it really handle midi, the simplest way would be to cut the number of ports
in half and cut the 1ms interrupt down to a 500 microsecond interrupt.
alot of the stuff the interrupt handler normally performs could also be
removed, so maybe making the interrupt handler around 750 microseconds and
cleaning up the handler could do it for 8 ports, but again it's not really
full speed yet.  yeah yeah, a faster 186!  that's the ticket!

i would just *LOVE* to whip up a similar board for the amiga (even if only
for releasing the schematics and software to PD), if only i had the following:

1) useful description of how serial.device is supposed to behave (sorry, the
   RKM just doesn't cut it)
2) useful description of a device driver in general (again, the RKM is sort
   of wrong in several places - most notably the example device).  the only
   device i have gotten to work is the scottdisk.device, but it bears very
   little resemblance to the RKM example, but they seem to do the same things.
   one works, one doesn't.

anyone have any comments?

  --Scotty