Subject: New serial driver for testing
To: port-mac68k <port-mac68k@NetBSD.ORG>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 10/03/1997 10:30:23
Howdy!

I've put (what I think are) the final touches on a new serial driver
for mac serial ports. This driver uses the machine independant SCC
driver (shared w/ sun3, sun3x, and mvme68k). The patches are at:

ftp://ftp.macbsd.com/private/wrstuden/zstty/zs.patches

They patch the kernel, pppd, ttyflags, stty, libc, and a few other
commands. I've tested the kernel patches, pppd, and stty. They work
fine. The other patches are simple code extentions, which compile. :-)

So I'd appreciate it if the folks who are set up to build kernels
could try them. A few folks have already tried an earlier version of
the patches, w/o problem. The hope is for this new driver to make 1.3.
I think it's in good shape, but I'd like to get folks used to it a
bit at a time.

What is different?

There are a few big changes. Everyone will need to know about them when the
driver gets into the tree.

1) The driver always gets reset to the defaults each time it goes from
fully closed to open. That means that you can't do an "stty -f /dev/tty01
57600" and have the change stick. So all the folks who are using my
gs distribution (which is really old) will need to change their setup.

I doubt this will be a problem for two reasons. One, we can now (actually
could since 1.2 or maybe even 1.1) set the baud rate to whatever we want
in the printcap entry, and we can set the printcap entry to use "raw"
settings by default.

Also, the booter can now pass in a default baud rate for the serial
ports, so all you have to do is just change some booter settings, and
the printer will default to 57600. :-)

2) We now properly do flow control. The problem has been that we only have
one control output from the serial port, and the output's commonly used
to make the modem hang up the phone (DTR). The new driver adds a new
flow control mode, cdtrcts, which will use DTR to tell the modem to
hush. If your RS/232 cable has wired HSKo to RTS, it will work.

crtscts will watch CTS, and hush when asked. This mode is great for
printers (like the DeskWriter I have :-), and lets you hang up the
phone.

cdtrcts is new, and uses DTR as a handshake output, to get the modem/other
computer to stop. CTS is still monitored for when we're asked to hush.
This mode is great for hooking two macs together (with a printer cable)
or talking to a fast modem. This mode can't make a modem hang up the
phone (you'd have to send a special AT command).

I tried cdtrcts hooked up to a 386, and, at 57600, was able to get > 10,000
BYTES/sec throughput (ppp compression was on) w/o a single overrun. :-)

Note: receiving data at a high rate can make the computer sluggish. When I
did the above test, my IIsi was VERY VERY sluggish. Switching screens
in dt took 6 seconds or so. dt would do part of the screen, then pause,
then do more, then pause. If you try this, DON'T expect to get much
else done. Hopefully for 1.4/2.0 we can do even better.

So let me know how the patches work! Oh, and don't forget that, as Mason,
Paul, and others have mentioned, pppd is kinda sick right now. I think
using an old chat is fine.

Take care,

Bill