============================================================================== [ THE KAY*FOG RBBS | CPM-CC12.ART | posted 01/18/86 | 159 lines 9k ] The CP/M Connection Originally published in by Computer Currents Ted Silveira 2550 9th Street (copyright and all rights reserved) Berkeley, CA 94710 October 8, 1985 COMMUNICATIONS UPDATE One problem I have writing about public domain software is that my information can be outdated even before it gets into print. People who write these programs just can't keep their hands off them, so they put out a steady stream of updates. Some programs I've written about are now available in newer versions, and new programs have come out in areas I've already covered, so from time to time, I'll devote a column to update news. Communications programs get updated more frequently than any other kind, almost weekly it seems. Most of these updates are relatively minor-- adding support for new computers and modems, making adjustments to handle oddball remote systems used by practically no one. But recently, there have been some bigger changes. [HIGH SPEED MODEMS] More and more people are using high speed 2400 bps (bits per second) modems. Many of the large RCP/M (Remote CP/M) bulletin board systems have them now, encouraged by support from U. S. Robotics and Racal-Vadic, two of the major modem manufacturers. And now that the price is drifting down toward $500, more callers have them, too. You can tell when you reach an RCP/M that has a 2400 bps modem because it answers the phone with a special whistle that an ordinary 300 bps or 1200/300 bps modem won't respond to at all. If the RCP/M's modem doesn't get a 2400 bps answer after a few seconds, it then tries 1200 bps and 300 bps, and everything proceeds normally. When these 2400 bps modems first showed up on RCP/Ms, there were some problems. Apparently, some of the modems ran very solidly at 2400 bps but made only tenuous connections at 1200 bps. This problem was supposed to be especially bad when the caller was using the U. S. Robotics Password modem, which I have. I did have many problems calling these high speed systems when they were first setting up and got dumped many times. Now, however, these problems seem to have been fixed, at least on the systems I call. [ENHANCED XMODEM PROTOCOL] The Xmodem (or Christensen) protocol that public domain communications programs and RCP/M systems use for transferring files has been enhanced. The original protocol transfers a file in a series of blocks, each containing 128 bytes. Each block is checked for errors after it's received and retransmitted if any are found. Recently, this protocol has been expanded to include the option of using 1024 byte (1K) blocks instead of 128 byte blocks. You save time using 1K blocks because the various housekeeping and error-checking functions don't have to be done as often, so the computers spend more time actually transmitting the file and less time talking about it. With short files at slow speeds (300bps) the savings are marginal at best, but with longer files at higher speeds, they're significant. Of course, it takes longer to transmit a 1K block than a 128 byte block, so if you're using a noisy phone line and have to retransmit many blocks, you'll lose instead of gain. Newer versions of the XMODEM program, used by RCP/Ms to transfer files to you, can now handle transfers with either 1K or 128 byte blocks. In addition, Irv Hoff has created a new program, KMD, that can take the place of XMODEM. KMD also handles transfers using either 1K or 128 byte blocks and has a batch mode that allows you to up- or download a series of files with a single command, using wildcards. Just to confuse you, some systems have renamed KMD to XMODEM while others call it KMD. So, if you try to download something using the familiar [XMODEM S filename.typ] command, and the system tells you there's no such program as XMODEM, try using [KMD S filename.typ] instead. [A NEW COMMUNICATIONS PROGRAM--IMP] Irv Hoff has done a major overhaul of his reliable MDM740 and brought out IMP243 (Improved Modem Program version 2.43). IMP can make file transfers using either 1K or 128 byte blocks. In fact, IMP goes one step further by automatically using 1K blocks when transferring with KMD or XMODEM versions 112 and beyond. IMP also monitors the number of errors during a file transfer and automatically switches from 1K to 128 byte blocks if the error rate gets too high. IMP also adds support for 2400 bps modems. Most of these modems have an "automatic step-down" feature, which means that if they can't make a connection at 2400 bps, they will automatically try at 1200 bps or even 300 bps (on some). IMP takes full advantage of this, waiting for the modem to make its connection, finding out what speed it has connected at, and then setting the computer's modem port to that speed, all automatically. The operator doesn't need to think about setting the speed at all (2400 bps modems only). Finally, IMP has added a feature that I think was long overdue in all such programs. Most sophisticated communications programs will let you set up a list of numbers that they will dial in turn until they get a connection. Unfortunately, most modems don't recognize when they've reached a busy signal or a phone that isn't being answered, so the programs just hold on to the line for about 30 seconds before they "timeout" and move to the next number. I find this frustrating because I usually know in 10 or 15 seconds that the phone isn't going to be answered. IMP now allows you to abort the current attempt without cancelling the whole dialing list. Instead, IMP just moves on to the next number. One caution--though IMP looks much like MDM740 from the outside, you can't use the MDM740 overlay files to adapt it to your computer. You must use the special IMP overlay files. There are many of these available already, adapted from the MDM740 overlays, but you may find some bugs, since the program is still young. I know, for example, that the Morrow Micro-Decision overlay won't work with Revision 1 Morrow, though I assume it will work with the Revision 2 (Morrow owners--it's the same old printer/modem port problem). I doubt that these bugs will last long, but you should always test any new program before you use it for anything crucial. [A NEW VERSION OF MEX] Ron Fowler has recently updated his MEX (Modem EXecutive) to MEX114. First, this version fixes a few bugs. These were not too serious--I use MEX far more than my checkbook really allows and have never run into any of them. One involved problems with the printer buffer, another with full capture buffers (only if the buffer was more than 32K), and a third with garbage created in a capture buffer left open during an Xmodem transfer. Second, MEX114 can now handle the 1K protocol. It will automatically adjust to either 1K or 128 byte blocks when receiving a file, but it will only send with 1K blocks if you specifically instruct it to. Like IMP243, MEX114 will switch from 1K to 128 byte blocks if the error rate gets too high. Through a special overlay (MXM-2403), MEX114 now supports two 2400 bps modems, the Hayes 2400 and the U. S. Robotics Courier. This overlay does use the automatic step-down feature of these two modems but in a less sophisticated way, so MEX114 can't yet take full advantage of this equipment, as IMP243 does. If you have a 1200 bps or 2400 bps modem, and you spend much time up- and downloading software, you should upgrade to IMP243 or MEX114. It's not just that the 1K protocol will save you some time but also that I suspect the RCP/Ms will eventually adopt this protocol as their primary standard. You won't be locked out if you don't have it--all the RCP/Ms will still allow you to use 128 byte blocks--but life is easier if you stay current. ------------------------------------------------------------------------------ Ted Silveira is a freelance writer and contributing editor to several computer-oriented publications. He appreciates suggestions or feedback and can be reached through the KAY*FOG RBBS (415)285-2687 and CompuServe (72135,1447) or by mail to 2756 Mattison Lane, Santa Cruz, CA 95065. ------------------------- End of CPM-CC12.ART Text -------------------------