Continued checkout of the keyboard device controller logic - issues and progress

EXHAUSTIVE TEST OF EVERY KEY VALUE

I had a short program entered that issued an XIO Control to select the keyboard, along with an interrupt routine that read the keypress value and loaded it into the ACC register before returning to the XIO Control instruction to reissue it. 

Each time I press a key, it locks down, triggers an interrupt on level 4 and waits. The interrupt routine reads the bit value into a memory location, loads that into the accumulator to make it easily visible to me at the console, then branches out of the interrupt routine to do reenable the keyboard. The XIO Control causes the reset solenoids to unlock the keyboard and turns on the Select lamp on the console. 

In addition to the keys that produce hollerith values, there are three field oriented keys - backspace, erase field and end field. Since a punched card is twelve rows, the hollerith is returned in the leftmost 12 bits while bits 12, 13 and 14 represent these special field keys. 

A Numeric shift key alters the hollerith returned when a particular keystem is pressed - changing it from the alpha (lower) symbol to the upper symbol. The Keyboard Restore key just unlocks the keyboard and removes the hollerith encoding of whatever key had previously been depressed. The Interrupt Request key triggers an interrupt on level 4 and the Device Status Word tells us that key was pressed rather than any other key. 

RESULTS OF THE TESTING

I checked all the alpha position codes (bottom character on each keycap, emitted when the Numeric key is NOT depressed). However, Numeric did nothing, the character was always the alpha version. 

REPAIR OF NUMERIC KEY FUNCTION

I disassembled everything and found that the Numeric key is a spring loaded plunger that pushes a leaf spring microswitch, but the plunger was missing the leaf entirely. I loosened and moved the mount so that this is now working properly. My VOM verified that the microswitch itself works properly. 

I didn't have time to run through all the numeric (upper character) codes of the keycaps as there was an angry lightning storm hitting the area. I though it wise to keep the machine and my sensitive test gear disconnected from the power lines until the strikes were over. 

HEAD START ON ADDITIONAL PERIPHERAL TESTING

I had previously verified that the Console Entry Switches, 16 toggle switches across the front of the console printer, are correctly read into memory with the XIO Read instruction.

The console printer and the disk drive are not yet working, but I could check for the appropriate bits that say so in the Device Status Words for those devices. I see that bit 5 is on for the keyboard/printer device controller when I read the DSW, which is due to the Forms Out condition (no paper in typewriter) also visible as a console lamp. 

To round out the other testing that is possible at this point for I/O devices, I issued sense device XIOs to the internal disk drive and to the 1231 Optical Mark Reader, as both of these device controllers are configured into this system. I did see the Disk Not Ready bit (3) for the disk drive along with Carriage Home and the sector number value was its default of b'11 so that was a good omen. The 1231 DSW was completely zeroes, while I had expected to see bit 15 for the optical mark device indicating that it is not ready.  

It is possible that the Not Ready condition has to be generated by the 1231 itself and with nothing attached to the connector, the lack of a bit is appropriate. If I had the ALDs for the 1231 controller I could check on this possibility, but for now I won't worry about this. 

There are no device controllers configured for the 1442, 1132, 1134, 1055 or 1627, thus an XIO to them will result in a completely empty DSW every time. I verified this result. 

TESTING THE ABILITY TO RESET INTERRUPT LEVELS WITH A BOSC INSTRUCTION

The Branch or Skip on Condition (BSC) instruction has a special function overlaid on it, active when bit 9 of the instruction is set to 1. This makes it a Branch Out (BOSC) that would end an interrupt handler and turn off the level. 

I tested this independent of the keyboard by using the Prog Stop button on the console. This button generates an interrupt on Level 5 and sets a bit in the Interrupt Level Status Word (ILSW) to indicate the button was the source of the interrupt. The button acts as a single shot to trigger the request, thus the level will turn off if you issue a BOSC while the level is active.

I tried to reset it with a short format (single word) BOSC instruction, but it didn't shut off. I hauled out the scope probes and monitored the gate that sets the -Branch Out signal which flips off the interrupt level at every T6 clock state if the signal is active. 

I wasn't seeing it trigger although most of the input conditions were met. It was a BSC instruction, it was short format, and Bit 9 of the instruction had been set. The logic to set this signal has two AND gates, one for the short format and one for the long format BOSC. 

Looking closer at the AND gate, I identified a fourth input condition, +Skip Condition, which means that the BSC would have skipped the next sequential instruction. The behavior of 1130 instructions is somewhat convoluted, in that behaviors switch based on factors such as short versus long format, use of index registers, etc. I hadn't remembered this particular subtlety, but once I changed the BOSC instruction to give it all possible conditions, at least one of them was satisfied, the BOSC skipped, the signal was set and indeed my -Branch Out was active, resetting the interrupt level as desired!

I therefore know there is a defect in the keyboard device controller logic that causes it to stay in level 4 perpetually. The trigger is turned off by the XIO Sense Device when bit 15 is on (called an XIO Sense Device with Reset). Thus when the interrupt handler is exited by a BOSC the interrupt level goes off. Not so with the current machine - once a key press has triggered a request for level 4 interrupt, it cannot be turned off with reset to the entire machine. 

The logic involved is well localized and should be easy to watch with the scope and debug. I will work on this next time I visit the shop. 

MINOR RANT ABOUT THE CONVOLUTED INSTRUCTION BEHAVIORS

As one example of the modal change in behavior, lets look at the BSC instruction. It either flows to the next sequential instruction or takes a branch, depending on whether some conditions are met. These are defined states such as zero accumulator, carry sign on, and so forth. 

However, the short version of BSC will skip when any of the conditions are satisfied; the long version branches only when NONE of the selected conditions are true. Inverses of each other, dependent on the length of the instruction.

Next, the BSC does different things in short versus long. The short instruction either drops to the next address (N+1) or skips over a word to execute N+2. The long instruction either branches to some absolute address encoded in the second word of the instruction or drops through to N+1. 

Other instructions are similarly modal. The short format Modify Index Register and Skip (MDX) instruction can jump to an address relative to the current position, or jump to the pointer in an Index register with a relative displacement added to it. The relative jumps are -127 to +128 words from the location where the instruction is executing. 

The long format of MDX is quite a bit different. With no index register specified, a long MDX is also called a Modify Memory as it will add the relative displacement (-127 to +128) to the contents of the memory location pointed at by the second word of the instruction. It is often used to bump a counter or lock word in memory.

If the long format MDX has an index register specified, its behavior is to add some value to the index register. If the instruction has the Indirect Address bit on, then the location in the second word of the MDX is read and the contents of that location are added to the register. Without IA, the value of the second word of the MDX is added to the register,  without involving any memory location. 

One has to remember these rules which are hard to codify in a reference card thus easy to forget if you are not regularly coding for the 1130. At least, that is my excuse for why I  was rusty and made a few mistakes.