CP/M KERMIT STATUS CP/M 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. As support for more and more systems was added, this process, and the program itself, became unwieldy. The program is presently undergoing conversion to a new form, a "Base Kermit-80" to which may be added modular "configuration overlays" for the system-dependent parts, enabling new CP/M implementations to be built simply by filling in a template, and without reassembling the bulk of the program. This conversion is far from complete. 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 CPMKERMIT.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. 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. Here's a list of the available assembly switches: System: Switch: Support: Tested: Works: DEC Rainbow-100 RAINBO Generic VT100 Yes Yes DEC DECmate II DMII Generic VT100 Yes Yes DEC VT180 "Robin" ROBIN Generic VT100 Yes Yes Intertec SuperBrain BRAIN Native VT52 Yes Yes "Generic" Kermit-80 GENER Generic (dumb) Yes Yes Heath/Zenith 89 HEATH Native H19 No ? Heath/Zenith 100 (CP/M-85) Z100 Native H19 No ? Apple II (CP/M, Softcard) APPLE Native VT52 No ? TRS-80 II (CP/M) TRS80 Native VT52 No ? Osborne 1 OSBRN1 Native VT52 No No Vector Graphics VECTOR Native VT52 No ? Ohio Scientific OSI Native VT52 No ? Telcon Zorba TELCON Native VT52 No ? Generic means IOBYTE, Native means direct i/o to hardwired device addresses, and also explicit code to emulate some terminal, like a VT52. Warning: the Rainbow and DECmate II implementations of Kermit run at 1200 baud (maybe 1800) tops! This is because the Z80 that's running Kermit has to ask the other processor (8088 or PDP-8, respectively) to do the port i/o, which slows things down a lot. A "native" 8088 version of Kermit for the Rainbow is on the way. The other known working versions (VT180, SuperBrain) have been tested up to 4800 baud and work just fine at that speed. The Rainbow, Robin, and DECmate Kermits are identical to each other (except that DECmate has its own special IOBYTE definitions), and to Generic Kermit-80 (except that the Rainbow, Robin, and DECmate do VT100 display screen updating during file transfer, whereas the Generic version does straight dumb terminal updating). - Frank da Cruz, Columbia, 12 May 83