At 0:16 Uhr +0100 09.11.1999, Bill Studenmund wrote:
>On Mon, 8 Nov 1999, Hauke Fath wrote:
>> 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.
>
>Kinda. While that's what Apple calles it in pictures of the port,

I see. Still, I maintain that this is a misconception. When the Macintosh
Plus came out in 1985, there was no need for flow control with modems (the
'83 Macintosh did not even have an outgoing handshake line!). According to
[CAM87], the RTS/CTS pair was used for switching direction on half-duplex
links.

And the URL you gave (IM:Devices:Serial Driver) talks about line control,
only listing in a side note that the SCC DTR pin is actually a general
purpose output.

>Nope. DTR. HSKo doesn't translate well into NetBSD. For instance, if you
>use the TIOCMXXX ioctls, this pin is controlled by TIOCM_DTR.

As that notion is what I propose to fix, it is no good as an argument here. ;)

>Oh. This might explain a lot. I don't think anyone expects the other side
>to do cdtrcts handshaking, unless it is another mac.

Yep. And even the other Mac, then, would use RTS semantics on the
HSKo/"DTR" line.

>But you're also talking about the cable explicitly doing a
>wiring conversion...

Not exactly "conversion"... According to [CAM87] -- best book on the issue
I have seen so far, btw. -- even the very first Hayes SmartModem came with
AT&D0 to ignore the state of the DCE's DTR input line. Probably to ease the
RS232 interface hell with a three-wire line option.

Therefore, a Macintosh "hardware handshake" modem cable bridges pin 4 (RTS)
and pin 20 (DTR). This gives you hardware line control with DTR enabled
(AT&D1) because the modem does not care about RTS when it is told to hang
up, and, alternatively, hardware flow control (AT&D0) because the modem
explicitely ignores DTR.

Probably you can even have your cake and eat it when you tell the modem not
to hang up unless DTR is low for a certain time (ATS25=255 for a Rockwell
chip set -- I haven't tried it, though).

>Uhm, it's still the DTR pin. It's not cdtrcts because we use DTR
>semantics, but because we use the DTR pin.

And if Zilog had named the pin "FOO" we'd call it "cfoocts"? Can't follow
you there, sorry.

>Well, I wasn't the one who came up with this solution. So I'm not the one
>you need to convice, though I do agree with the decision.

{When,On which list} was this hashed out? Just so I can go and find out if
there were any arguments besides "Zilog named the pin DTR"?

>But from the point of view of the kernel, there is no (externally visable)
>RTS pin, so what sense does crtscts make?

Describe the semantics? Because the outside world cares about the
_semantics_ of the line, not about the _label_ that the chip manufacturer
cared to give the pin?

	hauke

--
[CAM87] Joe Campbell, "C Programmer's Guide to Serial Communications",
        1987 SAMS