By "antique" I mean modems with speeds of 14.4 kbps or less. Many
of them were made in the 1980s. Faster modems are also included if
they use a proprietary protocol. This appendix compares the
antique modems with the modern ones. You should read it if you are
interested in modem history or are intending to actually use an
antique modem. Also, many modern modems and software still support
the old protocols and you might find that such old protocols have been
configured by mistake.
Prior to 1960, 110 bps modems were used for teletype
machines (like an electric typewriter only much more noisy). What one
typed at a teletype (or had saved on punched paper tape) could be
printed on a remote teletype located far away. No computer was
Then in 1960 AT$amp;T came out with a 300 bps modem (for use on it's
phone system). Such slow and expensive modems were later mainly
used for transmitting data between mainframe computers or for
connecting a dumb terminal to a mainframe computer over phone lines.
Many dumb terminals didn't even have a screen display, but printed on
paper what you typed at the keyboard along with responses from the
PCs and BBSs
With the advent of the personal computer (PCs) in the early 1980s,
one could use a modem to dial into a remote mainframe computer. In
this case, the PC was used like a dumb terminal. But now files could
be transferred and one PC could connect to another via modems.
The 1980s saw the rise of the Bulletin Board System (BBS). A BBS was
just a computer with a modem listening for incoming calls. The public
could dial up a BBS with a modem and then download free software,
participate in discussions on various topics, play on-line games, etc.
Dialing in to a BBS was something like going to an Internet site.
Except that to go to another BBS site, you would need to dial another
number (and possible pay long distance telephone charges). Many BBSs
would have a monthly charge but some were run by volunteers and were
free. Many companies established BBSs for customers that contained
support information, catalogs, etc. In the early 1990s, BBSs were
booming. By the mid 1990s some even offered Internet connections.
For some history of BBSs see
Sysops' Corner: History of BBSing
Then came the advance of Internet in the mid 1990s which resulted
in the demise of the BBSs near the end of the 1990s. Some BBSs became
websites, but when BBSs were dying in droves, websites were quite
expensive so most BBSs just disappeared. The Internet contained far
more information than any one BBS could maintain so BBSs were no
Modems permitted the public to connect to the Internet. In the 1990s,
Modems became fast, cheap and widely used. Then in the late 1990s,
faster non-analog "modems" appeared: ISDN, DSL, and cable. The
history of these isn't in this HOWTO.
Before V.32 (9600 bps), modems typically had speeds of 300 to 2400
bps. Some super fast ones had much higher speeds (such as 19.2k bps)
and used non-standard protocols. To utilize these "fast" ones, both
modems for a connection needed to support the same proprietary protocol
which often meant that they must be the same brand.
Prior to the V.42 standard for error correction and the V.42bis (1990)
standard for data compression, the MNP standards were usually used for
both error correction and data compression. An X.PC error correction
standard was used on some commercial data networks. Compression and
error correction were available on some 2400 bps modems.
From 1960 to 1980 most modems only had a speed of 300 bps (which was
also 300 baud). This is only 0.3kbps. Modern modems are over 100
times faster. Some old-slow modems are still in use so they are not
really "antique" quite yet.
These were used in order to obtain higher speeds before more
standardized higher speeds became established. The modem at the other
end needs to support the same protocol for this to work. The dates
shown below may be only approximate.
PEP (Packetized Ensemble Protocol 1985): 18k (at best).
Turbo PEP: 23k 1994?
Hayes Express 96: 9.6k (Hayes 1987)
HST: 9.6k (US Robotics 1986)
HST: 14.4k (US Robotics 1989)
HST: 16.8k (US Robotics 1992)
V.32 terbo: 19.2k (AT$amp;T 1993)
V.FastClass: 28.8k (Rockwell 1993)
X2 :57.3k (US Robotics 1997)
K56: Flex 57.3k (Rockwell 1997)
The PEP used as much bandwidth as feasible by splitting the spectrum
into as many as 512 sub-bands. It was supported by Ven-Tel's
Pathfinder and Telebit's Trailblazer.
Modern modems negotiate the modem-to-modem speed and protocol when
they first connect to each other and normally connect to each other at
the highest possible speed. If one side can't negotiate, the other
side should accept whatever speed and protocol that the fixed side has
available. Except that some modern modems may no longer support some
of the antique protocols. As a result of negotiations, one modem may
need to use a lower speed than its maximum in order to communicate
with the other modem. This is sometimes called "autobauding" or
"automode". It might also be called "fallback". A more intuitive use
of the word "fallback" is where both modems automatically lower their
speed due to a noisy line. While autobauding is normally the default,
setting a fixed modem-to-modem speed instead of autobauding is done
with either an AT command like or by a register like S37.
Early modems didn't have such autobauding or fallback. If you have
such a modem, it will likely work OK if the other modem you connect to
is a modern one that can adjust it's speed and protocol to yours. But
a problem arises if both modems which want to communicate with each
other are both antique and don't support automode. In this case
they need to be manually set to the same speed and protocol.
Even when this automode existed, there was sometimes a limited
choice of speed (like only 1200/300 bps). In olden days (rarely
today), a computer dial-in site might have one phone number a certain
speed (like say 2400) and another phone number for a different speed
(say 1200). It was often not quite this simple as there might be a
few different phone number for one speed, or one phone number might
support say only a couple of speeds (like 1200/300). Also one phone
number might support only a certain protocol such as the Bell 212A
modem. Once a site obtained modems that could support a wider variety
of speeds and protocols, then there was no need to have different
groups of phone lines.
For old modems (mostly under 9600 bps) the modem-to-serial_port
speed had to be the same as the modem-to-modem speed. This was
because data flowed straight thru the modem without "speed buffering"
(storing bytes) inside the modem. This meant that both the modem's
serial port and the computer's serial port had to be set to this
speed. That is, both ends of the serial cable had to be set for this
One might erroneously reason that if the serial port speed was higher
than the modem-to-modem speed, all would work OK since then there
would be no bottleneck in the serial line. This works OK in the
direction from the modem to the PC since a higher speed line can have
a lower thruput speed due to greater time spacing between bytes. But
disaster strikes for the flow from the PC to the modem since it would
flow into the modem at a speed faster than the modem could transmit
the data. Data would be lost since there is no speed buffering.
If a modem had only one modem-to-modem speed (or was set by
software or physical switches to only operate at one speed), then this
wasn't a problem since one would just set the PCs serial port for this
speed. And the modem would set it's serial port for this speed.
Another way make the speeds equal is for the modem to detect the PC's
serial port speed and then set both it's serial speed and it's
modem-to-modem speed the same. This will be explained later.
But for modems that used more than one modem-to-modem speed there's a
problem. In that case it's not known in advance at what speed the
modem will connect to another modem. For example, if a fixed speed
modem dialed in to you modem and your modem supported the remote
modems fixed speed, then that's the speed it would connect at. If the
PC's serial port speed had been previously set to a different speed,
then this speed needs to be changed.
But setting the computer's serial port to the modem-to-modem speed was
a problem since the modem has no way to directly give commands to the
PCs serial port to change it's speed. Only system software can do
that. The modem finds out what speed to use based on negotiations
with the other modem and thus the change of this serial port speed
can't be done in advance. How does the modem communicate its
modem-to-modem speed to the system software?
Use "CONNECT" message to set speed
Here's one way to do it. Consider the case of a dial-in modem that
others dial into. A getty program will be used to send a login prompt
thru the modems to a user's terminal screen. Getty will also be the
system software that changes the speed of the serial port. The modem
will tell getty what modem-to-modem speed it's using by sending getty
a "CONNECT" message giving the modem-to-modem speed (such as "CONNECT
But there's one problem here. How does one insure that the "CONNECT"
message, which the modem sends to getty via the serial port, is sent
at the same speed as the PC's serial port which is expecting a
"CONNECT" message? Here's how it's done.
When the modem is first sent an init string, the modem detects the
speed of the computer's serial port and sets it's modem-to-serial_port
speed to this value. Now it can communicate with getty and the
"CONNECT" message can get thru.
To sense the speed the modem has examined the "AT" at the beginning of
the string. This is sometimes also called autobauding. For modern
modems, this same modem-to-serial port speed is always retained, even
after the modem connects to another modem and regardless of what the
modem-to-modem speed is. But for our old modem this initial serial speed
may need to be changed later to that of the modem-to-modem speed once
a connection is made.
For example, getty gets a CONNECT 2400 from the modem and switches the
PC's serial port speed to 2400. The modem also switches its serial
port speed to 2400. Now both ends of the modem serial cable are at
2400 and there is no speed mismatch. Then getty sends a login prompt
out over the phone line thru the modems. The 2400 bps is now both the
modem-to-modem speed and the modem-to-serial_port speed. Problem
solved. Mgetty can do this by configuring it for "autobauding" but
it's only of use for very old (and slow) modems.
For dialing out, the same method is used, but now the communication
software must handle it instead of getty.
Setting modem-to-modem speeds by the serial speed
Another way to switch modem-to-modem speed was by using a
modem feature where the modem would set its modem-to-modem speed to be
the same as the modem-to-serial port speed it detected. The Bn AT
commands would enable this and determine what protocol to use for each
speed. So with this enabled, setting the serial speed by the computer
would also set the modem-to-modem speed to be the same. This should
result in this modem being inflexible in any speed negotiations
between the modems.
Another (but cruder) way to solve the serial speed problem when
dialing in to a site was to get the remote site to change it's
modem-to-modem speed to match your serial port speed. It works like
this: The person trying to login over a modem connection doesn't see
any login prompt because of a speed mismatch. So the person trying to
login hits a "break" key to send a break signal over the phone line
(via modem) to getty on the remote machine. A break signal will
always get through even if there is a speed mismatch in a serial line.
The remote getty gets this break signal and switches the remote's
serial port to the next speed as specified in its getty configuration
file. This new remote serial port speed causes the remote modem to
switch to the same modem-to-modem speed as previously configured by
the ATB command. Then the local modem would transmit the login prompt
over the local's serial line at this speed. If one doesn't see a
login prompt, then they hit the break key again and a new speed is
tried. This continues until the remote getty finally gets the speed
correct (equal to the serial speed set on the local PC) and a login
prompt finally displays. Note that PC keyboards have no "break" key
but dumb terminal keyboards did. Mgetty, agetty, and uugetty can do
this obsolete break method and it's called "manual bauding".
In Linux, there's a problem if the speed is set to a speed not
supported by Linux's serial port (for example 7200 bps). You may dial
out and connect at 7200 bps (both modem-to-modem and
modem-to-serial_port speed) but you only see garbage since Linux
doesn't support 7200 on the serial port. Once you connect there is no
simple way to hang up because even the +++ escape sequence can't be
sent to the modem over a 7200 baud interface.
Modern modems, speed buffering
To dial out by the antique method using some modern modems set
&Q0 N0 and S37=5 (if you want 1200 bps). Some of the S17 settings
vary with the make of modem. S37=0 is the default that connects the
modern way at the highest speed supported.
Modern modems can use almost any serial port speed. It doesn't
depend at all on modem-to-modem speed. To do this, they employ speed
buffering and flow control. Speed buffering means that modems have
buffers so that there can be a difference between the modem-to-modem
speed and the modem-to-serial_port speed. If the flow entering the
modem is faster than the flow exiting it, the excess flow is simply
stored in a buffer in the modem. Then to prevent the buffer from
overflowing, the modem sends a flow control signal to stop the input
flow to it. This is true for either direction of flow. See
Flow Control for more details.
Hayes introduced the AT command set and other modem manufacturers
adopted it as a standard. Before the AT commands, many modems used
dip switches to configure the modem. Another command set is the CCITT
V.25bis command set. Some modems supported both CCITT and AT
commands. The CCITT V.25bis also specifies how Synchronous
modem-to-serial_port communication is to take place using either the
ASCII or 8-bit EBCDIC character sets.
This is where one connects a modem to a telephone using audio tones
that one can hear. The modem contains a microphone and speaker which
"talks" directly into the telephone handset without using any wires.
It's "wireless" in a sense but uses sound waves instead of radio
waves. The modem speaker is placed in contact with the telephone
microphone (on the handset) so that the tones from the modem go into
the telephone. The modem microphone, picks up tones from the
telephone handset speaker. This scheme is called "acoustic coupling".
A major problem is that outside noises can interfere and cause
errors. The advantage is convenience: There are no cables to plug in.
Most modems that could do this were only 300 baud, but higher speeds
were used too. It's said that 9600 bps didn't work very well using