From: rfall@mv.us.adobe.com (Richard Fall)
Newsgroups: comp.dcom.modems
Subject: Re: Why is this modem cable's DTR mapped to RTS?
Date: 8 Sep 92 22:12:08 GMT
Followup-To: comp.dcom.modems
Organization: Adobe

In article <1992Sep6.050516.4767@news.columbia.edu>,
ia4@cunixa.cc.columbia.edu (Imran Anwar) wrote:
> 

    [....]

> But , despite attempts, we could not figure out what was happening.  I did
> remember that the program ONLY works with a modem cable the company gave.
> And one of the things I noticed between this and other modem cables I had
> was that with it the Modem Ready light and CTS come on but NOT the DTR light.
> 
> Interestingly, when this cable is hooked to the Worldblazer the RTS light
> comes on (the Trailblazer Plus does not have an RTS light or I would have
> noticed this sooner). instead of the DTR light.  When I make any other
> communications program eventhen the RTS light comes on instead of DTR.  And
> "inverting DTR" in the application makes the RTS light go on and off.

I'm a little confused by what you've described, but it sounds to me very
much like you've got a problem with the setup of your WorldBlazer and/or
you serial cable.

Let me see if I can help by providing an explanation first:

The Mac serial port has a limited number of pins available for its use.
For this reason, there is only _one_ signal available for _any_ handshaking
use--it's a signal called "Handshaking Out (HO)".

Depending on the communications program you use, this signal may, in
general, be used for one of two purposes:  either as a means to signal
the modem to reset/go into command mode, or as a means to provide hardware
flow control from the modem to the Mac.

In the former case, this is done by connection HO to the DTR pin of the
modem, and configuring the modem to treat a deassertion of this signal
in the appropriate manner (see the documentation for your WorldBlazer
and refer to the &D register settings--you probably will want to set
&D1, &D2,or &D3 for this mode).  In this case, however, since there is
nothing connected to RTS, you must tell the WorldBlazer to ignore the
signal level on the RTS pin, by setting S58 equal to 0 or 3 (no flow
control, or XON/XOFF flow control, respectively).  You must be sure,
however, that the communcation program is using HO in the fashion, since
if it uses this signal for flow control, the modem will drop the
connection or drop into command mode the first time it sees DTR go
away;  probably not what the program meant to do.

In the case where the comm package uses HO for hardware flow control,
you must connect HO to RTS, and tell the modem to use RTS/CTS flow control
(S58 = 2 and S68 = 2 or 255), and you must also tell it to assume that
DTR is asserted all the time, since there will be no signal driving it
(&D0).

In general, you're better off using RTS/CTS flow control, since many
file transfer protocols assume a clean 8-bit data path, end to end, and
won't "like" seeing XON/XOFF characters disappearing from the data
stream, as they're interpreted as flow control characters by the other
modem.

There is an equivalent situation, BTW, with regard to input handshaking
to the Mac--a signal called "Handshaking In (HI)" is available for use
either as a signal from the modem for certain events (usually used as
a DCD indication) or as flow control in the other direction (CTS).

So, bottom line, you need to know what your comm program wants to use
HO/HI for, and wire and set S-registers appropriately.

> That really suprises me.  Could this have any implications for fast data
> transmission, because when I use ordinary hardware cables with the
> Trailblazer or with the WorldBlazer and send data to the same numbers in
> Pakistan with any other standard program like White Knight, Microphon etc
> using X-, Y- or Z-modem in all the cases the file transfers fail, or
> achieve 80 cps or even lower :-(

You bet.  If hardware flow control is not set up correctly, but the
comm package expects it to be, you will be overrunning the receiving
modem, and retranmitting packets, lowering throughput.

> I am totallyt confused if it is just some super programming that they
> employed and is it related to DTR/RTS switching on the cable or is that
> kjust a trick to sell expensiuve cables.  The company is in England
> and they want about $5000 yes that is $5000 for an UPGRADE!

Well, several companies seem to use this as an excuse to tell you that you
need to buy an expensive serial cable to work with high-speed modems, but
you could just as easily wire one yourself.

BTW, I try to solve this problem in a slightly different way, since I have
comm packages that work both ways I've described above.  I have created  a
pair of WorldBlazer settings, once for each, and have the comm program
pick the right one when it initializes the modem.  The cable I use has
HO wired to _both_ DTR and RTS.  When I want to use hardware flow control,
I set S58=2, S68=255, and &D0, and the modem ignores the transitions on
DTR.  When I want to use XON/XOFF flow control, and have the comm program
be able to drop the connection by lowering DTR, I set S58=3, S68=255, and
&D2.  The transitions on RTS are then ignored.

In fact, several commercial cables are wired this way (DTR and RTS wired
together) causing no end of confusion for some.

Unfortunately, it's not possible to do the same for the input direction to
the Mac, so I simply have CTS on the modem connected to HI.  I can't
then "see" DCD at the Mac, but that's a minor annoyance.

> The program shows that it is based on the Think C libraries so I am not
> evenm sure if the Think C code has some such standard high speed data
> transmission routines.
> 
> Hope people on the net can please help me out with this.
> 
> Thanks
> 
> Imran

I hope this explanation helps.  Good luck.

 +--------------------------------+-----------------------------------+
 |  Richard Fall                  |  Voice:  (415) 962-4889           |
 |  Adobe Systems, Incorporated   |  Fax  :  (415) 903-9652           |
 |  P.O. Box 7900                 |-----------------------------------|
 |  1585 Charleston Road          |  Internet:  rfall@mv.us.adobe.com |
 |  Mountain View, CA  94039-7900 |  UUCP:    ..!decwrl!adobe!rfall   |
 +--------------------------------+-----------------------------------+