Article View: net.micro.atari16
Article #1521Re: Modem Info
From: jhs
Date: Thu, 14 Aug 1986 00:47
Date: Thu, 14 Aug 1986 00:47
77 lines
4865 bytes
4865 bytes
Jim:
I believe you are confusing a "null modem" connection with a normal data
terminal to modem connection.
The kind of cross-connection you are using is appropriate when you are
connecting two terminals together, or a computer, which is a "smart" kind of
terminal, to an ordinary terminal. In that case you DO want each Receive Data
input to look at the other's Transmit Data output. A cross-connecting device
called a "null modem" is used for this purpose, and to cross-connect several
of the other control lines as you were trying to do in your setup. Basically,
a null modem acts like two back-to-back modems, which would have to be used if
the two terminals were not physically close enough to connect directly. But
of course it is A LOT CHEAPER than two modems, back to back or otherwise!
However, in your case, you don't have two terminals; you have one terminal and
one modem or "Data Set". And I believe that you want to connect the
terminal's (Atari's) Transmit Data output line to the Transmit Data INPUT of
the modem so it can transmit it (what else?!). Similarly, you want to connect
the modem's Receive Data OUTPUT to the Atari's Receive Data input.
Also, the ST's Request To Send output should not be connected glaring face to
face with the modem's Clear To Send output. Each output on one side should go
to some input on the other side. One output can go to several inputs,
including one back on its own side if necessary. Since the modem apparently
does have a Clear To Send (CTS) output, one possibility would be to tie that
to the ST's Clear To Send output in the hope that both vendors are trying to
do something standard. Tying DTR's together seems wise for the same reason.
Since the modem is not a data terminal, this an input which it expects to see
from the data terminal (Atari). This leaves the ST's Request To Send (RTS)
dangling, assuming that as you indicate the modem has no input to receive it.
If things don't work in this way, the other reasonable possibility I see would
be to leave the modem's CTS line dangling and strap the ST's RTS back to its
CTS input. I am reasonably sure that this will do the trick. In fact, I
kinda like this better than using the modem's CTS line -- if you do it the
second way, at least you KNOW the Atari will be given CTS permission if it
ever requests it (RTS).
Once you have adhered to the above general rule of no two outputs tied
together, the only other problem in the RS-232 "standard" is that sometimes
both sides are waiting for the other to "assert" (turn ON) a signal, most
often DTR and DSR. In such a case, you might have to strap a signal that you
are SURE is on (by measuring it with a voltmeter!) to one of the inputs (after
disconnecting that input from any other source to follow the above rule) that
is waiting for a signal.
Anyway, my best guess for a workable arrangement would be as follows:
Your current connection Recommended connection
ST Datec ST Datec
-- ----- -- -----
(terminal) (modem)
GND ----------- GND GND ----------- GND
TXD ->-------<- RXD TXD ->------->- TXD *
RXD -<------->- TXD RXD -<-------<- RXD *
RTS ->-------<- CTS * RTS ->, (NC)<- CTS *
|
CTS -<---------------, ? I think * CTS -<'
SIG ----------- SIG | this is what SIG ----------- SIG
DCD -<-------<- DCD | you mean. DCD -<-------<- DCD
DTR ->------->- DTR--' * DTR ->------->- DTR *
RNG ----------- RNG RNG ----------- RNG
(no DSR) (no RTS) (no DSR) (no RTS)
The *'s indicate pins affected by the change.
If I sound as though I know what I am talking about, don't be fooled: only the
electrons know for sure!!!! Other connections are possible, as long as you
follow the general rules mentioned above; in fact you may find a better one.
But I hope this discussion helps you figure out how to get your setup working.
Good luck with it,
-John Sangster
jhs@mitre-bedford.arpa
Technical Details
Message-ID:
<8608132230.AA09612@mitre-bedford.ARPA>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!nbires!hao!hplabs!ucbvax!MITRE-BEDFORD.ARPA!jhsReferences:
<8608121246.AA00671@ncsc.ARPA>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!nbires!hao!hplabs!ucbvax!MITRE-BEDFORD.ARPA!jhs From: jhs@MITRE-BEDFORD.ARPA Newsgroups: net.micro.atari16 Subject: Re: Modem Info Message-ID: <8608132230.AA09612@mitre-bedford.ARPA> Date: Wed, 13-Aug-86 20:47:34 EDT Article-I.D.: mitre-be.8608132230.AA09612 Posted: Wed Aug 13 20:47:34 1986 Date-Received: Thu, 14-Aug-86 10:14:30 EDT References: <8608121246.AA00671@ncsc.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 77