Classic Computer Magazine Archive COMPUTE! ISSUE 23 / APRIL 1982 / PAGE 130


How To Use A Modem

Michael E. Day
Chief Engineer, Edge Technology

So you finally went out and bought that MODEM you wanted. Now what do you do?

First of course read the manual! This is especially important with MODEMs, as their operation differs from manufacturer to manufacturer. You should read the entire manual even if you don't understand some of it, you will need the information later. You should go back and read it completely again (after you have used your MODEM). Much of the information it contains which may be undecipherable the first time through will be clearer.

One of the first things you will want to do is see if the MODEM works, and how it works. To do this you will need to call a computer so that you can communicate with it.

If you don't have a computer to call, a good way to start is to call one of the Computerized Bulletin Board Systems (or message systems) that is probably in your area. If you don't have a number, ask your local computer store, or go to a computer club meeting and ask someone.

The bulletin board systems are useful in several ways. First, they give you something to do with your MODEM immediately. Second, they tend to hold your interest for a rather long period of time. The first session on a message system often lasts thirty minutes to an hour or more. This can be rather expensive if the call is long distance! Assuming that the call is local, (or you don't care, if that is possible) the long time spent is useful. It will exercise your MODEM, and give you a good sense of how it works.

There are two major ways to communicate via a MODEM. The method just discussed (using a bulletin board system) is referred to as the conversational mode. This is because you are, in a sense, "conversing" with the computer. You ask it for some information, or request a specific function, and it responds directly to that request. You are interacting directly with the computer. The other means of communication via the MODEM is the data transfer mode. In this mode of operation, the computer is in control of the communications. This is generally used to transfer programs or text between two computers.

The Conversational Mode

The conversational mode is where you are in direct communication with the remote computer. This is similar to sitting in front of your own computer and writing a program. In fact, the only difference is that the computer is at the other end of the phone line.

There are different types of conversational modes employed depending on the system involved. The most common is echoplexing. Echoplexing is often referred to by the physical means of implementing it (full duplex). Although this is common practice, it is not valid since any of the communications methods can be implemented with a full duplex setup. Echoplexing means that, when you type a character, it gets sent out of the MODEM, the remote computer receives it, and echoes it back to you. This way you can verify that it was properly received, since you see every character exactly as the remote computer sees it.

A problem with echoplexing is that if the phone line is weak, noisy, or has excessive propagation delays, (such as very long distance calls) the character that is echoed back can be destroyed or lost by its own reflection, or by the next character that is transmitted. This is solved by not echoing the character. Instead, the character is echoed locally either by the MODEM itself, (this is what the half duplex switch is for on some MODEMs) or by the local computer or terminal. This is referred to as local echo. Although it is often referred to as half duplex, this is not the proper term since half duplex, by definition, is the way the system hardware is set up and not the way the system echoes characters. In fact, if the MODEM is "103 compatible" it is always in full duplex mode even if it has a half duplex switch on. By the way, if you are communicating with an echoplexing (full duplex) system and you have the switch set to half duplex, you will get two characters for every one you type. This is because the MODEM is echoing the character back, and the remote computer is also echoing it back.

Finally, there is a special mode that has grown up on the true half duplex systems. This is referred to as conversational half duplex. This is a modified version of local echo. In local echo mode, any character can be sent at any time. In true half duplex communications, only one computer can communicate at any one time, so the local computer cannot respond while the remote computer is transmitting. This can be a problem if the remote computer is sending a bunch of data or stuck in a loop – there is no way to stop it.

This problem is usually corrected in one of two ways. The first method is to add some more hardware in the form of a reverse channel or supervisory channel (a special signal that can be sent back over the phone lines without interfering with the data). It cannot carry any large amount of information and, in fact, is normally only used to request the remote computer to stop what it is doing and return control to the local computer.

The other way that the communications problem is solved is by program control. After the remote computer sends a specific amount of data, it waits for the local computer to indicate if it has received the data or if it wants the data to be sent again, or to have control returned to it. This has the advantage over the reverse channel type systems of being able to send any data again that was improperly received; but it has the disadvantage of being slower.

A response-expected type system is used in packet switching systems (they are, by nature, half duplex type systems) because the response can be shifted in time. That is, several groups of data can be sent with the response to be returned later. In fact, the response can sometimes lag behind the sent data by a number of data groups. This, of course, means that it is important that the groups be properly identified so that it is known which one was bad and needs to be resent.

The data transfer mode is normally seen as having two subdivisions: the send mode and the receive mode. It might be noted at this point that there is another mode that is often grouped with the send and receive modes: the local mode. The local mode is not a form of communication, but rather a mode of non-communication. The local mode is any operation that occurs locally such as preparing the text or program to send, or preparing the computer to receive data. Specifically, if the action involved does not use the MODEM to interact with the other computer, it is a local operation.

When operating in the send or receive modes, one computer must be in the send mode, and the other must be in the receive mode. Except in the case of fully-automated computer systems, the specific mode is normally selected by the user at the beginning of the operation while in local mode. The computer then takes over and establishes communication with the other computer and transfers the desired information.

The operation of the data transfer mode can be quite complex. The first action must be the establishment of synchronization with the other computer. This is done by the designated primary computer (depending on the system involved, this could be the sending computer or the receiving computer) by sending out a periodic request to the other computer. When the other computer answers, they then become synchronized. This means that the two computers are now listening to each other and are in a position to respond to requests from the other.

The next action is dependent upon the type of system involved. In a non-automatic system, it is assumed that the information has been predefined at both computers and no information needs to be sent to define it. In an automatic system, the predefinition is not assumed, and so the information must be transferred. Generally this consists of the program (or file) name of the data to be transferred.

Next, the data itself is sent. It is usually broken up into small pieces during the sending process. The reason for breaking up the data is to reduce the retransmission time involved if an error is encountered. This way, only a small piece has to be retransmitted if an error occurs, not the entire program.

Normally, the size of these pieces is related to the computer, and typical sizes are 128, 256, or 1024 bytes. The piece of information is referred to as a record. The exact structure of the record varies from system to system; there is no standard yet developed. In time a common standard will develop. Until then, we will have to live with what is out there.

In my next column I will describe a specific application of program transfer with a MODEM.