zben@umd5 (Ben Cranston) (11/22/86)
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"cetron@utah-cs.UUCP (11/22/86)
yep, looks bacward to me!! After 7 years of hacking RS232/422/423, I posted a sign by me breakout box: positive voltage -> binary zero, signal space, CONTROL ON negative voltage -> binary one, signal mark, CONTROL OFF so I vote for a brain-damaged MAC+ -ed cetron Univ of Utah
brian@ut-sally.UUCP (Brian H. Powell) (11/25/86)
In article <1372@umd5>, zben@umd5 (Ben Cranston) writes: } Upon DTR was: } Power up Positive } Entry to Mac Kermit 0.8(34) Negative } Exit from Mac Kermit Stays Negative } Entry to MacTerminal Negative } Exit from Mac Terminal Positive }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. I don't know anything about positive and negative voltages or rs422 specs. I do, however, know a little about the serial drivers. The reason these terminal programs act this way is not that they are too dumb to close the serial driver. They use the old ROM Serial Driver, which you aren't supposed to close. Inside Mac II says "You shouldn't ever close the ROM Serial Driver with a Device Manager Close call. If you wish to replace it with a RAM Serial Driver, the RAMSDOpen call will automatically close the ROM driver for you." I'll get back to this in a minute. They are also not dumb enough to use the new _Control calls. These would only work with the new SERD resources, and most of these terminal programs predate the new SERD anyway. Anyway, back to the DTR problem. The old SERD and the 64K ROM serial drivers never negated DTR (logically, I don't know if that means positive or negative electrically). The new SERD in the 128K ROM drivers (and their corresponding resource file for use with 64K ROMs) fixed this "bug". Furthermore, Inside Mac IV says "In the 128K ROM, a single new Serial Driver replaces the RAM and ROM Serial Drivers." Now about those applications. Remember that MacKermit is written in SUMacC, which we all know is the most powerful, complete, up-to-date compiler for the mac. (In case you don't know about SUMacC, let me include a :-) here.) Since SUMacC predated the first definitive 64K ROM SERD, the RAM Serial Driver wasn't/isn't supported. So ROM calls were used. (Perhaps this will change when the LightSpeed C version of Kermit is released.) MacTerminal and other terminal programs usually come with SERD resources installed, so they issue RAM Serial Driver calls. Uw tries to survive in a world where the SERD may or may not be present. Therefore, uw probably makes ROM calls and gets to use the new SERD if 128K ROMs are present, but doesn't mind using the 64K ROMs if you don't have the new ROMs. So, that's why some terminal programs don't hang up the phone (negate DTR) when you quit. Brian H. Powell UUCP: {ihnp4,seismo,ctvax}!ut-sally!brian ARPA: brian@sally.UTEXAS.EDU _Work_ _Not Work_ Department of Computer Sciences P.O. Box 5899 Taylor Hall 2.124 Austin, TX 78763-5899 The University of Texas at Austin (512) 346-0835 Austin, TX 78712-1188 (512) 471-9536
curry@nsc.NSC.COM (Ray Curry) (11/26/86)
Don't forget that the rs232/rs422 world defines their signals as active (DTR) but the lines are all physical (DTR-). DTR- line being held low is active.
jdb@mordor.ARPA (John Bruner) (11/26/86)
> ... Uw tries to survive in a >world where the SERD may or may not be present. Therefore, uw probably makes >ROM calls and gets to use the new SERD if 128K ROMs are present, but doesn't >mind using the 64K ROMs if you don't have the new ROMs. Well, almost. UW tries to use the SERD driver. It calls RAMSDOpen first, and only if that fails does it use OpenDriver. Just before it exits, it calls RAMSDClose and then OpenDriver. As Brian Powell said, *Inside Macintosh* warns against closing the ROM serial driver because mouse interrupts can be lost. According to a comment in the code, I added the call to OpenDriver after RAMSDClose because when I left out this call, the mouse froze. (This is Megamax's RAMSDClose, which is (1) over a year old and (2) was outdated when I received it.) UW v3.4 does make the hold-DTR Control call to ensure that there is no glitch on the DTR line between the RAMSDClose and the OpenDriver, because it is intended that users be able to exit UW, restart it, and resume a modem-connected terminal session. BTW, UW is in a holding pattern right now. I've just purchased Lightspeed C and I'm thinking seriously about MPW C. I'm going to convert it to one of those (I'd like to use both -- LSC for prototyping and MPW C for final code quality, but C implementations on the Mac don't seem to be very compatible). I don't plan to make any additional major changes to the Megamax version. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
peter@aragorn.OZ (Peter Horan) (11/27/86)
In article <3897@nsc.NSC.COM> curry@nsc.UUCP (Ray Curry) writes: >Don't forget that the rs232/rs422 world defines their signals as active (DTR) >but the lines are all physical (DTR-). DTR- line being held low is active. This is not correct for control lines like DTR. From the standard EIA RS232C Aug 1969: Notation Interchange Voltage Negative Positive Binary State 1 0 Signal Condition Marking Spacing {the data lines} Function OFF ON {lines like DTR} So data lines are negative logic, whereas control lines are positive logic. Peter Horan ACSnet: peter@aragorn.oz Division of Computing and Mathematics UUCP: {seismo,ukc,mcvax}!munnari! Deakin University aragorn!peter Geelong ARPA: peter%aragorn.oz@seismo.edu.gov Victoria +61 52 471234 Australia 3217 (052) 471234