CP/M-80 KERMIT STATUS CP/M-80 KERMIT (Kermit-80) was originally written for a single system (by Bill Catchings, formerly of Columbia), and then support for additional systems was added (at Columbia and elsewhere) using conditional assembly to select a particular machine's device addresses, screen control codes, or other system dependent features. Meanwhile, a way of supporting different CP/M systems without device dependent code was discovered (by Bernie Eiben at DEC), involving tricky manipulation of the IOBYTE. When Kermit-80 is built in this way, it is called "Generic Kermit-80". It can generally be made to run on any system that implements the "optional" CP/M IOBYTE facility, either as-is, or by changing the IOBYTE definitions. The source still contains conditional assembly support for many systems from the pre-generic version, but not all of this support has been tested when built from the current source. If you want to build Kermit-80 for a particular micro, try the following in this order: 1. Download CPMGENERI.HEX, which is "Generic Kermit-80", load it, and see if it works. If it does, you're done. 2. Look in the source, at the definitions of the symbols BATIO and DEFIO. These are the two IOBYTE values that Kermit-80 switches between for the console and the serial port. See if these need to be redefined for your system. If so, change the definitions, make sure assembly switch GENER is TRUE and all others are FALSE, reassemble, download the resulting hex file and try it out. If it works, you're done. The current source is CPMBASE.M80. Accept no substitutes! 3. If generic Kermit-80 doesn't work, look for an assembly switch for your micro, set it to TRUE and all others to FALSE, assemble, download, try it out. If it works, fine, you're done. If it doesn't work, you'll have to debug it. 4. If generic Kermit-80 doesn't work, and there's no assembly switch for your micro, add a new assembly switch and conditional code to support your system, debug it, and send it back to us. CPMKERMIT.DOC contains detailed information about KERMIT-80. This information also appears as a chapter in the Kermit User Guide. Here is a list of known problems with KERMIT-80: 1. No command files or initialization files. 2. The incredibly ugly IF...ENDIF structure of the program makes it almost impossible to read and maintain, and to add support for new systems without endangering the support for old ones. The program needs to be completely rewritten, broken up into separate modules for protocol, disk i/o, screen i/o, console i/o, port/modem i/o, command parsing, terminal emulation, data and definitions. Of these, only the protocol module would be system independent. 3. Lower case letters in an incoming file header should be raised to upper case and nulls or other control characters in the filename should be discarded. 4. A NAK for the next packet is NOT an ack for the current one if the current one was a Send-Init. 5. Check for packet number wrap-around when checking for things like "is this a NAK for the previous packet?" when comparing packet numbers. 6. May want to verify other side's Send-Init parameters more rigorously and force them to legal values if illegal. 7. Junk in command buffer after a file transfer (or is it just an unsuccessful file transfer?) sometimes prevents the first command after the transfer from being parsed. 8. The old file stepping mechanism -- which allowed only 16 files to be sent in a wildcard send command -- has been replaced by a new mechanism that lets any number be sent. However, the new mechanism is very costly, requiring on the order of n**2 directory lookups to send n files. The new method should incorporate the old -- build a table of, say, 16 (32? 64?) files to send, and when that gets used up, build another table. 9. KERMIT-80 (and all the other micro versions) badly need to be able to send a BREAK signal. You need it to talk to IBM systems, and to get the attention of various kinds of port switchers, multiplexers, etc. Code has been added to allow the VT180 and DECmate II to do this, but none of the other implementations have it. This is, of course, highly system dependent. 10. Fix logging function. Most implementations don't have it; those that do lose characters. Log to a big area in memory; when buffer gets nearly full, send ^S, dump it to disk, send ^Q. Look at MODEM, see what it does. 11. Retry count still isn't updated in every case. - Frank da Cruz, Columbia U, April 84