Columbia Kermit/kermit.zip/extra/appxxx.txt

Internet Message Format | 2020-01-01 | 10KB

Date:     Tue, 27 Aug 85  12:14 EDT
From:     Dick Atlee <ATLEE@UMDC>
Subject:  Apple DOS Kermit
To:       Kermit Warm Line <DFTCU@CUVMA>

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.