Date : Wed, 20 Apr 1988 11:23:26 PDT
From : Bridger Mitchell <bridger%rcc@rand-unix.ARPA>
Subject: Visible ^P BDOS status
It's going to be difficult to come up with a portable method of
providing visible reporting of ^P status. Here are some rough
thoughts.
1. Determining the status. Unlike CP/M Plus, CP/M 2.2 and its
emulators (ZRDOS, QP/M, ...) have no status-reporting function.
You could:
a) locate the status byte in your particular BDOS, by
disassembly.
b) write an RSX to intercept console output functions (and
warmboot) and emulate the toggling of ^P. The warmboot
trap will need to account for the fact that
the BDOS will now not be reloaded on warmboot, and the
status byte therefore not reset. Without an RSX in place
your BDOS may or may not be reloaded on warmboot, depending
on the BIOS implementation of the warmboot function.
Initializing the shadow status byte in your RSX is a
problem, unless you know where the BDOS's byte is. (i.e.
what if ^P is ON when you load the rsx?)
c. Patch the BDOS so that it will call a routine when it changes ^P
status. Locate the routine the BIOS or other protected memory.
You will need to take care that the shaddow status in your routine
is correct after a warmboot; the best thing would be for
your routine to inspect the status byte in the BDOS.
2. Detecting change in status.
a. Have an interrupt-service routine triggered by a clock
countdown that checks ^P status once in a while.
b. Have the RSX update the cursor/25th line if it is emulating
^P toggling.
c. be called by the BDOS patch (1c above).
3. Displaying status. This will require terminal-specific data.
Changing the cursor type can usually be done by sending an escape
sequence to conout. An alternative is to display an enduring message
on the "25th line" of terminals with such a feature. (A message
located on a regular text line will quickly scroll off the screen.) Be
sure to call BIOS conout so you don't recurse in the BDOS!
--bridger