home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / cpm / rcpm / newbye.msg < prev    next >
Encoding:
Text File  |  1987-12-29  |  3.3 KB  |  80 lines
  1.                      Thoughts for a new BYE
  2.                  Bridger Mitchell, Dec. 24, 1987
  3.  
  4. Discussions with Al Hawley have prompted me to set down notes
  5. about how basic improvements could be added to BYE - the
  6. host executive for remote-system operation.  These are just
  7. that -- notes for discussion, to be added to and improved on!
  8.  
  9. For CP/M 2.2 BYE should be constructed as a standard RSX, using
  10. the Plu*Perfect Systems' RSX header (see BackGrounder ii manual,
  11. Appendix I).  This standard header has two key advantages:
  12. other RSX's can be loaded and unloaded below it and it provides
  13. for its own removal/deinitialization.
  14.  
  15. The RSX image itself should be in PRL or REL format, and loaded
  16. by a quasi-standard RSX loader, customized for BYE's particular
  17. requirements and features.  Splitting the code into resident
  18. module and loader module makes it far easier to maintain and
  19. makes the relocation process painless.  A sample loader is
  20. available on the BGii disk.
  21.  
  22. The new BYE can support two different, parallel terminals, each
  23. with terminal-specific video sequences.  The key to accomplishing
  24. this is to use a "generic" tcap in the z3 external environment,
  25. and have conout (which is intercepted by BYE) translate the
  26. generic video sequences differently for each terminal.
  27.  
  28. One limitation:  while BYE is running, programs that use video
  29. sequences should be restricted to those that either use the z3tcap
  30. itself, or have been installed with the "generic" tcap.
  31.  
  32.  
  33. on init:
  34.         move current z3tcap to local_tcap
  35.         move generic tcap to z3tcap buffer
  36. on deinit:
  37.         move local_tcap to z3tcap buffer
  38.  
  39. generic tcap:
  40.         a "generic" set of escape/control-char sequences.  It may be
  41.         best to choose/create a set that all have a fixed number of bytes.
  42.         e.g. ESC A = cleol, ESC B = cleos, ...
  43.  
  44.         However, if sysops have programs that have internal video strings
  45.         (rather than getting them from z3tcap) it would be nice to have
  46.         the generic set be the same as the sysop's terminal's tcap, so
  47.         that he/she wouldn't have to install a separate version of those
  48.         programs for running while BYE is active.
  49.  
  50.  
  51. remote_tcap:
  52.         installed by an upgraded T3SELECT, which puts the selected
  53.         tcap into the remote_tcap buffer, NOT the z3tcap buffer
  54.  
  55.         To accomplish this, the new BYE should have a service
  56.         call that returns pointers to internal data structures,
  57.         including the remote_tcap buffer.  It can usefully
  58.         return ptrs to other (configurable) parameters for other
  59.         applications, too.
  60.  
  61.         The local and remote tcap buffers should be located within the RSX.
  62.  
  63. conout routine:
  64.         The BYE conout splits the output stream into two parallel
  65.         streams -- for the remote user and the local console.  The
  66.         code would work as follows:
  67.  
  68.         1. accumulate input chars in an input state-machine
  69.  
  70.         2. if input-string == a generic tcap string
  71.                 emit local_string to local conout
  72.                 emit remote_string to modem output device
  73.            else
  74.                 emit byte to local conout
  75.                 emit byte to modem output device
  76.  
  77.         The conout routine is probably best realized as three small
  78.         state machines, one for input-recognition, and one for each
  79.         output device (local, remote).
  80.