bridger%rcc@RAND-UNIX.ARPA (Bridger Mitchell) (04/21/88)
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