How modems work. (part 3) (Column)
by Mark Minasi

For the last two months, we've looked at some of the things we need to know in order to get the fastest, most reliable file transfers out of our existing modems. This month, I want to wrap up the topic of improved protocols, talk about setting modems and software to handle varying error climates, and look at modems that are inexpensive and fast.

We saw last month that a checksum is calculated for every block of data sent via XMODEM. The receiver uses that checksum to ensure that the data in the block was transmitted without damage from phone noise. The checksum's a good tool, but there are some cases where line noise could change two bits in a 128-byte message but the noise wouldn't be detected by the checksum procedure on the receiver side. While such a thing is unlikely, it's still too likely for my taste. The checksum is only 99 percent effective--that is, it only detects line noise in 99 percent of the cases where it occurs. Most modern protocols don't use checksum but instead employ a more complex mathematical function called a cyclical redundancy check (CRC), which is 99.9926 percent effective.

It would often be nice to use a wildcard character when transferring data. Unfortunately, with XMODEM you have to specify each file, one by one. YMODEM Batch and ZMODEM are among the newer protocols that offer batch transfer. I particularly like ZMODEM; it lets me specify a list of files and then asks if it should hang up after the transfer. I then walk away for a while, return, and find that ZMODEM has transferred all of the files for me.

Even more amazing, if ZMODEM detects that one of the files was only partially transferred, perhaps because I was disconnected in midtransfer during my last transfer session, ZMODEM will actually pick up where it previously left off! Late at night, when phone charges are at their lowest, I can queue up several megabytes for transfer and go off to bed without worrying about staying connected all night. Along the same lines, XMODEM requires that you specify twice the name of the file you want to transfer--once for the sender and once for the receiver. YMODEM and later protocols transfer not only the file but also the filename. All you need to do is to tell your communications software to receive the file, and it gets the filename from the sending BBS.

Squeezing the Last Bit

There are many data-compression techniques in use these days; the most popular are the ones used by the PKZIP, ARC, PAK, and LHARC programs. If you've ever pulled a file off a computer bulletin board system (BBS), it probably had a ZIP, ARC, PAK, or LZH extension, requiring that you have the appropriate decompressing program.

The idea with file-compression programs is simple: The more time required to do a file transfer, the more the transfer costs, whether from CompuServe charges, long distance charges, or whatever. File-compression programs can often compress files to one-tenth of their original size, so a 1MB file would compress to a 100K file.

That's why many of today's modems include the ability to compress and uncompress data on the fly. With such a system, you'd never have to bother with the whole compression and decompression process; you'd just leave bloated, uncompressed files on your BBS and let the modems handle the compression. You'll recall from last month that two terms stand out in the error-correction area: MNP, for Microcom Networking Protocol, and V.42, an international standard. Both standards have been augmented to include data compression in addition to error correction. MNP's Level 5 includes data compression, as does V.42 bis. These days, many modems come with these features.

If you download images from bulletin boards, you've probably heard of GIF (Graphic Interchange Format). GIF files don't benefit from modem compression, because GIF files are already compressed.

Since ZIP, ARC, PAK, LZH, and GIF files are in formats that don't lend themselves to further compression with normal compression techniques, it should be obvious that modems with built-in compression capabilities are of very little value to most of us. Not only are they of little value, but they're often downright undesirable, since modems with built-in compression can waste time trying to compress uncompressible data, slowing down file transfers. Given that ZIPs and GIFs are what most of us are downloading, look for a modem with the ability to turn off compression.

Communications Coprocessor

An inexpensive chip that can increase the speed of your file transfers has been around for years. Called the 16550, it's a member of the class of chips called UARTs (Universal Asynchronous Receiver/Transmitters). A UART is the heart of any serial port. If you're curious, pop the top on your PC and pull out the board that has your serial port on it. (Some computers may have the serial-port electronics right on the computer's motherboard.) You'll probably see a large 40-pin chip on the board. Look for the numbers 8250, 16450, or 16550. They may be wrapped up in some other characters, such as INS8250AP or the like.

The 8250 was the original UART used in PCs and XTs. It was fine for communications up to 2400 bps, but it couldn't keep up with faster computers and communications. So the 16450 was developed, and it's fairly prominent on the serial ports of computers in the 286 and higher class. A complete internal re-design makes it up to ten times faster than the 8250 for some applications. Part of that speed comes from a one-byte buffer that makes life easier for multitasking systems. Multitaskers like buffers because serial devices need nearly constant attention or data gets lost. Buffers hold the data for a few extra milliseconds, making the process of juggling tasks a bit simpler. OS/2, in fact, insists on 16450 UARTs, and serial ports with 8250s aren't recognized at all. Fortunately, the 8250 and 16450 are pin compatible, so I've been able to convert a number of old parallel/serial cards to OS/2 compatibility by just swapping a single chip. The task is further simplified by the happy fact that many UARTs are socketed, removing the need for soldering.

OS/2 works well with the 16450 because it has to deal only with well-behaved programs that were designed to be multitasked. Unfortunately, DOS multitaskers such as DESQview and Windows don't have that luxury. It can take so much time to swap multiple DOS applications that background communications can be a real pain under most DOS multitaskers; in fact, I use background file transfers as one of my basic tests of DOS multitaskers. There's where the 16550 comes in. The next member of the UART family, it includes a 16-byte buffer that turns out to be just perfect for communicating with DOS multitaskers. It even smooths out file transfers at 9600+ bps for slower PCs. And, best of all, it's pin compatible with its older siblings, the 8250 and the 16450, so you can upgrade easily if your current UART is socketed. And you'll need just one more thing: a program to turn on the 16550. Some applications do that automatically, but just to be sure, you can grab a program called 16550 off CompuServe.

But all isn't good news here. You'd think that a multitasking platform such as Windows would benefit from the 16550 and would use it if present. To the contrary, Windows will likely lock up if your 16550 buffers are enabled. The Windows COMM.DRV and virtual driver *combuff must be rewritten in order to use the 16550; Microsoft says it will take care of this "in a future release of Windows."

Tips for Maximum Transfers

Assuming you have a fast computer and 9600-bps or faster modem, how do you squeeze the maximum file-transfer rate out of your system? First and foremost, choose a protocol that allows large block sizes, as that will net the greatest transfer rate. Make sure only one part of the system handles error checking: either the modem or the protocol. That means either diving into your modem manual to find the code to turn error checking off or leaving the modem alone and finding and using a protocol that won't try to do error checking. The preferred protocol here from my experience is YMODEM-G. The G is the important part; regular old YMODEM does error checking. Given the choice, let the modem do the error checking. It's faster, more robust in the case of noisy lines, and more thorough in its discovery of transmission errors. The main problem is finding a host that supports YMODEM-G.

Install a 16550 if you can, or think about replacing your current parallel/serial board with one that sports the newer chips. You won't see a difference with a 16550 unless you're multitasking, transferring data at 9600+ bps, or both.

And whenever possible, use COM2 rather than COM1. Why? You'll get a slightly better response from COM2 because it's driven off interrupt 3 (so is COM4, so you could alternatively use COM4), whereas COM1 and COM3 are driven by interrupt 4. The interrupts in the PC are prioritized, meaning the items with the lower interrupts get higher priority. Assuming your PC is monitoring both COM1 and COM2--if, for example, you had a serial mouse on one COM port and a modem on the other--you'd do better to put the mouse on COM1 and the modem on COM2.

If you're using Windows, that's the preferred arrangement anyway, since Windows deals best with communications ports when it sees them in order. It sees the mouse first, so put that on COM1. Then it sees the modem on COM2 whenever you get around to starting up the communications application. And remember to turn off compression in most cases.