Columbia Kermit/kermit.zip/mskermit/msxapr.bwr

Text File | 2020-01-01 | 6KB | 135 lines

MS-DOS Kermit v2.27 for ACT Apricot
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

There should be no problem with assembling and linking this version,
except that the module 'msxdmb' should be linked first.  This is to
ensure that the object segments are linked in the correct order.
Leaving out that module prevents proper use of PUSH, RUN, DIR, SPACE,
and LOCAL.  What actually happens is this:

  1) MS-DOS allocates the entire free memory to the currently running
     program, so Kermit needs to de-allocate the space it doesn't use.

  2) Kermit locates the end of itself by assuming that its stack seg
     is its highest point in memory.  It then calls the MS-DOS function
     to shrink the allocated memory down to that point.

  3) Kermit then calls the MS-DOS function to load and execute the
     required program, which goes into the free memory.

  4) Program loads, but Kermit has placed parameter control blocks in
     its own data seg which tends to be placed ABOVE the stack seg by
     the linker, so it gets zapped by the newly loaded program.......

  5) Sudden death ensues......  Actually, I think you're left in an
     inferior command process, if you try to EXIT back to Kermit, the
     whole thing dies because its data seg has been blown away.


Any questions/problems should be addressed to:

     Ralph Mitchell
     Computer Centre
     Brunel University
     Uxbridge
     Middlesex
     UB8 3PH

------------------------------

                    14 August 1985
Dear Alan,

     This file should arrive along with an updated copy of MSXAPR.ASM:

          o The various procedures have been sorted by name so that it's
            easier to find them...

          o It now displays a mode line on line 25 when in CONNECT state.
            This is displayed in high intensity rather than inverse video,
            but that could be changed.  I think inverse video can be a bit
            hard on the eyes...

          o The keyboard is re-programmed so that CTRL-[ and CTRL-] return
            real control characters instead of printing characters.  This
            does not revert to normal on leaving Kermit.  Thanks to
            Dr. Akers for this fix.

          o On Apricot PC and XI keyboards there is a dot-matrix LCD micro-
            screen with six touch switches.  The screen normally displays
            the time and date.  In CONNECT state it now also displays the
            words 'BREAK CLOSE STATUS PUSH HELP LOG' and the keys are
            programmed to supply the appropriate escape sequences for each
            of these functions.  This reverts to normal when the esc char
            is typed.

            Note:  The LOG key toggles logging on and off only if logging
                   is enabled.  i.e. It mimics CTRL-[Q or CTRL-[R, depending
                   on the current state of the switch.

          o The screen is NEVER saved when leaving CONNECT state.  This is
            because I haven't yet figured out how to restore it.  The
            problem is that the screen memory holds 25.6 lines in a kind of
            circular buffer and the screen is scrolled by changing a pointer
            in the CRTC (I think).  The extra 6/10 of a line means that for
            every time a complete screen scrolls up, the origin (top left)
            is advanced by 48 characters.  I've tried saving and restoring
            the CRTC registers, but it only works if the screen hasn't
            scrolled since the last clear-screen.  If anyone has any ideas
            I'd be only too pleased to try them out...

          o Key re-definitions are not available at the present time.

          o XON/XOFF are handled by the Apricot 'hardware'.  It is only
            possible to change it by re-initializing the SIO, which drops
            DTR and RTS.  This is not always desirable, so I have left it
            permanently on.


     Apart from these differences, Apricot Kermit is just like the IBM-PC
version.

            Regards

            Ralph Mitchell

------------------------------

Date:  Sun, 22 Jun 86 16:01+0100
From:  [e-mail]
Subject:  Re: Apricot Query
To:  [e-mail]1

   The Apricot screen driver looks like a VT52, but it can also handle a
lot of ansi control sequences...  It DOES display a mode line in CONNECT
state, but it only redefines a few keys.  What it does is this:  there
is a micro- screen that normally displays a clock, but also has
"soft-keys" which can be labelled using the micro-screen display.  The
keys can also be programmed to produce character strings.  In connect
state, the soft-keys are redefined to give single-key-press CLOSE,
BREAK, STATUS, HELP, LOG toggle, and one other I can't remember.  I've
tried doing screen rollback, but it's a real pain when copying back to
the screen.  The screen memory is such that it has an extra .6-of-a-line
and somehow it gets scrolled when it hits the end.  I haven't been able
to locate the pointers.  If fact, doing ANYTHING to the screen once it's
been written is a pain...  Screen dump and Print Screen would be nice I
guess, but it would have to go out the the Centronics port, and we don't
have a Centronics printer to spare...  I generally ship output down to
the Multics...  There is actually a key labelled PRINT, but it only
prints the screen when controlled by software; it's not a hardwired
function.  Also, reading from the screen memory is a pain because what
you get is a pointer offset into a character table.  The table is
pointed to by the contents of four locations at around 700H absolute,
and I'm not too hot on pointer arithmetic in 8086 assembler...

Actually, that may be wrong...  There is a key definition table that's
used to find out what a key should return, that has a pointer at ~700H.
There's also a font table stashed somewhere else, and you can bet the
screen memory doesn't hold ASCII characters.  More likely to be offsets
into the font table...

Ralph Mitchell

------------------------------