🚀 go-pugleaf

Jerry at Calma/Computervision (are they the same now?) and I have been
exchanging some e-mail about the SPC/S board, a serial/parallel expansion
board for the SBus that Sun makes.  I asked Jerry if I could post relevant
parts of our exchanges to this group, and he agreed.

I am both "|>" and "", and Jerry is "|".

|>I use a Sun SPC/S board - it's got 8 async serial ports and one parallel
|>port (got my HP DeskJet hooked up to that port).  The SPC/S supports full
|>hardware flow control on all serial ports.
|
|This contradicts other information I have received on this and I
|would be very glad if you are correct, but would like you to check again.
|
|Does "supports full hardware flow control" mean that the port will
|drop RTS to stop input from the modem as well as stopping output to
|the modem in response to the modem dropping CTS?  The informatiom I have
|is that Sun drivers do not support the former on any serial port hardware
|because it is "non-standard", a position that I consider to be just a
|poor excuse and rationalization for not considering this a sufficiently
|high priority to allocate resources to fixing.

Yes, the SPC/S board does support full modem control.  I think the confusion
comes in because people say "Sun's serial drivers", when in reality they
should say "Sun's drivers for the serial ports (commonly called the "zs"
driver) that are on the Sun motherboard".  The driver for the SPC/S card
(which I wrote, BTW) is not based on the zs driver at all.  The hardware on
the SPC/S board is completly different than the zs hardware; zs h/w uses
Zilog 8530 UARTs, and SPC/S uses a single 8-channel cd-180 UART (octart) from
Cirrus Logic.

The SPC/S board will drop RTS when the driver's buffer for the serial port
passes a high-water mark, and raises RTS when a low-water mark is passed.
The buffer size used by the driver is 1024 bytes per serial port, and there
is an 8-byte FIFO per serial port on the SPC/S hardware as well.

When your modem drops CTS into the SPC/S, the SPC/S will stop sending data to
your modem within two character times.  There is no interaction between CTS
and CD as there is on the Zilog (zs) part.

|The lack of bi-directional
|RTS/CTS flow control on the Suns is the ONLY reason we have not replaced
|our aging Pyramid 90x with a Sun SPARCserver 690.  The Pyramid has
|serial I/O ports that support this feature and we have become quite
|dependent on it.  It may be 'non-standard' but it does not break the
|standard, rather it just takes a signal that otherwise just duplicates
|DSR and is thus just redundant (and really useless) and gives it an
|important function in providing a capability that is missing from the
|standard.  So what if the UARTs don't support this in hardware.
|It is just a matter of having drivers written to provide the functionality.

That's right.  The Zilog parts have a nasty side effect of disabling the
receiver if you enable automatic CTS flow control and CD is deasserted.  It
has to be one of the stupidest UARTs that I have ever seen and had the
displeasure of working with (but I have nothing to do with the zs driver).
After coming out with the great Z80, Zilog should hang their head in shame
for designing the 8530 the way that they did.

|We have several high speed modems on our Pyramid and have had no
|problems with input overruns despite the fact that the Pyramid
|is only a 2.3 or so MIPS system.  Until we get some assurance that
|a Sun server can provide this performance we will be sticking with
|the old Pyramid.

Your company is pretty big - have the Sun sales person bring in a 690 in a
small chassis with an SPC/S board and let you borrow it for a week or so to
use on your modem pool.

    [some editorial comments deleted for out mutual safety :-]

mike

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mike bender  DOD# 007  for sale: NX-650 & VT110 Shadow	415-863-8913 (home)
bender@oobleck.eng.sun.com    nothin' witty here	415-336-6353 (work)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~