home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / archives / mskermit.tar.gz / mskermit.tar / msxapr.bwr < prev    next >
Text File  |  1988-08-16  |  6KB  |  135 lines
  1. MS-DOS Kermit v2.27 for ACT Apricot
  2. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  3.  
  4. There should be no problem with assembling and linking this version,
  5. except that the module 'msxdmb' should be linked first.  This is to
  6. ensure that the object segments are linked in the correct order.
  7. Leaving out that module prevents proper use of PUSH, RUN, DIR, SPACE,
  8. and LOCAL.  What actually happens is this:
  9.  
  10.   1) MS-DOS allocates the entire free memory to the currently running
  11.      program, so Kermit needs to de-allocate the space it doesn't use.
  12.  
  13.   2) Kermit locates the end of itself by assuming that its stack seg
  14.      is its highest point in memory.  It then calls the MS-DOS function
  15.      to shrink the allocated memory down to that point.
  16.  
  17.   3) Kermit then calls the MS-DOS function to load and execute the
  18.      required program, which goes into the free memory.
  19.  
  20.   4) Program loads, but Kermit has placed parameter control blocks in
  21.      its own data seg which tends to be placed ABOVE the stack seg by
  22.      the linker, so it gets zapped by the newly loaded program.......
  23.  
  24.   5) Sudden death ensues......  Actually, I think you're left in an
  25.      inferior command process, if you try to EXIT back to Kermit, the
  26.      whole thing dies because its data seg has been blown away.
  27.  
  28.  
  29. Any questions/problems should be addressed to:
  30.  
  31.      Ralph Mitchell
  32.      Computer Centre
  33.      Brunel University
  34.      Uxbridge
  35.      Middlesex
  36.      UB8 3PH
  37.  
  38. ------------------------------
  39.  
  40.                     14 August 1985
  41. Dear Alan,
  42.  
  43.      This file should arrive along with an updated copy of MSXAPR.ASM:
  44.  
  45.           o The various procedures have been sorted by name so that it's
  46.             easier to find them...
  47.  
  48.           o It now displays a mode line on line 25 when in CONNECT state.
  49.             This is displayed in high intensity rather than inverse video,
  50.             but that could be changed.  I think inverse video can be a bit
  51.             hard on the eyes...
  52.  
  53.           o The keyboard is re-programmed so that CTRL-[ and CTRL-] return
  54.             real control characters instead of printing characters.  This
  55.             does not revert to normal on leaving Kermit.  Thanks to
  56.             Dr. Akers for this fix.
  57.  
  58.           o On Apricot PC and XI keyboards there is a dot-matrix LCD micro-
  59.             screen with six touch switches.  The screen normally displays
  60.             the time and date.  In CONNECT state it now also displays the
  61.             words 'BREAK CLOSE STATUS PUSH HELP LOG' and the keys are
  62.             programmed to supply the appropriate escape sequences for each
  63.             of these functions.  This reverts to normal when the esc char
  64.             is typed.
  65.  
  66.             Note:  The LOG key toggles logging on and off only if logging
  67.                    is enabled.  i.e. It mimics CTRL-[Q or CTRL-[R, depending
  68.                    on the current state of the switch.
  69.  
  70.           o The screen is NEVER saved when leaving CONNECT state.  This is
  71.             because I haven't yet figured out how to restore it.  The
  72.             problem is that the screen memory holds 25.6 lines in a kind of
  73.             circular buffer and the screen is scrolled by changing a pointer
  74.             in the CRTC (I think).  The extra 6/10 of a line means that for
  75.             every time a complete screen scrolls up, the origin (top left)
  76.             is advanced by 48 characters.  I've tried saving and restoring
  77.             the CRTC registers, but it only works if the screen hasn't
  78.             scrolled since the last clear-screen.  If anyone has any ideas
  79.             I'd be only too pleased to try them out...
  80.  
  81.           o Key re-definitions are not available at the present time.
  82.  
  83.           o XON/XOFF are handled by the Apricot 'hardware'.  It is only
  84.             possible to change it by re-initializing the SIO, which drops
  85.             DTR and RTS.  This is not always desirable, so I have left it
  86.             permanently on.
  87.  
  88.  
  89.      Apart from these differences, Apricot Kermit is just like the IBM-PC
  90. version.
  91.  
  92.             Regards
  93.  
  94.             Ralph Mitchell
  95.  
  96. ------------------------------
  97.  
  98. Date:  Sun, 22 Jun 86 16:01+0100
  99. From:  Mitchell@UK.AC.BRUNEL
  100. Subject:  Re: Apricot Query
  101. To:  SYSKERMIT@UK.AC.LANCASTER.CENTRAL.VAX1
  102.  
  103.    The Apricot screen driver looks like a VT52, but it can also handle a
  104. lot of ansi control sequences...  It DOES display a mode line in CONNECT
  105. state, but it only redefines a few keys.  What it does is this:  there
  106. is a micro- screen that normally displays a clock, but also has
  107. "soft-keys" which can be labelled using the micro-screen display.  The
  108. keys can also be programmed to produce character strings.  In connect
  109. state, the soft-keys are redefined to give single-key-press CLOSE,
  110. BREAK, STATUS, HELP, LOG toggle, and one other I can't remember.  I've
  111. tried doing screen rollback, but it's a real pain when copying back to
  112. the screen.  The screen memory is such that it has an extra .6-of-a-line
  113. and somehow it gets scrolled when it hits the end.  I haven't been able
  114. to locate the pointers.  If fact, doing ANYTHING to the screen once it's
  115. been written is a pain...  Screen dump and Print Screen would be nice I
  116. guess, but it would have to go out the the Centronics port, and we don't
  117. have a Centronics printer to spare...  I generally ship output down to
  118. the Multics...  There is actually a key labelled PRINT, but it only
  119. prints the screen when controlled by software; it's not a hardwired
  120. function.  Also, reading from the screen memory is a pain because what
  121. you get is a pointer offset into a character table.  The table is
  122. pointed to by the contents of four locations at around 700H absolute,
  123. and I'm not too hot on pointer arithmetic in 8086 assembler...
  124.  
  125. Actually, that may be wrong...  There is a key definition table that's
  126. used to find out what a key should return, that has a pointer at ~700H.
  127. There's also a font table stashed somewhere else, and you can bet the
  128. screen memory doesn't hold ASCII characters.  More likely to be offsets
  129. into the font table...
  130.  
  131. Ralph Mitchell
  132.  
  133. ------------------------------
  134.  
  135.