Партнёры:
Хостинг:
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 current modems and software still support the old protocols and you might find that these have been configured by mistake.
Prior to 1960, 110 bps ( 0.11) modems were used for teletype machines (like an electric typewriter only much more noisy). 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 computer.
With the advent of the personal computer (PCs) in the early 1980s, the PC was used like a dumb terminal for connecting to mainframes. But now files could be transferred and one PC could connect to another.
The 1980s saw the rise of the Bulletin Board System (BBS). This was just a computer with a modem listening for incoming calls. The public could dial up a BBS with a modem and then downloadable free software, participate in discussions on various topics, play on-line games, etc. Dialing in to a BBS was something like 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. Also, the public was unwilling to pay for using websites like they previously paid for the use of BBSs. There were such a huge number of free websites to visit that subscription BBSs were no longer competitive.
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.
This term has a few different meanings. In general it means either the automatic adjustment of modem-to-modem speed or of modem-to-serial_port speed.
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. During negotiations, one modem often must use a lower speed than its maximum in order to connect with the other modem. This is sometimes called "fallback" since one modem falls back to a lower speed (although it never really used its higher speed modem-to-modem). This is also called "autobauding" or "automode". Sometimes fallback also happens when both modems automatically lower their speed due to a noisy line. Register S37 in a modem is normally set to enable autobauding but may also be set for a fixed modem-to-modem speed in some modems.
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 choices of speed (like only 1200/300 bps). In olden days (and even today), a computer dial-in site might have groups of phone lines, where each group which had a specific type modem on it which supported specific speeds and protocols. For example, if you had a 2400 bps Bell 212A modem then you simply only dialed in to certain telephone numbers that supported that speed and protocol. 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 speed.
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 time spacing between bytes. But disaster strikes for the flow from the PC to the modem since it would flow 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. Even if the modem had various modem-to-modem speeds which were set by negotiations with the other modem, there was no problem in setting the modem's serial port speed correctly. It would simply set this port speed to it's current modem-to-modem speed. Another way make the speeds equal is for the modem to detect the PC's serial port speed and then set it's modem-to-modem speed the same. This will be explained later.
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 chosen modem-to-modem speed to the system software?
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 login prompt thru the modems to users. Getty will also be the system software that changes the speed of the serial port and the modem will tell getty what modem-to-modem speed it's using. The modem will do this by sending getty a "CONNECT" message giving the modem-to-modem speed.
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? 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. The modem senses the serial speed by examining 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 serial speed needs to be equal the modem-to-modem speed.
So now, 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".
For dialing out, the same method is used, but now the communication software must handle it instead of getty.
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.
To dial out by the antique method using some modern modems set &Q0 N0 and S17=5 (if you want 1200 bps). Some of the S17 settings vary with the make of modem. S17=0 is the default that connects the modern way at the highest speed supported.
Modern modems can use almost any serial port speed and 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 the modem. 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 this scheme.
MNP 2, 3, or 4 were used for error correction. MNP 5 was compression. Modern modems generally use V42 (error correction) and V42bis (compression). Many modems support both MNP and V42.
END OF Modem-HOWTO
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |