At 19:39 Uhr +0100 08.11.1999, Bill Studenmund wrote:
>On Sun, 7 Nov 1999, Hauke Fath wrote:
>
>> At 8:00 Uhr +0100 07.11.1999, Bill Studenmund wrote:
>>
>> 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_.
>
>Yes, but as you've mentioned, it's hooked up to the dtr pin. ;-) _That's_
>why it's cdtrcts.

No. It is HSKo, a general-purpose output line that is in no way tied to the
SCCs internal state other than the corresponding register bit and for all
we know could be the SCC RTS, its DTR or any line from a 6522 VIA.

>> We should fix the mac68k behaviour, and not change the rest of the
>> world to adjust to a misconception.  =8)
>
>But the misconception is on the other programs' thinking that crtscts is
>the only flow control form. From the point of view of the driver, the pin
>in question is the DTR pin.

HSKo.  =8)

Sorry to pick nits, but a (modem) cable that connects HSKo to DTR only is
simply not going to give you hardware flow control for incoming data with
any real-world modem. The modem will then either ignore what you feed it on
pin 20, or it will control the line state depending on pin 20 -- which is
DTR semantics.

You won't get hardware flow control until you bridge the modem's DTR and
RTS (or wire RTS only), *and* tell the modem to ignore what happens on pin
20/DTR. At that moment, you give up line control and use HSKo with RTS
semantics.

Repeat: To use the Mac's HSKo for controlling the flow of incoming data
(RTS), you need to explicitly *remove* DTR semantics both on the Mac side
(serial driver) *and* on the modem side (AT&D0 and change wiring).

No DTR left on both sides, sorry. Thus, no point in calling the mode "cdtrcts".

>When using the ioctls which get & set modem
>control line state, this pin is reported / updated according to the DTR
>pin settings. If a program wants to go off and do hardware handshaking,
>it can't play with RTS & do anything sensable. :-)

That is what I (strongly ;) feel is wrong and what I am proposing to change.

>> -  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.)
>>
>> 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.  ;)
>
>"has the right not to?" ??

A userland program has the right to depend on rtscts being called rtscts,
not blafasel.

	hauke


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