Date: Tue, 27 Aug 85 12:14 EDT From: Dick Atlee Subject: Apple DOS Kermit To: Kermit Warm Line I should report in on a Kermit I've been working on for Apple DOS. Last year, I took Antonino Mione's Version 2.1, which didn't provide 80 columns or nice looking output on my Apple IIe, and started working on an Apple-assemblable modified version. I chose Merlin/BigMac as the most widely used, relatively inexpensive, high-capability assembler. The requirements for Apple-assemblability were two in number: the source and object code had to fit in the assembler, and the existing DEC-cross-assembler code had to be modified to match the Apple assembler. To accomplish these, I first handled the code on our IBM CMS system, using a series of EXECs to make 99% of the necessary conversions to match Merlin's code, to look for patterns of locality of reference with an eye to breaking the code down into internally related modules with a minimum of external references, and to construct modules of a reasonable size for Merlin. The minimum of external references was necessary because Merlin doesn't have a linker (Linkers are, or at least were, very expensive, and such assemblers I assumed would not be widely available to ordinary mortals like me who would like to mess with KERMIT). This necessitated adding a central linking module containing shared addresses (JMP tables, DFB/DW defaults, and DS Storage allocations). The resulting KERMIT configuration has turned out to be 10 program modules: S. Linker A. Command Interpreter B. Kermit central control, command jmps, some utilities C. Communications--nonemulation (Device init, I/O, cursor, printable character mods, screenwriting, etc.) D. File-transfer routines code (SEND/RECEIVE/GET/FINISH/BYE) E. DOS interface F. Set/Show/Status commands G. Communications--emulation (screen-handling routines) H. INSTALL and DOS CATALOG/RENAME/DELETE commands I. File-transfer support (Packet handling, error and transfer-progress reporting, debug mode, etc.) This has made it quite easy to develop the program on the Apple--any changes in a module require as overhead only the additional modification of the link module's JMP table addresses for shared routines contained in the changed module (from about 4 to about 8 maximum, depending on the module). Additions to shared DFB/DW and DS storage are extremely easy. The program is designed around our IBM/CMS and SPERRY machines here at Maryland, and I report it to you at this time because this past weekend it finally was able to handle file transfers successfully at 300 baud through a Micromodem, and at 1200 through the Super Serial Card, to and from both mainframes here (though 1200 baud transfers with our IBM only work consistently when using interrupts, which are a requestable option in this KERMIT). There have been many changes from the original version 2.1, some of which are noted very briefly below: Command Interpreter -- left basically intact Commands -- several new ones: DOS CATALOG-RENAME-DELETE commands Exit-to-System-Monitor INSTALL (after you change defaults to desired values, cleans up all DS storage and writes new KERMIT to disk) Communications/Hardware: redid access to ACIA registers, so SET DEVICE loads the register addresses into zero-page locations which are used for indirect addressing. This eliminates the need for a completely separate code section for each device--all devices uses the same section at the cost of slightly slower indirect addressing. Also, interrupt capability was added, which is very helpful in full- screen work. Communications/Emulation--terminal emulation was switched from VT52 to Volker-Craig/ADM3A-emulation. This may sound arcane, but we use it here, and it contains the highest proportion of Ctrl-Chars vs. ESC sequences. However, it would not be difficult to either change the emulation, or to make installable emulations, since I have based the emulation (for both ctrl-characters and ESC-sequences) on translation tables. The concept was borrowed from the IIe 80-column card firmware. In fact, while the Apple side of the translations are nominally the control characters used by the IIe's 80-column card, there is no reliance on that card--all relevant routines have been abbreviated and put into KERMIT, so that dependence on that particular card has been virtually eliminated. 80-Column Support -- Although I originally depended on the 80-column card for both KERMIT local screenwork and non-emulation host-connection screen- work, I have modified my emulation code and put all host-related screen handling under control of KERMIT and not of the 80-column card. Because of inconsistencies in cursor-position storage between the card and the native Apple, my KERMIT does not work nicely on the II or II+, so I am in the process of removing ALL control from the 80-column card AND from COUT (the standard I/O routine and hooks), and giving the control to KERMIT, so as to be independent of both specific machine type and interface/80-col cards. I am almost sure this can be done, though not 100% (a condition I learned early to avoid assuming). File-Transfer -- I did a complete revamp of the SEND/RECEIVE code to rationalize it, using repetition of common code patterns and comments to make each state parallel to all others, and changed the error reporting to be more descriptive of exactly what was causing errors. DEBUG-OFF transfers are now accompanied by a formatted report screen modelled (in concept and content, though not layout) on KERMIT-86 (now MSKERMIT). Conceptual/protocol flaws in the 8-bit quoting code were fixed, but not as yet tested. Help -- the HELP information was augmented and put into a Multi-screen format, rather than scrolling. This made it possible to remove the artificial slowdown of local-KERMIT screenwork which presumably was inserted to permit reading of lines during scrolling. Comments (both in-line and routine sub-headers) -- After the pre-processing work (modularizing, DEC-to-Merlin code transformations) on IBM/CMS, I removed all comments to allow for Merlin source size-limitations. I recently checked every line and added comments to all lines that are new or changed with respect to version 2.1, plus any lines where commenting helped add sense or continuity to new/changed lines, or to identify non-substantive changes (such as labels) in old lines. Otherwise, I have been relying on the comments available in listings of version 2.1. Other changes too numerous to mention (as they say in the auction trade...) The breaking down of KERMIT into modules has of course introduced overhead into both the source and object code. The current source is probably smaller than the source for 2.1 because of the net decrease in line-comments described above. The main source of added length in the object code, apart from new code (such as new commands and device initialization) is in blank space allocated at the end of each module (to nearest hex 100 bytes) for expansion/contraction). However, both source and object for all ten modules, plus the executable KERMIT (simply the BLOADed combination of the object modules) all fit easily onto two sides of a floppy disk. In terms of storage, KERMIT 2.1 occuppied 801-5600 hex, while the new version currently occupies 801-7300 hex, or 109 DOS 3.3 sectors. Although KERMIT now functions, it would be desirable to address the following: 1. Transfer of all--or almost all--I/O handling from the MONITOR to KERMIT 2. Testing on II+/II (after #1) 3. Testing on non-Apple 80-column cards 4. Changing emulation to more common terminal-type 5. Adding more supported interface cards (the support for the old Apple Communication Card is already in KERMIT, but I can't get the ACC to work on my IIe even on its OWN merits, quite apart from KERMIT, and others may also be desirable) 6. Testing Apple/Apple communication 7. Testing 8-bit quoting 8. Solving inability to GET/FINISH from IBM/CMS server This sounds like quite a wish list for producing a truly functional program of use beyond the original U.of M. scope for which it was originally intended. You folks might be able to inform me of whether there is interest in the real world for such a version. I must confess that I have remained totally isolated from Apple Kermit developements since last August when I got version 2.1. I know SARDAC Corp in Florida has worked with Ed Butt here on their KERMIT, the Apple portion of which was borrowed from Wisconsin, which I gather handed the command interpretation to Applesoft to cut down on size. I haven't had a chance to really experiment with this version. Extensive changes may have already been made in Antonino's program, which I would be totally unaware of -- this has been kind of a hot-house isolated effort in sparse spare time. I'd appreciate any advice, information, or contacts you could provide in helping me to come out of the closet. Thanks. Dick Atlee ------ End of forwarded mail by DFTCU@CUVMA.