A student writes:

        Professor Patt,

        Can I assume that KBSR[14] is initially cleared for the final programming
        If I'm going to run a test to see if interrupts are already enabled, is
        there a possibility that the state of the KBSR could change before my
        program takes proper action based on the result of the test?  What could
        cause such a thing?

First of all:

1. Why do you care what state KBSR[14] is in when you show up?  If you simply set
it, it will be set for the rest of the time you are interested in.

2. If you did care (although I still don't know why), you could simply hit a key
again and again, and see what interrupt service routine is executed again and again.  
If none, then KBSR[14] is not set.  

...or, if you prefer, you could examine memory address xFE00.

        <<name withheld to protect one who wants to keep KBSR[14] under control>>

And, you should also know that:

When a machine is powered up, initially (as is always the case) every bit of every
location in memory, registers, etc. are in whatever state they happen to be in.  
Therefore, in the initiating code, the operating system would set KBSR[14] and every 
other bit to what the operating system desires them to be.  In this case, the operating
system would set KBSR[14] to 1 or to 0, depending on whether it wanted to allow the 
keyboard to interrupt or not allow the keyboard to interrupt.  In the vernacular of 
computer jargon, we often refer to that initiating code as "the boot program."

In our case, since we don't have Windows or Linux installed on the LC-3, we are
asking you to handle these tasks instead.  Note we asked you to do this before
the LC-3 starts executing your program.

Good luck with the final program.

Yale Patt