jhs@MITRE-BEDFORD.ARPA (11/27/87)
Steve Kaufmann asks why his file transfers don't work. I think the problem lies in the subtleties of the rs-232 standard and in particular the way he has hooked up his Clear To Send (CTS) inputs. Here's my theory... >> AT ATARI KEY (COMMENTS ADDED BY JHS) >> 1 --------------- 1 1 = GND Grounds tied together, OK. >> 2 --------------- 3 2 = TX AT sends, ST listens, fine. >> 3 --------------- 2 3 = RX Vice versa, also correct. >> 4 --------------- 5 4 = CTS AT is looking for Clear to >> 5 --------------- 4 5 = RTS*** Send but on wrong line!!! >> 6 --------------- 20 6 = DTR ? | >> 7 --------------- 7 7 = GND | >> 8 --------------- 20 8 = DSR ? | >> 20 --------------- 6 20 = DCD ? |-- looks OK. >> 20 --------------- 8 | What makes these terminal-to-terminal connections (remember, a computer is a terminal, a modem is a "DATA SET") so confusing is that the signal names assume we are dealing with a nice, cooperative team consisting of one each terminal and modem. When you go direct between two computers, you have TWO terminals and NO modems. All bets are off. There are two levels of inconsistency that have to be dealt with somehow. The first level is electrical: you have to make sure that whatever collection of pins you hook up, there is precisely ONE SOURCE and all the rest are INPUTS. As far as I can see, Steve has done that much correctly. At the next level, you have to make sure that the SEMANTICS of the signals are reasonable. What appears to me to be wrong is at this second level of subtlety: Clear To Send (CTS) on each side is being fed by Request To Send (RTS) on the other side. (Pin 4 on one side hooked to 5 on the other.) What this means is, if one side wants to Send, it will look for Clear To Send, but this will not be asserted (activated) unless the *OTHER SIDE* is asking permission to send (asserting RTS) at the same time!!! Clearly this is not reasonable. Some other arrangement is needed. When we are looking for Clear To Send, what logic line would the other terminal be asserting that we could look at to ascertain that it was well and truly ready to receive data? And while we are at it, what should we do before we look for Clear To Send? There may be other variants, but the following should work. When we want to send data, we assert Request To Send. Hook this to Data Carrier Detect (DCD) on the far side. OK, we ask to send, but this comes in on the other side as a signal that the (non-existent) modem just received a carrier. Any reasonable, right-thinking terminal emulator should start getting interested in receiving data under these conditions, right? We can also hook our Request To Send right back to our OWN Clear To Send so that requests to send are always granted. Or we can feed our Clear To Send with the far side's Data Terminal Ready (DTR) signal, to ensure that a terminal is in fact hooked up and powered up. That's probably the best way to do it. In other words, hook 5 (RTS) on one side to 20 (DCD) on the other, and hook DTR (Pin 6) on the far side back to 4 (CTS) on our side. Probably each Pin 6 should also go to the opposite Pin 8, so that each side's DTR looks like a modem's DSR to the other. I.e. each side's DTR (6) feeds the other side's DSR (8) input and its own CTS (4) input, and each side's RTS (5) feeds the other's DCD (20). I think that will fix Steve's problem, provided that both sides assert DTR without waiting around for something else to happen first. Then again, "only the electrons know for sure!". -John Sangster, jhs@mitre-bedford.arpa