A terminal emulation is in fact a protocol, or a set of specifications that two parties agree to for the purpose of communicating. One protocol level is the terminal emulation. Inside that emulation you will need file transfer protocols.

If you wish to transfer files you need software on both ends that can send and receive files using a common protocol. Here are the commonly used file protocols, with a bit of a description:

X-Modem is the grand-daddy of file transfer protocols. It’s simple and almost universal, but it’s not very robust. X-Modem sends 128 byte packets with an additive checksum. It can’t send more than one file at a time, and it doesn’t send any header information, such as the file name or file size. X-Modem is not a preferred choice, but if it’s your only choice, it will work.

X-Modem is also very error prone because additive checksums can’t cope with many data problems, and X-Modem also has an annoying habit: it sends extra padded data on the end of a file, because it can’t send packets shorter or longer than 128 bytes. X-Modem CRC addresses the original X-Modem’s checksum deficiency by adding a harder-to-fool CRC (Cyclical Redundancy Checksum) to the file. The very short 128 byte packets also make X-Modem very slow. X-Modem 1K is a faster version that sends 1024 byte packets instead.

Some versions of Y-Modem are really just a renaming of X-Modem-1K, but true Y-Modem is actually a new protocol. It uses 1K blocks. The G version is a streaming protocol designed for use over error corrected links. Because it doesn’t wait for a block to be acknowledged before sending the next block it can send larger files much more quickly than X-Modem or regular Y-Modem. Y-Modem batch allows transmitting multiple files at once, and sends the filenames along with the data, so you don’t have to enter filenames twice when starting a file transfer. Y-Modem also sends across the file size, so you can tell how long a file is going to take to download and you can see the progress as a percentage of the whole file size. It doesn’t pad the end of the file either, so files get through unmodified.

Z-Modem is the king of serial file transfer protocols. If you can use it you should. It can adapt to varying line speeds and line qualities by transmitting smaller packets if there are problems, and it can transfer files in batch mode, so you can start one transfer and send multiple files. It uses a very tough to beat 32-bit CRC, so you can transfer files over even very noisy lines with little risk of data corruption. If you are downloading a large file and you get cut off half-way, you can resume automatically from where you left off. This protocol is very complex to implement, but most decent terminal programs include it. Most file transfers from Bulletin Board Systems use Z-Modem. Z-Modem is also capable of streaming operation, making it very fast over error corrected links.

Kermit is the most complicated and tweakable file transfer system ever developed. That figures, since it was originally developed for Unix mainframes. It supports at least 50 different modifiable parameters. Getting it working is a nightmare, but if you need to talk to large host computers and get files off of it, you can try and get Kermit working. Kermit is not green, nor is it very friendly. It’s also very slow. But hey, it’s better than nothing, so if you need it, use it.

There are literally dozens of special purpose, proprietary and little used protocols. You don’t need to bother with them. If you run into a protocol you don’t know how to support, it’s possible that you can get a terminal program that supports it, but if you don’t need to find one, don’t bother, you’re not missing anything.

But modems are not always used to communicate between a terminal emulation program and a host computer. When we aren’t using a terminal emulation, then what are we using?

Understanding the protocol you are using is necessary if you are going to troubleshoot communications problems you are having with it.

Now that modems were capable of fully automatic operation, they started to be used for a lot more than just terminal connections. Other devices, such as the Programmable Logic Controllers (PLCs) we use for control systems, and other proprietary devices could all be accessed as well. We often use the Modbus protocol for communications between software running on our computers, and the PLC. This, and any other serial protocol may be used over a modem, but with varying degrees of success. We are using a modem for a purpose slightly different that it was originally designed for, and these discrepancies creep up on us and cause us problems if we aren’t aware of this.

When connecting to the internet, we’re using one of two protocols to communicate over the modem. They are SLIP and PPP. SLIP stands for Serial Link Internet Protocol, and is an adaptation of the standard Internet IP protocol for transmission over a standard serial cable link, or a modem. PPP is a later system designed for dial-up networking at the beginning of the big home internet access boom. PPP stands for Point to Point Protocol. It is much more flexible and has many additional powerful features that are much better than SLIP.

Your application software may use proprietary protocols that you can’t do much about. A good example of this is PC Anywhere: It provides remote graphical access to a computer, but you can’t do anything about the protocol. You just have to hope it works, and if it doesn’t consult the manuals for the product.

That doesn’t absolve you from trying to solve lower level problems, like your modem not being able to make or keep a connection.

The general rule is that if you can’t keep a connection, no protocol is going to work. So if you’re not sure if a modem link is working, try getting a terminal connected on either end and see if you can get connected, stay connected, and maybe transfer a file.