Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!cbnewsj!davet
From: davet@cbnewsj.att.com (Dave Tutelman)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: null modem cable
Message-ID: <1991Jan27.155828.15236@cbnewsj.att.com>
Date: 27 Jan 91 15:58:28 GMT
References: <2582@s5.Morgan.COM> <8Fy4V2w163w@cybrspc> <3439@nosc.NOSC.MIL>
Distribution: usa
Organization: AT&T Bell Labs - Lincroft, NJ
Lines: 90

>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					|
+---------------------------------------------------------------+