Subject: Re: ppp woes continued
To: Bill Studenmund <>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
List: current-users
Date: 11/07/1999 14:49:14
At 8:00 Uhr +0100 07.11.1999, Bill Studenmund wrote:
>On Sat, 6 Nov 1999, Hauke Fath wrote:
>> You want cdtrcts -- which, IMO, is a bad misnomer, because on mac68k it
>> delivers what drtscts promises to do. This is causing all sorts of havoc
>> when you try to run off-the-shelf unix comm applications on mac68k (try to
>> run uucp with hardware flow control =8( ).
>Well, there two reasons we named it like we did. First off, in terms of
>the chip, it really is the DTR line (RTS is used to turn the line drivers
>on and off). Also, a fair amount of Apple serial port documentation talks
>about "DTR" handshaking. :-)

As my Zilog data book says, "[!DTR/!REQA, !DTR/!REQB] These outputs follow
the state programmed into the DTR bit. They can also be used as
general-purpose outputs or as Request lines for a DMA controller."

I.e., if we use HSKo as a flow control handshake line, we _explicitly_
("AT&D0") tell the modem _not_ to monitor the DTR pin. At this point, "DTR
handshaking" is the wrong label - the line does not have DTR semantics, and
no modem out there can be convinced to do flow control _via_the_DTR_line_.

>Though we really should fix all packaged comm stuff to support cdtrcts.

No. We should fix the mac68k behaviour, and not change the rest of the
world to adjust to a misconception.  =8)

I propose

-  renaming the mac68k "cdtrcts" to "crtscts" to sync with
   the rest of the world
-  keeping around "cdtrcts" for compatibility but making it
   clear that it is deprecated (eventually phasing it out)
-  creating  a new "ccts" tag for unidirectional handshake,
   using HSKo with DTR semantics.
-  making the mac68k hardware handshake limitations clear in
   the zstty manpage. (There is no "ssc" manpage, btw.)

>Please file a PR if we've messed up.

See above.  =8)

This has been in the pipe for quite some time, ever since I wasted a few
nights on trying to run UUCP over my ISDN TA just to find out that
everything over 19k2 creates a flood of errors. Diving deep down into the
in-tree Taylor uucp source, I finally found that it had no clue about
mac68k's view on hardware handshake. And I understood that it has the right
not to.  ;)


"It's never straight up and down"     (DEVO)