Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!cvl!umd5!zben
From: zben@umd5 (Ben Cranston)
Newsgroups: comp.sys.mac
Subject: Mac+ DTR upside down?
Message-ID: <1372@umd5>
Date: Fri, 21-Nov-86 19:59:31 EST
Article-I.D.: umd5.1372
Posted: Fri Nov 21 19:59:31 1986
Date-Received: Fri, 21-Nov-86 22:51:57 EST
Distribution: net
Organization: University of Maryland, College Park
Lines: 38

This week I decided to find out once-and-for-all which communications programs
did what with the DTR signal.  I did so by removing the shell from the DB-25
connector and attaching a VOM between the DTR (20) and ground (7) pins.  (This 
corresponds to measuring (1) to (4) on the Din-8 connector.)  The results are
somewhat difficult to explain.

When Mac+ is turned on, DTR reads positive w/r/t ground.  Upon entering any of
the four communications programs tested, DTR went negative.  With two of these
programs, the line went positive upon exit, the other two left the line in the
negative condition:

Upon                          DTR was:
Power up                      Positive
Entry to Mac Kermit 0.8(34)   Negative
Exit from Mac Kermit          Stays Negative
Entry to Red Ryder 9.4        Negative
Exit from Red Ryder           Positive
Entry to MacTerminal          Negative
Exit from Mac Terminal        Positive
Entry to Unix Windows         Negative
Exit from Unix Windows        Stays Negative

Now, this seems to be the exact OPPOSITE of the RS232 spec for the DTR line.
Under that assumption everything else makes sense, with MacKermit and Unix
Windows either too dumb to close the serial driver or smart enough to use
the new serial driver csCode=16 csParam=0200 feature to keep DTR from being
reset when the serial driver is closed.

Could Apple really have been dumb enough to implement this backwards, do I
have a bogus serial driver, or is my analysis somehow flawed?  If things are
as I describe it certainly explains why modems have to have IGNORE-DTR set
to be used with the Mac+ systems.  NB: the corresponding pin was hardwired to 
(+12) in the old 128 and 512 Macs, which would have been interpreted as a 
good (asserted) terminal-ready status.
-- 
                    umd5.UUCP    <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU    Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"