RT-11 provides an interface into the terminal handler that lets you simulate the console hardware under all monitors.

The console hardware can be simulated under single terminal and multiterminal monitors. The program can check the MTTY$ bit in $SYSGE to determine if the system uses multiterminal support.

The data and instructions in the simulation code must reside in kernel memory and must not be in PAR1 as they are accessed by the monitor from interrupt code. (Single Terminal Software Simulation)

Simulating the console terminal in a single terminal system requires redirecting either the terminal input or the output registers or both. Then, an interrupt to a redirected hardware register is directed to the software emulation. (Data Structures\single_data_sec)

The data structures required to support console terminal software simulation are found in the following RMON fixed area offsets: (3\6\8) (Offset\Name\Contents) (304\$TTKS\Pointer to input CSR (RCSR)) (306\$TTKB\Pointer to input DATA register (RDAT)) (310\$TTPS\Pointer to output CSR (XCSR)) (312\$TTPB\Pointer to output DATA register (XDAT)) (372\$SYSGE\MTTY$ bit indicating nonmultiterminal or multiterminal support) (470\$XTTNR\Pointer to a routine to be called when there is no room for input characters in the terminal input buffer.) (476\$XTTPS\Pointer to routine called before reading @TTKS and after changing @TTKS) (500\$XTTPB\Pointer to routine called after changing @TTKB) (Setting Up the Terminal Input Software Simulation)

The following figure illustrates the structure of the hardware terminal input data structures before software simulation.

(postscript\s560ab_inbefload.eps\8)

Use the following procedure to replace the hardware terminal input with the software simulation: (numbered) Raise the processor priority to prevent interrupts and other interference. Save the contents of RMON fixed offsets $TTKS and $TTKB, preserving the addresses of the hardware registers RCSR and RDAT:

Copy $TTKS to location OTTKS.

Copy $TTKB to location OTTKB. Change the contents of those offsets to point to locations in memory that serve as the software simulated RCSR and RDAT. You could call those locations TTKS and TTKB, respectively.

The monitor then accesses TTKS and TTKB for terminal input, rather than the actual hardware registers. Save the contents of RMON fixed offset $XTTNR by copying it to location (OXTTNR). Change the contents of $XTTNR to point to a routine in your code that simulates the hardware console's XOFF 'bell' when there is no room for a character in the monitor's terminal input buffer. Lower the processor priority.

The following figure illustrates the simulated terminal input structure after performing those steps.

(postscript\s560ab_inafload.eps\16) (Providing an Interrupt Source\single_int_sec)

The software must simulate the action of a DL11, by using interrupts to notify the monitor of input characters, as follows: (unnumbered) Hook into the line time clock interrupt vector and use it as the interrupt source.

Save the current value in location 100. Replace the contents of 100 with the address of an interrupt routine in the simulation code. The interrupt routine determines if a console input interrupt is needed. If so, the routine can use the PIRQ hardware (if necessary) to post such an interrupt. The interrupt routine then jumps to the original contents of 100 to process the normal clock code. (Operation\single_inop_sec)

The following list is a guide to operating the simulated terminal input. (unnumbered) Entry from interrupt source

When the simulation code is entered by the interrupt source: (numbered) Check if there is a character in RECHAR or an active buffer with a character available.

If there is a character in RECHAR, place it in location TTKB and clear RECHAR.

If there is an active buffer with a character available, place it in TTKB and in LCHAR and update the buffer pointer and count.

Otherwise, just jump out, done. Set the DONE bit in TTKS. If the IENABL bit is set in TTKS, then post an interrupt for the console input vector (60). Entry from XTTNR

If the simulation code is entered from XTTNR (as a result of a full monitor input buffer): (numbered) Move the character in LCHAR to RECHAR, setting up a retry for this character. Pop the top of the stack and do a RETURN (to return to the caller's caller) which will suppress sending a BELL char in response buffer overflow. Posting interrupts

The input simulation cannot directly simulate an interrupt because the monitor may be using a priority level to synchronize operations. Instead of direct simulation, use the PIRQ hardware to post and deliver interrupts.

Interrupt dispatching for input or output (but not both) simulation is fairly simple. The interrupt dispatching for both input and output simulation is more complicated; PIRQ interrupts must be sorted out separately for input and output simulation. Unloading the input simulation software

Unload the input simulation software by restoring the structures to their premodified state, using the values you stored when loading the software. (simple) Restore $TTKS from OTTKS. Restore the hardware RCSR from TTKS. Restore $TTKB from OTTKB. Restore $XTTNR from OXTTNR. (Setting Up the Terminal Output Software Simulation)

The following figure illustrates the structure of the hardware terminal output data structures before software simulation:

(postscript\s560ab_outbefload.eps\11)

Use the following procedure to replace the hardware terminal output with the software simulation: (numbered) Raise the processor priority to prevent interrupts and other interference. Save the contents of RMON fixed offset $TTPS, preserving the address of the hardware register XCSR.

Copy $TTPS to OTTPS.

Copy @$TTPS to PTTPS to create a second copy of XCSR. PTTPS is discussed later. Clear @$TTPS to prevent interrupts from the actual hardware. Change the contents of $TTPS to point to a location in memory that serves as the software simulated XCSR; you could name that location TTPS.

The monitor then accesses TTPS for terminal output, rather than the actual hardware register. Save the contents of RMON fixed offset $TTPB, preserving the address of the hardware register XDAT:

Copy $TTPB to OTTPB. Change the contents of $TTPB to point to a location in memory that serves as the software simulated XDAT; you could name that location TTPB.

The monitor then accesses TTPB for terminal output, rather than the actual hardware register. Save the contents of RMON fixed offset $XTTPS, by copying it to location OXTTPS.

Change the contents of $XTTPS to point to XTTPS, the simulated XCSR action routine. Save the contents of RMON fixed offset $XTTPB, by copying it to location OXTTPB.

Change the contents of $XTTPB to point to XTTPB, the simulated XDAT action routine. Lower the processor priority.

The following figure illustrates the simulated terminal output structure after performing those steps.

(postscript\s560ab_outafload.eps\22) (Operation\single_outop_sec)

The following list is a guide to programming the simulated terminal output. (unnumbered) Calling the XTTPS simulated action routine.

The monitor calls XTTPS before it reads or after it modifies TTPB. If the monitor modifies and then reads TTPB, it calls XTTPS only once, between the modify and the read.

Do the following when calling XTTPS: (numbered) Save the current condition codes and any work registers. Copy the DONE bit (200) setting from PTTPS to TTPS. If the DONE bit is SET, check the IENABLE bit (100) in PTTPS.

If the IENABLE bit in PTTPS is clear and the IENABLE bit in TTPS is set, post an interrupt for the console output interrupt vector (64). Copy TTPS to PTTPS. Restore the saved condition codes and any work registers. Calling the XTTPB simulated action routine.

The monitor calls XTTPB after it modifies TTPB.

Do the following when calling XTTPB: (numbered) Save the current condition codes and any work registers. Pick up the low byte of TTPB as the next output character. Set the DONE bit in PTTPS and TTPS. If the IENABLE bit (100) in TTPS is set, post an interrupt for the console output terminal vector (64). Restore the saved condition code and any work registers. Posting interrupts

The output simulation cannot directly simulate an interrupt because the monitor may be using a priority level to synchronize operations. Instead of direct simulation, use the PIRQ hardware to post and deliver interrupts.

Interrupt dispatching for input or output (but not both) simulation is fairly simple. The interrupt dispatching for both input and output simulation is more complicated; PIRQ interrupts must be sorted out separately for input and output simulation. Unloading the output simulation software

Unload the output simulation software by restoring the structures to their premodified state, using the values you stored when loading the software. (simple) Restore $TTPS from OTTPS. Restore the hardware XCSR from TTPS. Restore $TTPB from OTTPB. Restore $XTTPS from OXTTPS. Restore $XTTPB from OXTTPB. (Multiterminal Software Simulation)

Simulating the console terminal in a multiterminal system requires redirecting a single pointer, T.CSR, rather than the four separate pointers in a single terminal configuration. The input and output CSR and data registers are offset from the address pointed to by T.CSR. This is the major difference between simulating the hardware console terminal with a multiterminal monitor, as opposed to the single terminal monitor. (Data Structures)

Besides the data structures described in (single_data_sec), support for multiterminal console terminal simulation requires:

(4\10\8\8) (Location\Offset\Name\Contents) (RMONFixed\446\$IMPLO\Pointer to background impure area.) (ImpureArea\016\I.CNSL\Pointer to TCB.) (TCB\014\T.STAT\DZ11$ and DH11$ bits; if either set, then not a DL11 interface (and operation is invalid).) (\016\T.CSR\Pointer to input CSR; registers are addressed as offsets from this value.) (RMONFixed\466\$CNFG3\Contains CF3.1S bit; if set, indicates support for one DL11 interface under multiterminal monitor.) (Setting Up the Multiterminal Software Simulation)

The following figure illustrates the structure of the multiterminal monitor console terminal data structures before loading the software simulation. Notice that the CSR and data registers are offset from the address pointed to by T.CSR.

(postscript\s560ab_mttybefload.eps\16)

Use the following procedure to replace the hardware multiterminal console terminal with the software simulation: (numbered) Raise the processor priority to prevent interrupts and other interference. Search the table just before $IMPLO in the RMON fixed offset area for the address of the background impure area.

If handler load code is being run, then the current job is the background and the value in offset $CNTXT can be used. Get the address for the job's console TCB from the I.CNSL word in the TCB. Check the T.STAT word in the TCB to make sure both DZ11$ and DH11$ bits are clear. If either is set, software simulation cannot be used. Save T.CSR by copying it to OTCSR. Save the address pointed to by T.CSR by copying it to TTKS, the simulated RCSR. Clear the hardware RCSR (pointed to by T.CSR) to prevent interrupts from the actual hardware. Copy the contents of the hardware XCSR (pointed to by T.CSR+4) to TTPS, the simulated XCSR.

Also copy the contents of the hardware XCSR to PTTPS, creating a second copy of XCSR at PTTPS.

Then, clear TTPS to prevent interrupts from the actual hardware. Change the contents of T.CSR to point to TTKS.

The three other simulated registers, TTKB, TTPS, and TTPB, are located after TTKS in memory. Copy $XTTNR to OXTTNR.

Then, change the contents of $XTTNR to point to XTTNR, the routine to be called when there is no room for input characters at the terminal input buffer. Copy $XTTPS to OXTTPS.

Then, change the contents of $XTTPS to point to XTTPS, the simulated XCSR action routine. Copy $XTTPB to OXTTPB.

Then, change the contents of $XTTPB to point to XTTPB, the simulated XDAT action routine. Lower the processor priority.

The following figure illustrates the simulated multiterminal monitor input/output terminal structure after performing those steps.

(postscript\s560ab_mttyafload.eps\32) (Identify the Console Terminal)

The need to identify the console terminal arises when there is more than one DL11 interface on the system. Check CF3.1S; if set, there is one DL11 interface and no further identification is necessary.

If CF3.1S is clear, the console replacement code must determine if calls to the action routines ($XXTNR, $XTTPS, $XTTPB) are for the supplanted terminal or another. When an action routine is called, the contents of R4 should be compared with the saved value OTCSR. If they are the same, the action routine is directed at the correct terminal. (Operation\mtty_op_sec)

The software simulation of the hardware console terminal is the same under multiterminal and single terminal monitors. See (single_int_sec) and Sections (single_inop_sec\value) for the input simulation procedure and (single_outop_sec) for the output simulation procedure.

Unload the input simulation software by restoring the structures to their premodified state, using the values you stored when loading the software. (simple) Restore T.CSR from OXTTPB. Restore RCSR from TTKS. Restore XCSR from TTPS. Restore $XTTNR from OXTTNR. Restore $XTTPS from OXTTPS. Restore $XTTPB from OXTTPB. (AA Dummy index entries to get "INDEX" in table of contents.) (AB The real index for this manual is in a separate skeleton) (AC index file. Process that file separately, then take the) (AD index produced from that file, insert in place of this page,) (AE and throw this page away.)