Subject: Re: 230.4 serial port speed?
To: David Bushong <dbushong@saidin.eecs.berkeley.edu>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 08/26/1997 11:02:08
> I was wondering if any progress had been made on the serial drivers in
> terms of supported speed, and at the same time, if someone could clear up
> some confusion on my part..

I can try.

> The issue:  I have an Epson Stylus Color 600 printer which wants its
> serial data at 230.4Kbps  I know this because if I fire up ZTerm under
> MacOS, set it to 230.4 and type plaintext it'll print it correctly.  Now,
> a while back someone mailed me a kernel patch which would allow me to stty
> the serial port speed to 230400, but I still couldn't send data out over
> it (it would essentially lock the machine up)  

At least Epson's getting real about Mac serial support. Our Stylus
Color ran at 57.6!

I was the person who sent you the patch, I believe. I don't understand
why it wouldn't work, though. What kind of mac do you have?

Oh, what serial driver are you using? If it's the ncr, I might know what
the problem is. More below.

> My main question is: _why_ does setting the port speed to 230.4 work under
> MacOS?  (e.g. I can talk to the printer w/ ZTerm and talk between two Macs
> running ZTerm set to 230.4)  I thought the max speed on old serial ports
> was 57.6?  

The serial ports can go up to 230.4 k. For rates below 64k (57600, 38400,
28800, etc), the chip uses the baud rate generator, and then divides that
signal by 16 (or 32 or 64 if we were feeling silly) for the baud rate.
It uses the faster rate (16x the baud rate) so that it can better sample
the received data, and link up with the transmitter. It's not a PLL, but
it tries to make things work well. The baud rate generator has a minimum
divide by 4. So the 3.68 MHz clock for the SCC gives 3680000/16/4 = 57600
as the fastest baud rate.

For 115.2k and 230.4k, we can bypass the BRG, and just directly divide the
3.6 MHz. /16 gives 230 k, and /32 gives 115 k.

The baud rate limit has never really been the serial chip, it's been the 
CPU overhead needed to service it. I have some ideas on how to make it
better, but our interrupt-driven driver will never do super at high
speeds. MacOS's approach at high speed (LocalTalk) is to do it in
polled-mode. That doesn't sound happy to me.

> My second (and perhaps more relevant) question is: what could i do to
> help/who could I pester to get the driver working at these speeds?  It's
> apparent the hw _can_ do it.. so the OS should be able to too =)

Allen just found a problem with the PDMA-mode scsi driver. If a serial
interrupt comes in at the wromg moment in a transfer, then the machine
hangs. You might have run into that. He, Scott, and I've batted around
some ideas on what to do. The only other idea I can come up with would be
for us to add a polled-output mode, for the really high baud rates.

The thing which makes me leary about the high speeds is that folks will
then want to receive data at these high rates. Apple only guaranteed
suport for 9600 baud, and from the overhead on the silly port, I can
understand why! I've run a PPP link at 57600 using the new serial driver,
and it took over my whole IIsi. I got NO responsivity on the keyboard.
(I think part of the problem was PPP had compression going, and
decompressed either at splnet or splsoftnet, thereby blocking
interrupts).

So what kind of computer is it & what SCSI driver are you using? I
think we should get it to where it doesnt hang...

Take care,

Bill