joec@Morgan.COM (Joe Collins) (01/19/91)
Anyone know how to make an null modem cable or should I just go and buy one? What are the mechanics of xfering between one pc and another pc? I plan to use kermit at both ends to transfer my files from my older 8088 to my newer 386 25mhz. I don't need a modem (I'm sure) but what speed should I tell kermit its running at on the 8088 to get optimal data xfer rates? any other tips would be appreciated. many thanks joec@morgan.com
raymond@math.berkeley.edu (Raymond Chen) (01/20/91)
In article <2582@s5.Morgan.COM>, joec@Morgan (Joe Collins) writes: >Anyone know how to make an null modem cable ... The pinout for a null modem cable is given in the "comm" file in my comp.sys.ibm.pc.misc archives (ftp math.princeton.edu:pub/rjc/csip). Here is the relevant excerpt: [@(#)comm 1.3. Last updated 3/23/90] SERIAL PORTS AND THINGS To hook up a null modem 1 2 3 4 5 6 20 7 | | | | | | | | 1 3 2 5 4 20 6 7 In some cases you may have to tie 6 & 8 on the same end together as well. The "comm" file also contains assorted comments on how to get COM3 and COM4 set up, how to program the serial port, and what sort of UUCP packages exist for the IBM PC.
kdq@demott.com (Kevin D. Quitt) (01/22/91)
In article <2582@s5.Morgan.COM> joec@Morgan.COM (Joe Collins) writes: >Anyone know how to make an null modem cable or should More than you even wanted to know about RS232 cables: DB9 RS232 Pin Signal 1 CD Carrier Detect 2 RxD Received Data 3 TxD Transmitted Data 4 DTR Data Terminal Ready 5 SGnd Signal Ground 6 DSR Data Set Ready 7 RTS Request to Send 8 CTS Clear To Send 9 RI Ring Indicator DB25 RS232 Pin Signal 1 CGnd Case Ground 2 TxD 3 RxD 4 RTS 5 CTS 6 DSR 7 SGnd 8 CD 9-19 Not usually used 20 DTR 21-25 Not usually used RS232C Null-Modem Cable DB9 DB25 DB25 DB9 Pin Pin Pin Pin 1 8 CD DTR 20 4 2 3 RxD TxD 2 3 3 2 TxD RxD 3 2 4 20 DTR DSR 6 6 4 20 DTR CD 8 1 5 7 SGnd SGnd 7 5 6 6 DSR DTR 20 4 7 4 RTS CTS 5 8 8 5 CTS RTS 4 7 9 RI 1-6 6-8 6-8 1-6 <- Jumpers Note: If for some reason, you cannot jumper DSR to CD, connect DSR to the opposite DTR, and connect CD straight across (if possible). -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last
roy%cybrspc@cs.umn.edu (Roy M. Silvernail) (01/27/91)
koziarz@halibut.nosc.mil (Walter A. Koziarz) writes: > In article <8Fy4V2w163w@cybrspc> roy%cybrspc@cs.umn.edu (Roy M. Silvernail) w > >Here's a design that emulates a LapLink cable. I've used it with great > > It's never a good move to try to 'fake-out' hardware handshaking!!!!! Don't > it!! Presented below is *the RIGHT way* to make a null modem cable -- [both designs deleted] OK, I have filed your design along with mine. However, I'd suggest (if you're going to be fanatic about it) building _both_ versions. In my case, I used the null-modem to talk with a non-PC machine, and the software on the other end didn't speak hardware handshaking. In this instance, your design would fail to function, while mine would pass the data. > This is the correct wat to make a FULL-HANDSHAKING null modem; throw away > ANYTHING that tells you to use the 'other', fake-out connection. If faking the handshake really is "never a good move", why did LapLink do it? -- Roy M. Silvernail -- roy%cybrspc@cs.umn.edu - OR- cybrspc!roy@cs.umn.edu Department of redundancy department, or "Take the long way home...": main(){system("perl -e '$x = 1/50; print \"Still just my \\$$x!\n\"'");} [new year, new .sig, same ol' cyberspace]
etxsral@california.ericsson.se (Lars Nilsson) (01/27/91)
In article <3439@nosc.NOSC.MIL> koziarz@halibut.nosc.mil (Walter A. Koziarz) writes: >>Here's a design that emulates a LapLink cable. I've used it with great > >It's never a good move to try to 'fake-out' hardware handshaking!!!!! Don't do >it!! Presented below is *the RIGHT way* to make a null modem cable -- > >[1]------chassis GND--------[1] > >[2]-------------------------[3] > >[3]-------------------------[2] > >[4]-------------------------[5] > >[5]-------------------------[4] > >[6]------------------------[20] > >[7]-----signal GND----------[7] > >[8]-------------------------[8] > >[20]------------------------[6] > > >This is the correct wat to make a FULL-HANDSHAKING null modem; throw away >ANYTHING that tells you to use the 'other', fake-out connection. > >Walt K. Uhmm. Your solution seems good except for the pin 8 to pin 8 connection ,connecting an input to an input doesnt work so good. I usually connect pin 8 -- 6 to 20 in the other end. /Lars Nilsson -- Lars Nilsson Ericsson Telecom AB , Stockholm - Sweden E-mail: etxsral@california.ericsson.se Fidonet: Lars Nilsson @ 2:201/108.7
davet@cbnewsj.att.com (Dave Tutelman) (01/27/91)
>In article <8Fy4V2w163w@cybrspc> roy%cybrspc@cs.umn.edu (Roy M. Silvernail) writes: >>Here's a design that emulates a LapLink cable. I've used it with great >>success for over a year. Roy's accompanying diagram shows some through leads, some transposed leads, and some loopback leads. In article <3439@nosc.NOSC.MIL> koziarz@halibut.nosc.mil (Walter A. Koziarz) writes: >It's never a good move to try to 'fake-out' hardware handshaking!!!!! Don't do >it!! Presented below is *the RIGHT way* to make a null modem cable -- ... in which he shows basically a "straight-through" connection (with a few properly transposed leads). While Walter has philosophical right on his side, his solution won't work, either. There is no way to "do it right" without a REAL modem, (or an active, powered null modem with internal logic and option jumpers), but there is a way to get as close as possible to philosophical "right" by taking points from BOTH Roy and Walter. Here's what I've seen used successfully, and an explanation of why it works: [2]>--------\ TX /--------<[2] \ / / \ [3]<--------/ RX \-------->[3] [4]-----| RTS |-----[4] | | [5]-----| CTS |-----[5] [8]--\ CD /--[8] \ / [7]-----------GND-----------[7] \ / [6]---------\ DSR /---------[6] \ / / \ [20]--------/ DTR \--------[20] RTS / CTS (Request To Send / Clear To Send) There is one possible way that this "fake-out" could be misleading. Suppose the other end is unplugged, and your application doesn't check DSR. But Walter's solution also has a case that doesn't work. Suppose the applications think they're using half-duplex modems and are using these signals to turn the line around. In that case, the protocol breaks down completely, while Roy's solves the problem. DTR /DSR (Data Terminal Ready / Data Set [=modem] Ready) Looping back doesn't work, as Walter points out. These leads say that the other "thingy" on the interface is ready, so do it as a through-transpose. CD (Carrier Detect) Sorry Walter. Any software that even looks at this lead will break on your solution. It's an output lead from the local modem with no corresponding input lead (from this end OR the other end). There are two choices, of which I've shown one. They REALLY ought to be a jumper option. 1) Some software uses CD as an alternative to DSR, or an additional check that the modem is ready. The configuration I've shown works for that case. 2) Some software (using half-duplex protocols ONLY) uses CD as an additional check to CTS, to make sure the line is really turned around. The ONLY way to accurately implement this in a null modem is an ACTIVE null modem that presents CD as the inverse of CTS. Note that the two choices are mutually exclusive. The strap must be set to reflect the use the DTE (terminal or computer software) will make of the CD lead. This is, in fact, consistent with Walter's "don't fake it" philosophy. Any pair of modems will, in fact, either be operating Full-Duplex or Half-Duplex. Those operations are different in the way they use the RS-232 leads, and a null modem would have to be "jumperable" to reflect that. To be COMPLETELY accurate would require an active null modem, with logic on the leads, and at least one jumper (HDX / FDX). But the solution I've shown above works in the vast majority of cases. And the solutions presented by both Roy and Walter work on virtually all PC-to-mini and PC-to-PC connections of which I'm aware. Hope this helps, rather than just fanning the flames. Dave +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T Bell Labs - Lincroft, NJ | | Logical - ...att!pegasus!dmt == dmt@pegasus.att.com | | Audible - (201) 576 2194 | +---------------------------------------------------------------+
koziarz@halibut.nosc.mil (Walter A. Koziarz) (01/29/91)
In article <1991Jan27.123115.23732@ericsson.se> etxsral@california.ericsson.se (Lars Nilsson) writes: >In article <3439@nosc.NOSC.MIL> koziarz@halibut.nosc.mil (Walter A. Koziarz) writes: >>It's never a good move to try to 'fake-out' hardware handshaking!!!!! Don't do >>it!! Presented below is *the RIGHT way* to make a null modem cable -- >>[1]------chassis GND--------[1] >>[2]-------------------------[3] >>[3]-------------------------[2] >>[4]-------------------------[5] >>[5]-------------------------[4] >>[6]------------------------[20] >>[7]-----signal GND----------[7] >>[8]-------------------------[8] >>[20]------------------------[6] >>This is the correct wat to make a FULL-HANDSHAKING null modem; throw away >>ANYTHING that tells you to use the 'other', fake-out connection. > >Uhmm. Your solution seems good except for the pin 8 to pin 8 connection >,connecting an input to an input doesnt work so good. >I usually connect pin 8 -- 6 to 20 in the other end. >/Lars Nilsson Ah, but I'm *not* connecting an input to an input. A null modem is used when 'I've got an available DCE port and need to connect a DTE device' or vice versa. Examination of pin 8 [DCD] for a DCE device port (female on the computer) shows it to be an output. And for a DTE device port; it is an input. DCE -- printer; DTE -- modem in my context. I submit that my connection is indeed correct and valid. Walt K.
jc58+@andrew.cmu.edu (Johnny J. Chin) (01/29/91)
Excerpts From Captions of netnews.comp.sys.ibm.pc.hardware: 26-Jan-91 Re: null modem cable Walter A. Koziarz@halibu (1215) >It's never a good move to try to 'fake-out' hardware handshaking!!!!! Don't >do >it!! Presented below is *the RIGHT way* to make a null modem cable -- > >[1]------chassis GND--------[1] > >[2]-------------------------[3] > >[3]-------------------------[2] > >[4]-------------------------[5] > >[5]-------------------------[4] > >[6]------------------------[20] > >[7]-----signal GND----------[7] > >[8]-------------------------[8] > >[20]------------------------[6] > > >This is the correct wat to make a FULL-HANDSHAKING null modem; throw away >ANYTHING that tells you to use the 'other', fake-out connection. What about this cable then? I've been told by many many product manufacturers (including big cable companies ... ie. Black Box) that this is a "FULL HANDSHAKING null-modem cable": 1 ---- 1 (shielding ground) 2 ---- 3 3 ---- 2 4 ---- 5 5 ---- 4 6 -+-- 20 8 -+ 7 ---- 7 (signal ground) 20 --+ 6 + 8 (6 and 8 tied on each side to 20 on the other side) Any suggestions? What is pin-8 anyway? Thanks. __________ Carnegie Mellon University ___ / \ / / /_/ / /\/ _/ / / / "Happy Computing ..." __/. /__ / / / / / / / / -- Computer Dr. / / Internet: Johnny.J.Chin@andrew.cmu.edu / ------- / 4730 Centre Ave. #412 BITnet: jc58@andrew \__________/ Pittsburgh, PA 15213 UUCP: ...!uunet!andrew.cmu.edu!jc58
jc58+@andrew.cmu.edu (Johnny J. Chin) (01/29/91)
Excerpts From Captions of netnews.comp.sys.ibm.pc.hardware: 27-Jan-91 Re: null modem cable Roy M. Silvernail@cs.umn (1242) >If faking the handshake really is "never a good move", why did LapLink >do it? Laplink does it in order to avoid hardware control problems when you have serial ports on different speed computers talk to each other. A 386 talking to an 8088 will definitely have different handshaking signal timings. That is why data is checked via software with Laplink. __________ Carnegie Mellon University ___ / \ / / /_/ / /\/ _/ / / / "Happy Computing ..." __/. /__ / / / / / / / / -- Computer Dr. / / Internet: Johnny.J.Chin@andrew.cmu.edu / ------- / 4730 Centre Ave. #412 BITnet: jc58@andrew \__________/ Pittsburgh, PA 15213 UUCP: ...!uunet!andrew.cmu.edu!jc58
oeschi@netmbx.UUCP (Johann Deutinger) (01/30/91)
In article <3446@nosc.NOSC.MIL> koziarz@halibut.nosc.mil (Walter A. Koziarz) writes: >In article <1991Jan27.123115.23732@ericsson.se> etxsral@california.ericsson.se (Lars Nilsson) writes: >>In article <3439@nosc.NOSC.MIL> koziarz@halibut.nosc.mil (Walter A. Koziarz) writes: >>>It's never a good move to try to 'fake-out' hardware handshaking!!!!! Don't do >>>it!! Presented below is *the RIGHT way* to make a null modem cable -- >>>[1]------chassis GND--------[1] >>>[2]-------------------------[3] [other connections deleted ...] >>Uhmm. Your solution seems good except for the pin 8 to pin 8 connection >>,connecting an input to an input doesnt work so good. >>I usually connect pin 8 -- 6 to 20 in the other end. >>/Lars Nilsson > >Ah, but I'm *not* connecting an input to an input. A null modem is used when >'I've got an available DCE port and need to connect a DTE device' or vice >versa. Examination of pin 8 [DCD] for a DCE device port (female on the >computer) shows it to be an output. And for a DTE device port; it is an input. >DCE -- printer; DTE -- modem in my context. I submit that my connection is >indeed correct and valid. The nullmodem is a discussion item with quite a long history ;-) If you are connecting two similar pieces of hardware (and this is the typical reason to cross pins 2/3 and pins 4/5 and so on) you should expect both sides to use pin 8 (DCD) for the same thing, typically as input. The main point in this discussion is the difference between nullmodem and other serial connections. If you really want to create a nullmodem, that means, a replacement of an analog connection including two modems, there is only one solution: 2 - 3 - 2 4,5 - 8 (activates DCD from RTS at remote side - esp. for half duplex) 8 - 4,5 (vice versa) 6,20 6,20 This gives the response to RTS, which is CTS and to DTR, which is DSR. This would be normally done by the modem. If synchronous procedures should be used, additionally the clock lines (15,17,24) have to be connected the right way (too much info for this context) Looking at the history of this discussion the main application of such cables is not to replace two modems but to connect a computer to a peripheral device. For that application there is really no standard (some use hardware handshake, some not; some use DTR/DSR for handshake, some use RTS/CTS, some ignore DCD, some don't etc.) So all of the presented solutions work with some special setup. This misleads to thinking that it might be the only one! Hans -- oeschi@netmbx.UUCP | Johann Deutinger voice +49 30 396 50 21 | Ferrari electronic GmbH (.. no, we don't sell cars) fax +49 30 396 80 20 | Beusselstr. 27 - 1000 Berlin 21 - FRG
david@csource.oz.au (david nugent) (01/30/91)
jc58+@andrew.cmu.edu (Johnny J. Chin) writes: > Excerpts From Captions of netnews.comp.sys.ibm.pc.hardware: > 27-Jan-91 Re: null modem cable Roy M. Silvernail@cs.umn (1242) > >If faking the handshake really is "never a good move", why did LapLink > >do it? > Laplink does it in order to avoid hardware control problems when you have > serial ports on different speed computers talk to each other. A 386 talking > to an 8088 will definitely have different handshaking signal timings. That > is why data is checked via software with Laplink. Err, what has this to do with hardware timings? Hardware signals are controlled by software and are not intrinsic to the hardware itself.
jm9t+@andrew.cmu.edu (Josh Brian Mastronarde) (01/30/91)
Excerpts From Captions of netnews.comp.sys.ibm.pc.hardware: 28-Jan-91 Re: null modem cable Walter A. Koziarz@halibu (1410) >In article <1991Jan27.123115.23732@ericsson.se> etxsral@california.ericsson.s >e (Lars Nilsson) writes: >>In article <3439@nosc.NOSC.MIL> koziarz@halibut.nosc.mil (Walter A. Koziarz) > writes: >>>It's never a good move to try to 'fake-out' hardware handshaking!!!!! Don' >t do >>>it!! Presented below is *the RIGHT way* to make a null modem cable -- >>>[1]------chassis GND--------[1] >>>[2]-------------------------[3] >>>[3]-------------------------[2] >>>[4]-------------------------[5] >>>[5]-------------------------[4] >>>[6]------------------------[20] >>>[7]-----signal GND----------[7] >>>[8]-------------------------[8] >>>[20]------------------------[6] >>>This is the correct wat to make a FULL-HANDSHAKING null modem; throw away >>>ANYTHING that tells you to use the 'other', fake-out connection. >> >>Uhmm. Your solution seems good except for the pin 8 to pin 8 connection >>,connecting an input to an input doesnt work so good. >>I usually connect pin 8 -- 6 to 20 in the other end. >>/Lars Nilsson > > >Ah, but I'm *not* connecting an input to an input. A null modem is used when >'I've got an available DCE port and need to connect a DTE device' or vice >versa. Examination of pin 8 [DCD] for a DCE device port (female on the >computer) shows it to be an output. And for a DTE device port; it is an inpu >t. >DCE -- printer; DTE -- modem in my context. I submit that my connection is >indeed correct and valid. > >Walt K. Bzzt. DTE stands for Data Terminal Equipment, such as a computer or VT100 terminal, etc. i.e. It transmits on pin 2 and receives on pin 3. DCE stands for Data Communications Equipment, such as a modem. DCE transmits on pin 3 and receives on pin 2 (those might be reversed, I'm not sure, but that's not important). Many (most?) serial printers are set up as DTE, god knows why (so you can connect your printer to your modem, perhaps :-). When making a null modem cable, almost all of the pins have a corresponding input/output pin (transmit-receive, RTS-CTS, DTR-DSR). However, DCD (data carrier detect) doesn't have such a partner. It is always an input from the DTE's point of view. So, connecting the pin 8's together does indeed connect an input to an input. Fortunately, the concept of carrier detect is lost when connecting two computers, so you should connect DCD to pin 20 (DTR). Hope this clears things up. -Josh Mastronarde -jm9t+@andrew.cmu.edu
pwong@batcomputer.tn.cornell.edu (Patrick Wong) (01/31/91)
In article <11184@uhccux.uhcc.Hawaii.Edu> robin@uhunix1.uhcc.Hawaii.Edu (Robin Amano) writes: > > ------------------------(lines deleted)............. > > I'd have to side with Lars on this one. By what you are > saying above, and looking at your diagram above I'd have > to say that your connection is invalid. Most of the time > you use a null modem cable for DTE to DTE. In the old days, > actually not that old, when computer ports weren't as > flexible they looked like a DTE expecting a modem or > communication device to be hooked up to it. So, when hooking > up a terminal you would use a null modem cable to make each > device look like a communication device to each other, although > they were actually terminal devices, thus crossing 2 & 3. > Above you are talking about hooking up a terminal device(DTE) > to a communication device(DCE), but your wiring diagram > crosses pins two and three. I'd say your connection is > indeed incorrect and invalid. And as far as 'fake-out' > that's exactly what a null modem, or sometimes called modem > eliminator, is for to fake out the DTE into thinking there > is a modem or communication device connected to it. So, > for those of you who haven't seen Lars' cable > > 2 -------------- 3 > 3 -------------- 2 > |-4 4-| > |-5 5-| > 7 -------------- 7 > |-20 -------------- 20-| > |--8 8--| > |--6 6--| > > I think this is what he layed out. This is what we use. > So, if you don't want to use a breakout box to figure out > the exact pin configuration try this. Remember DTE to DTE > or DCE to DCE cross 2 & 3, DTE to DCE 2 & 3 straight through. > > >-- >-------------------------------------------------------- > Robin Amano | robin@uhunix.uhcc.hawaii.edu > UHCC | Data Communications Dept. > 2565 The Mall | Honolulu, HI 96822 Just to add confusion to the net. I opened up a el cheapo "RS232 NULL MODEM" sold by CompuAdd and here is what I find: 2 ------ 3 3 ------ 2 |-4 4-| |-5 5-| 7 ------ 7 |-20 20-| |--8 8--| |--6 6--| Note that there is no interconnection between any of 6,8,20 pins on one side to any of the same set of pins on the other side. But, what the heck. I have used it in connecting a pc to a serial printer and also connecting two pc's. It works in both cases and I am not going to loose sleep over it. One thing thou, if I am going to make a NULL MODEM, I will most likely follow the cable manufacturers' suggestion (e.g., Black Box catalog's diagram, etc.) Have fun in searching for the ultimate null modem! Patrick pcw@squid.graphics.cornell.edu
robin@uhunix1.uhcc.Hawaii.Edu (Robin Amano) (02/01/91)
In article <1991Jan31.140137.25101@batcomputer.tn.cornell.edu> pwong@batcomputer.tn.cornell.edu (Patrick Wong) writes: > >Just to add confusion to the net. I opened up a el cheapo "RS232 NULL >MODEM" sold by CompuAdd and here is what I find: > > 2 ------ 3 > 3 ------ 2 > |-4 4-| > |-5 5-| > 7 ------ 7 > |-20 20-| > |--8 8--| > |--6 6--| > >Note that there is no interconnection between any of 6,8,20 pins on one >side to any of the same set of pins on the other side. > >Have fun in searching for the ultimate null modem! > >Patrick >pcw@squid.graphics.cornell.edu This cable will definitely work also. Although if you are using hardware flow control you may have problems, because there is no control line. But, if you use xon/xoff it should be fine. Although a lot of times if the devices are using xon/xoff a three wire hook up is all that is needed 2,3, & 7. But, by all means not all the time. RS232 is standard in a sense that you could guess and make it work or in tough situations, if you have a breakout box you could figure it out, 'cuz not every manufacturer does it exactly the same. I remember on a pc using yterm going to a starmaster(pacx) switch we had to use the 4-5, 6-8-20 jumpers on the pc end because yterm was looking for a modem. When we hooked up a ps/2 to the switch using yterm, it wouldn't work. We found that pin 8 was pulling down pin 20, we snipped off 8 and it worked fine. So, we use that pinout as a time saver or if we don't have a manual, because most of the time it will work. If it doesn't work, then we'll go in with a breakout box and modify it a little. Well, goodluck! what are we talking about this for anyway? -- -------------------------------------------------------- Robin Amano | robin@uhunix.uhcc.hawaii.edu UHCC | 2565 The Mall | Honolulu, HI 96822