madler@pooh.caltech.edu (Mark Adler) (01/06/91)
I have sent out this old posting of mine three times in the last week,
so I decided to edit it a little for the new 68040 serial ports with
hardware flow control and repost it. Enjoy.
Mark Adler
madler@pooh.caltech.edu
People seem to be having problems getting their modems to work, so here
is how my modem is set up and how I use it (a public service message) ...
First off, I highly recommend that you obtain and read the documentation
from NeXT in their TechSupportNotes series called SerialPortDoc.wn. It
is complete, well-written, and even has pretty pictures of the DIN-8 and
DB-25 connectors. (You may have to do a Command-u in WriteNow to see the
pictures.) You can get it via anonymous ftp from cs.orst.edu in the
directory pub/next/documents/TechSupportNotes. (This doesn't apply to
68040 NeXT's--in that case, look in the online documentation for "serial".)
The modem on my NeXT works just honky-dory for both dial-in and dial-out.
I have an Everex/Abaton EverFax 24/96E. (The fax part won't work until I
get 2.0 and a new ROM and RAM for the modem to implement a Class II Fax
command set, but that's a different story ...)
CABLING
Given that the pins on the male DIN-8 connector look like this:
6 7 8
3 4 5
1 2
then my cable, which came with an EMAC (Everex) modem, is wired thusly:
DIN-8 DB-25 signal means direction
1 20 DTR data terminal ready to modem
2 8 DCD data carrier detect from modem
3 2 TD transmit data to modem
4 7 SG signal ground n/a
5 3 RD receive data from modem
6 NC
7 NC
8 NC
case case the metal connector housings and
probably the cable shield also
The NeXT documentation mentioned above says that pin 8 of the DIN-8
connector should be connected to pin 7 of the DB-25 (signal ground) along
with pin 4. Apparently this is not necessary. Pin 8 is labeled RXD+
implying that it's a return line for pin 5 (RXD-). Perhaps connecting
RXD+ to signal ground is necessary at baud rates higher than 9600, but at
9600, I see no errors in reception. If you are wiring your own cable,
you should follow the NeXT directions, but if you have a cable like mine,
it'll work. Pin 8 should *not* be connected ground for serial ports on
68040 NeXT's (see below).
Note that pin 2 on the DIN-8 is labeled CTS (clear to send) by NeXT.
Ignore that. It should be connected to DCD only. I bought a $5
Mac-modem cable off a clearance table that had pin 2 on the DIN-8
connected to both DCD (8) and CTS (5) on the DB-25 end! This cable did
not work. (If it weren't for the RS-232 standards concerning connecting
two outputs, it might have even damaged my modem.) If I wanted to use
this cable, I would have broken off pin 5 in the male DB-25 connector.
Late press: since this was originally posted, the 68040 NeXT's arrived
and have slightly different serial port connections. The above cabling
will work fine with the 68040 serial ports, so long as you *don't*
connect pin 8, as the documentation for the 68030 ports suggests. If you
also want to use hardware flow control, you will need to connect DIN pin
6 to the DB-25 pin 4 (RTS) and DIN pin 8 to DB-25 pin 5 (CTS). DIN pin 7
should remain unconnected.
MODEM CONFIGURATION
The important control signals are DTR and DCD. The modem needs to be
set up to respond to DTR and generate DCD in a specified way. When DTR
is asserted, the modem should allow auto-answer and respond to commands.
When DTR is deasserted, it should not allow the above, and also hang up
the phone if it was off-hook. The modem should assert DCD if and only if
a carrier is detected.
My modem's default behavior is to always assert DCD and to always ignore
DTR. I suspect that all modems for the Mac and PC world are this way,
since modem control is not needed in most cases. This default behavior
makes the modem/computer connection a little more robust to cable
variations. However, it's too limited for dial-in support.
You will most likely have to read your modem manual to change this
behavior. (Perish the thought.) On my modem, I used the command:
AT &C1 &D2 S0=5 &W0
The &C1 makes DCD reflect the carrier status and the &D2 makes the modem
respond as described above to DTR. The S0=5 tells the modem to answer
the phone after five rings (the default is S0=0, which doesn't answer at
all). Finally, the &W0 writes the configuration to the non-volatile RAM,
so the modem will always be this way when powered up.
If you want to use hardware flow control (only available on 68040 NeXT
serial ports), then you will also have to tell the modem to use RTS/CTS
flow control. You will have to (shudder) read the modem manual.
DIAL IN
For dialing in, I changed the ttydb line (I use port B for the modem) in
/etc/ttys to:
ttydb "/usr/etc/getty std.9600" vt100 on
where the 9600 is the speed to talk to the modem at, vt100 says to assume
the terminal dialing in is VT-100 compatible (you can leave this as
"dialup" to make no assumption), and the "on" enables dial-ins. If you
are using hardware flow control, I suspect you would also change the ttydb
to ttydfb, but I have not tried this.
For this change to take effect, you will need to reboot or send a message
to the init process by:
kill -HUP 1
Don't mess with the ttya or ttyb lines---they're for permenantly
connected terminals and do not allow sharing the port between dial-in's
and dial-out's.
DIAL OUT
For dialing out, I use Kermit 5A (4E and 4F also work fine) in a Stuart
window (Shell or Terminal also work fine, but there is no emulation in
Shell). My kermit command line is "kermit -l /dev/cub -b 9600" where the
"b" in "cub" selects serial port B, and the 9600 is the bit per second
rate. I use 9600 since MNP 5, which supports compression, can sometimes
require more than 2400 bps. It is important to use /dev/cua or /dev/cub
and not any /dev/tty* to allow sharing the port for dial-in and dial-out.
You may have to change the permissions on /dev/cua and /dev/cub to be
able to use them.
You can get the kermit source via anonymous ftp from watsun.cc.columbia.
Version 4E is in kermit/b, 4F is in kermit/ck4f, and 5A is in kermit/sw.
You can get Stuart from cs.orst.edu in pub/next/binaries. (In 2.0, the
new Terminal is a NeXT adaptation of Stuart.)
As a side note, kermit 5A supports large packets (over 9000 bytes) and
continuous transmission of packets with delayed acknowledgement, which
results in much faster transer rates when using kermit protocol
transfers.
SUMMARY
1. Make sure DCD and DTR are wired correctly on your cable, and that
CTS isn't wired (unless you are using hardware flow control on a
68040 NeXT--in that case wire RTS and CTS as noted).
2. Convince the modem to respond to DTR and generate DCD appropriately,
as well as answer the phone if it rings. (Also convince the modem
to use RTS/CTS flow control for a 68040 NeXT, if desired.) Save the
setup if you can.
3. Edit /etc/ttys and put in an "on" to enable dial-in's on the port
with the modem (ttyda for port A, ttydb for port B). Change the
baud rate and terminal type if desired. (If using hardware flow
control on a 68040 NeXT, change it to ttydfa or ttydfb.)
4. Use /dev/cua or /dev/cua with your communication program, NOT
/dev/ttya, /dev/ttyb, /dev/ttyda, or /dev/ttydb. You may have to
chmod the permissions on /dev/cu*. (If using hardware flow control
on a 68040 NeXT, use /dev/cufa or /dev/cufb instead.)
Good luck.madler@nntp-server.caltech.edu (Mark Adler) (05/18/91)
By popular demand, here is a repost of my modem notes. (Pascal: perhaps
you can put them somewhere and reference that location in the FAQ.)
Mark Adler
madler@tybalt.caltech.edu
---- about.modem ----
People seem to be having problems getting their modems to work, so here
is how my modem is set up and how I use it for dial-in and dial-out (a
public service message):
The modem on my NeXT works just honky-dory for both dial-in and dial-out.
I have an Everex/Abaton EverFax 24/96E. (The fax part doesn't and can't
work since it does not implement a Class II Fax command set, but that's a
different story ...)
First off, if you have it, read the online documentation. The keyword
"serial" will bring up all the relevant documents in Librarian. Of
particular interest is the zs(4) man page and 13_Peripherals/_Attaching
Modems.rtf. If you are still using 1.0 or 1.0a, instead get the Technical
Support Note SerialPortDoc.wn from one of the ftp sites.
Second, if you have NeXTStep 2.0, and you want to be able to dial-in to
your machine, you will need to upgrade to 2.1. There are lots of other
good reasons to go to 2.1, so do it anyway. Dial-in (and out) works in
1.0 and 1.0a also, if you're still back there in the dark ages.
CABLING
Given that the pins on the male DIN-8 connector look like this:
6 7 8
3 4 5
1 2
then my cable, which came with an EMAC (Everex) modem, is wired thusly:
DIN-8 DB-25 signal means direction
1 20 DTR data terminal ready to modem
2 8 DCD data carrier detect from modem
3 2 TD transmitted data to modem
4 7 SG signal ground n/a
5 3 RD received data from modem
6 NC
7 NC
8 NC
case case the metal connector housings and
probably the cable shield also
The NeXT documentation mentioned above says that pin 8 of the DIN-8
connector should be connected to pin 7 of the DB-25 (signal ground) along
with pin 4. Apparently this is not necessary. Pin 8 is labeled RXD+
implying that it's a return line for pin 5 (RXD-). Perhaps connecting
RXD+ to signal ground is necessary at baud rates higher than 9600, but at
9600, I get no errors in reception. If you are wiring your own cable,
you should follow the NeXT directions, but if you have a cable like mine,
it'll work. Pin 8 should *not* be connected ground for serial ports on
68040 NeXT's (see below).
Note that pin 2 on the DIN-8 is labeled CTS (clear to send) by NeXT.
Ignore that. It should be connected to DCD only. I bought a $5
Mac-modem cable off a clearance table that had pin 2 on the DIN-8
connected to both DCD (8) and CTS (5) on the DB-25 end! This cable did
not work. (If it weren't for the RS-232 standards concerning connecting
two outputs, it might have even damaged my modem.) If I wanted to use
this cable, I would have broken off pin 5 in the male DB-25 connector.
Late press: since this was originally posted, the 68040 NeXT's arrived
and have slightly different serial port connections. The above cabling
will work fine with the 68040 serial ports, so long as you *don't*
connect pin 8, as the documentation for the 68030 ports suggests. If you
also want to use hardware flow control, you will need to connect DIN pin
6 to the DB-25 pin 4 (RTS) and DIN pin 8 to DB-25 pin 5 (CTS). DIN pin 7
should remain unconnected. This is the way my new, handmade modem cable
is now wired for my upgraded 040 cube:
DIN-8 DB-25 signal means direction
1 20 DTR data terminal ready to modem
2 8 DCD data carrier detect from modem
3 2 TD transmitted data to modem
4 7 SG signal ground n/a
5 3 RD received data from modem
6 4 RTS request to send to modem
7 NC
8 5 CTS clear to send from modem
In general, any Mac modem cable will work for dial-out, some Mac modem
cables will work for dial-in and dial-out, but no Mac modem cable will
work with hardware flow control. Of course, you can cannibalize any
Mac modem cable and rewire it, as I did.
MODEM CONFIGURATION
The important control signals are DTR and DCD. The modem needs to be
set up to respond to DTR and generate DCD in a specified way. When DTR
is asserted, the modem should allow auto-answer and respond to commands.
When DTR is deasserted, it should not allow the above, and also hang up
the phone if it was off-hook. The modem should assert DCD if and only if
a carrier is detected.
My modem's default behavior is to always assert DCD and to always ignore
DTR. I suspect that all modems for the Mac and PC world are this way,
since modem control is not needed in most cases. This default behavior
makes the modem/computer connection a little more robust to cable
variations. However, it's too limited for dial-in support.
You will most likely have to read your modem manual to change this
behavior. (Perish the thought.) On my modem, I used the command:
AT &C1 &D2 S0=5 &W0
The &C1 makes DCD reflect the carrier status and the &D2 makes the modem
respond as described above to DTR. The S0=5 tells the modem to answer
the phone after five rings (the default is S0=0, which doesn't answer at
all). Finally, the &W0 writes the configuration to the non-volatile RAM,
so the modem will always be this way when powered up. These commands
seem pretty common for modern modems.
If you want to use hardware flow control (only available on 68040 NeXT
serial ports), then you will also have to tell the modem to use RTS/CTS
flow control. You will have to (shudder) read the modem manual. On my
modem, I used the command:
AT \Q3 \X1 &W0
where the \Q3 tells the modem to use bi-directional RTS/CTS flow control,
and the \X1 tells the modem to not use xon/xoff flow control (this allows
xon and xoff to pass through as normal data). These commands may be more
specific to my modem than the previous commands for DTR and DCD.
I recommend using hardware flow control if you have a 68040 NeXT and your
modem supports it. It is essential for reliable communication at 9600 bps
and above.
DIAL IN
For dialing in, I changed the ttyda line (I use port A for the modem) in
/etc/ttys to:
ttyda "/usr/etc/getty std.9600" vt100 on
where the 9600 is the speed to talk to the modem at, vt100 says to assume
the terminal dialing in is VT-100 compatible (you can leave this as
"dialup" to make no assumption), and the "on" enables dial-ins. See below
for why I use 9600 bps.
If you have a 68040 NeXT and are using hardware flow control, you need to
change the ttyda to ttydfa. The line in my /etc/ttys actually reads:
ttydfa "/usr/etc/getty std.9600" vt100 on
For any changes to /etc/ttys to take effect, you will need to reboot, or
tell the init process to re-read the ttys file by issuing this command (as
root):
kill -HUP 1
Don't mess with the ttya or ttyb lines---they're for permanently
connected terminals and do not allow sharing the port between dial-in's
and dial-out's. Leave them "off".
DIAL OUT
For dialing out, I use C-Kermit 5A in a Terminal window. You can use the
command line:
kermit -l /dev/cua -b 9600
where the "a" in "cua" selects serial port A, and the 9600 is the bit per
second rate. I use 9600 since MNP 5, which supports compression, can
sometimes require more than 2400 bps. It is important to use /dev/cua or
/dev/cub and not any /dev/tty* to allow sharing the port for dial-in and
dial-out. If you are using hardware flow control, like I do, then the
command is instead:
kermit -l /dev/cufa -b 9600
You can get a ready-to-fly compiled kermit 5A for 2.x from cs.orst.edu in
pub/next/binaries as kermit5a.170.bin20.tar.Z. You can extract the
kermit executable using the command:
zcat kermit5a.170.bin20.tar.Z | tar xvf -
and then put the kermit in a suitable directory (as root):
mkdirs /usr/local/bin
mv kermit /usr/local/bin
For kermit to have access to the /dev/cu* ports, it needs special
permissions. You can grant them (as root) using these commands:
chown uucp /usr/local/bin/kermit
chmod u+s /usr/local/bin/kermit
You should not do this to a pre-5A kermit (e.g. 4E or 4F). For earlier
versions of C-Kermit, you should instead change the permissions on
/dev/cu* to allow rw access to all. However, I'd recommend getting a
5A kermit.
You may need to "bootstrap" yourself into kermit by downloading it through
the modem. Here is a good technique: first, use cu to dial out:
cu -l /dev/cua -s 9600
and you will then be able to converse with your modem. In cu, at the
beginning of a line, you can use the ~? command to get a list of special
tilde commands. Like how to get out (~.). (By the way, in my opinion,
the "tip" program is too much of a hassle to use, at least if you are only
trying to get kermit.) Then dial up the host on which you have ftp'ed
kermit from (I will assume it is a Unix machine). Use uuencode to print
the binary:
uuencode kermit5a.170.bin20.tar.Z kermit5a.170.bin20.tar.Z
and when it is done, copy the contents of the Terminal window to an Edit
window and save it as a file. (If you are using 1.0 or 1.0a, you will
need to use Shell or Stuart, since Terminal in 1.0 does not scroll.) If
you have MNP modems at both ends, then you can uudecode the file and
you've got it. If not, then repeat the process and save it as a different
file. Use diff to find where the files disagree, and use an editor on the
host to see what those lines are supposed to be and fix them. However you
do it, check the transfer using the "sum" command on your machine and the
host on the uudecoded (.tar.Z) file.
SUMMARY
1. Make sure DCD and DTR are wired correctly on your cable, and that
CTS isn't wired (unless you are using hardware flow control on a
68040 NeXT--in that case wire RTS and CTS as noted).
2. Convince the modem to respond to DTR and generate DCD appropriately,
as well as answer the phone if it rings. (Also convince the modem
to use RTS/CTS flow control for a 68040 NeXT, if desired.) Save the
setup if you can.
3. Edit /etc/ttys and put in an "on" to enable dial-in's on the port
with the modem (ttyda for port A, ttydb for port B). Change the
baud rate and terminal type if desired. (If using hardware flow
control on a 68040 NeXT, change it to ttydfa or ttydfb.)
4. Use /dev/cua or /dev/cua with your communication program, NOT
/dev/ttya, /dev/ttyb, /dev/ttyda, or /dev/ttydb. (If using hardware
flow control on a 68040 NeXT, use /dev/cufa or /dev/cufb instead.)
5. For dialing out, use C-Kermit 5A in a Terminal window (or a Stuart
window, especially if you're still using 1.0 or 1.0a). Kermit needs
to be given permission by root to use the /dev/cu* devices.
Good luck.
---- end ----