Creating a runnable KERMIT from the distribution KIT: This version of CP/M KERMIT is "modular". It basically consists of two pieces - a system-independent body and a micro-specific module. With this technique a couple of objectives were achieved: 1. Storage requirements for the "distribution media" was minimized. 2. Transfer time for a "specific KERMIT" was "split" into smaller pieces - so that it becomes possible to use existing and "maybe" not too dependable base-transfer software. 3. For the "general" case of re-building an "existing" KERMIT, micro-storage requirements are within 150K of floppy space. 4. And , last not least , the code was stream-lined to make it a little bit easier for the "developer" to add new functionality. Also its now possible again to do KERMIT-development using micros lacking the "luxury" of a 10Mb hard disk. The following text is trying to "walk you thru" the most common cases.. Starting from "just" getting an already pre-built micro version of KERMIT into operation , followed by changing terminal handling for micros, which allow "external" terminals -- and finally (if You so desire) to rebuild KERMIT from sources. Case I Overlaying BASE-Kermit with an existing micro-module. ============================================================ Table 1 Systems supported by KERMIT-80 ------------------------------ ------------------------------------------------------------------------- |Symbol | System | |------------------------------------------------------------------------ |AP6551 | Apple II with Z80 Softcard and 6551 ACIA in serial interface | |APMMDM | Apple II with Z80 Softcard and Micromodem II in slot 2 | |BBII | BigBoard II (terminal required) | |BRAIN | Intertec SuperBrain. | |CPM3 | "generic": CP/M 3.0 (CP/M Plus) systems (terminal required) | |DMII | DECMATE II | |GENER | "generic": CPM 2.2 systems supporting IOBYTE (terminal requ.) | |HEATH | Heath/Zenith H89. | |KPII | Kaypro-II (and 4; probably supports all Kaypro systems) | |MDI | Morrow Decision I (terminal required) | |MIKKO | MikroMikko | |MMDI | Morrow Micro Decision I (terminal required) | |OSBRN1 | Osborne 1 | |OSI | Ohio Scientific | |ROBIN | DEC VT180 | |TELCON | TELCON Zorba portable | |TRS80LB| TRS-80 model II with Lifeboat 2.25C CP/M Display | |TRS80PT| TRS-80 model II with Pickles + Trout CP/M Display | |VECTOR | Vector Graphics. | |Z100 | Z-100 under CP/M-85 | ------------------------------------------------------------------------- You will need MLOAD.COM (HEX) [should be V21 or higher] and two of the .HEX files from the distribution kit: CPBASE.HEX (the system-independent module) and one of the system-dependent overlay modules. The name of the system-dependent overlay is CPxxxxxx.HEX, where xxxxxx refers to the first six characters of the switch used to generate it; see Table 1 above. For systems which require an external terminal as console, the distribution kit overlays use the generic "crt" selection; after getting KERMIT running, you may wish to re-assemble the system dependent part to make use of your specific terminal (see below Case II). Using MLOAD, the process is easy and fast: Assuming the system-dependent piece is called MYNE.HEX ... A>MLOAD KERNEW=CPBASE.HEX,MYNE.HEX ;if You have two HEX-files A>MLOAD KERNEW=CPBASE.COM,MYNE.HEX ;if You have one of each This produces KERNEW.COM, which may be run directly. If You either "skipped" getting MLOAD or just don't have it, You have to use DDT. This involves converting a number from HEX to decimal.....and a "steady hand". For purposes of illustration, we will assume the system-dependent overlay is called "MYNE.HEX". The two HEX files will be combined usinge DDT, as follows: A>DDT CPBASE.HEX NEXT PC 3500 0100 -IMYNE.HEX -r NEXT PC xxxx 0000 -^C A>SAVE DD KERNEW.COM The page count ("DD") used in the SAVE command is calculated from the last address ("xxxx") given by DDT in response to the R command: divide this number by 100 hex, rounding up, then convert to decimal: 384F becomes 39 hex, which is 57 decimal (i.e. 3*16 +9) ; but 3700 becomes 37 hex, or 55 decimal. Be careful not to overwrite your running KERMIT, if any, with this new version until you've tested it. Test your new KERMIT by running it. If it gives you a prompt, it might be OK. (don't delete your old one yet...). Instead of a prompt, you could get one of two messages indicating that the configuration information is invalid: ?KERMIT has not been configured for a target system or ?Consistency check on configuration failed Of course, neither of these messages should appear if you're building KERMIT from the distribution kit. The first message indicates that the overlay was not found where the system-independent module expected to find it, probably because the overlay address is incorrect; the second indicates that the version of CP4LNK used in the system-dependent module is incompatible with the system- independent module. A "relatively fast" and "easy" way to check a new KERMIT involves moving the KERNEW back to the "host" , renaming it to KERTST on the micro under test - and then moving it back to the micro. If the newly downloaded KERNEW behaves unchanged - Congratulations! You are the proud owner of a new version of CP/M KERMIT. More involved "tests" include comparing Checksums on micro and host etc... In case your micro supports "external" terminals , you have to "customize" the system-dependent overlay for Your micro and Your terminal - CPBASE.HEX, the independend piece stays constant. Case II Modifying the system-dependent overlay ============================================== Table 2 Terminals known to KERMIT-80 ---------------------------- ------------------------------------------------------------------------- |Symbol | Terminal description | ------------------------------------------------------------------------- |CRT | Basic CRT, no cursor positioning | |ADM3A | Adm3a Display or lookalike | |TVI925 | TVI925, Freedom 100 | |VT52 | VT52 or VT52 emulator such as Heath H19, H29, etc. | |VT100 | VT100 or emulator (most ANSI terminals should work?) | ------------------------------------------------------------------------- You need a couple of more files - but You have already a "working" KERMIT -- although Your terminal is "generic" and definitely can do better.. CP4TYP.ASM - system selection CP4DEF.ASM - definitions for both independent and sys-specific part CP4SYS.ASM - system-specific code CP4LNK.ASM - linkage area description ...plus LASM.COM the public domain module-linking assembler You'll need an EDITOR to check/change the following switches: [OVLADR only changes if CPBASE got changed !!] First, the overlay start address. The symbol "OVLADR" is EQUated to the address of "LNKFLG" in the system-independent module, as the starting address of the overlay (3400H for version 4.02). You'll need this if you're building the overlay with M80/L80. Second, the assembler being used. Again, define one of MAC80, M80, and LASM to be TRUE to select it, and define the others to be FALSE. The two modules (system-independent and system-dependent) do not need to be built with the same assembler (the default setting is LASM). Third, the system configuration. Locate your system in table 1, then define the appropriate symbol TRUE, and the rest FALSE. If the system comes with a builtin console terminal, define all the terminal switches FALSE. If the system uses an external terminal as the console, locate the terminal in table 2 and define the appropriate symbol TRUE, and the remainder FALSE. If the terminal is not listed in table 2, use the CRT switch; in this case, VT52 emulation is not supported. In addition, there are a few general and system-specific symbols which may be altered to fit your system: APSLOT For Apple with 6551 ACIA, defines the slot number of the serial card CPUSPD Processor speed in units of 100KHz (currently used only for bbII and kpII for timing loops) TAC For users connecting through ARPAnet TACs: set to TRUE if you wish the default TACTRAP status to be ON. (This may be overridden with the SET TACTRAP command) TACVAL For ARPANET TAC users: defines the default TAC intercept character (may be overridden with the SET TACTRAP command) After editing CP4TYP.ASM as necessary, assemble and link the overlay as follows: With LASM: A>LASM CP4TYP.xxZ (see Case I regarding xx) With M80 (where "xxxx" is the hex value of OVLADR from CP4LNK.ASM): A>M80 CP4TYP=CP4TYP.ASM A>L80 /P:xxxx,CP4TYP,CP4TYP/N/X/E The overlay may then be merged with the system-independent module as described above ( Case I ). CASE III Adding functionality to CPBASE or adding a new micro. ============================================================== KERMIT-80 is built in two pieces from the following 12 files: The system-independent files: Endresult =>CPBASE.HEX CP4KER.ASM - header file CP4DEF.ASM - definitions for both independent and sys-specific part CP4MIT.ASM - initialization, main loop, miscellaneous commands (BYE, EXIT, LOG, SET, SHOW, and STATUS) CP4PKT.ASM - the KERMIT protocol handler (SEND, RECEIVE, LOGOUT, and FINISH commands) CP4TT.ASM - the transparent commands (TRANSMIT, CONNECT) CP4CPM.ASM - CP/M commands (DIR, ERA) CP4WLD.ASM - the wildcard handler CP4CMD.ASM - the command parser CP4UTL.ASM - utility routines and data CP4LNK.ASM - linkage area description ...and the system-dependent module (see above Case II). The system-independent module contains all of the system-independent files except for CP4LNK.ASM, which is assembled into the system-dependent module to provide the structures needed to connect the two modules. As distributed, the system-independent module is named CP4nn.HEX, where 4nn is the version number. THIS MODULE ONLY NEEDS to be ASSEMBLED in case of ADDING NEW FEATURES! The system-dependent module consists of CP4TYP.ASM, CP4DEF.ASM, CP4LNK.ASM, and CP4SYS.ASM. One copy of the system-dependent module is supplied for each supported system; the filename is the same as the switch which is defined to select that system (truncated to six characters). After assembling the two pieces separately, they are combined with DDT or MLOAD into a system-specific KERMIT (see above Case I). If you want to rebuild the system-independent module, the only change you may need to make is to select the assembler to be used, in CP4KER.ASM. Define one of MAC80, M80, or LASM to TRUE to select it as the assembler; the others should be defined FALSE. The assembler-switch is set to LASM. Your command for LASM will look like (standard ASM convention) A>lasm cp4ker.xxZ ;where xx is source and destination disk LASM will generate CP4KER.HEX. Assuming you have the Microsoft Macro Assembler package (M80/L80), you'll need to do the following: A>m80 cp4ker=cp4ker.asm A>l80 /p:100,cp4ker,cp4ker/n/e This will produce CP4KER.COM. If you're using MAC80, I can't help you. (Frank??) Changing the system-dependent overlay ; see Case II above ... If you are just assembling an existing configuration, you'll need to edit CP4TYP.ASM only. If you are adding support for a new system, you should NOT MODIFY CP4DEF.ASM or CP4LNK.ASM; if you do, you'll have to change the system- independent module also. Eventually, CP4SYS.ASM will be split into separate files, each of which will generate one or more related systems. When this happens, you'll want to pick the one closest to your system to use as a starting point. After editing CP4TYP.ASM as necessary, assemble and link the overlay as follows: With LASM: A>LASM CP4TYP.xxZ (see above regarding xx) With M80 (where "xxxx" is the hex value of OVLADR from CP4LNK.ASM): A>M80 CP4TYP=CP4TYP.ASM A>L80 /P:xxxx,CP4TYP,CP4TYP/N/X/E The overlay may then be merged with the system-independent module as described above (Creating a runnable KERMIT from the distribution kit). Adding support for your system to KERMIT: TO BE SUPPLIED. Basically, you'll only need to add a switch in CP4TYP.ASM to select your system, and add the system-dependent code to CP4SYS.ASM (I hope I've put enough hooks to allow this to be done easily). Adding new features to KERMIT: TO BE SUPPLIED. Hang on, I've got this list of requests...