Our version of the processor sets PSR.Priority (PSR[10:8]) to PL7 (3'b111) on interrupts. The interrupt handler can determine for itself what the appropriate priority should be and reset the PSR. By setting Priority to PL7, no device can cause an interrupt since the priority comparator only allows an interrupt if the incoming priority from the priority encoder is greater than PSR.Priority. This effectively disables interrupts. Subroutine code to manipulate PSR.Priority would look like this,
PSRval: .FILL x0700 ;-- PSR.Priv=0, PSR.Priority=7, PSR.CC=0
SetPSR: ld r0, PSRval ;-- get new PSR
jsr pushR0 ;-- push new PSR
lea r0, done ;-- get dummy PC
jsr pushR0 ;-- push dummy PC
rti ;-- pop dummy PC, pop new PSR
done: retThat can also be used to enable/disable interrupts at any time. (Of course, this can only be done in supervisor mode since RTI is a protected instruction.)
Our keyboard device, KB in lib/IOdevices.jelib, serves as a prototypical I/O device for our LC3. It includes a controller that interfaces with the Memory-I/O bus. It also interfaces with the actual keyboard of the machine running the simulation. This provides a way for actual keyboard event data to be sent to the LC3's KBDR. This is done by running an interface program, kb.c, which gets keyboard events, then writes the key data to a data file and writes a data-ready signal to a handshake file. KB polls the handshake file, reads the data file, and sets the KBSR and KBDR.
The interface, kb.c, spawns a child process to exec "vvp a.out", and that is how the LC3 simulation is started with a keyboard interface. (Future plans call for a second child process to provide a video display interface as well.) However, one can still run the LC3 simulation without running kb.c. In that case, since KB will try to read the data and handshake files, they should be set up in advance by hand, and the simulation is started in the usual way by typing "vvp a.out".
Somewhat realistically, KB consists of two FSMs, one to manage the Memory-I/O bus interactions, the other the keyboard interactions. They both run slower than the system clock. So, it takes time for the keyboard controller to reset the ready bit, for instance. The cpu can reset that bit as the KBSR is read/write. (The KBDR is also read/write, which may be useful in future development.)