Further digging into the cause of the spurious parity checks doesn't get me to an answer yet

METHODICALLY WORKING MY WAY FROM KEYBOARD TO PARITY GENERATION

I monitored the output of the keyboard so that I was certain it was setting the correct bits in the Storage Buffer Register during the XIO Read to pick up the character code for the key that had been pressed. A sampling pulse arrives to latch the SBR bit to the value coming from the I/O bus which is fed by the keyboard. 

The Storage Buffer Register output was steady from that sampling pulse throughout the time when the XIO Read was storing the values in memory, including when the parity checker falsely declares an error. The SBR output is fed through an inverter in B-B1 L6 although the output does not have a pullup to +3V thus it is difficult to monitor its output state. 

Nothing was obviously wrong with the output of the inverter, to the degree that I could see it, but when the signal arrived at B-B1 L7 where the parity is generated by a tree of XOR gates, the signal looked wonky. 

The yellow trace is the input on the IO bus from the keyboard. The purple trace is when the SBR is set based on that input. The blue trace is the detection of the parity error. What is anomalous is the green trace, which should follow the purple trace since it is just redriving the output of the SBR, but it does its yo-yo maneuver beginning earlier than when the SBR is set. Something else is injecting signals on this net and I have to find it. 

STRUGGLING TO FIND THE LINK SINCE THE KEYBOARD VALUE IS LOCKED IN

After a large number of experiments typing keys I see an inescapable correlation between the keys pressed and the failure. There are a few groups of keys that consistently cause the parity check when sequentially typing from one group and then the other. For example, F, W and O are in one group, while G, X and P are in another. Whether the F is pressed first successfully and then G triggers a parity check, or the G is successfully pressed first and then the F triggers the error, it always involves changing between groups.

Going between F and P or the reverse causes the same error, since they are in different groups. Another group involved the Z key and quite a few other keys, both alpha and numeric. I looked at the generated character codes for these and can see commonalities. The F/W/O group has the Hollerith row 6 active, while the group G/X/P has row 7 active. It appears that the switch between 6 and 7 introduces the error. 

The time between pressing the keys does not seem to matter. Pressing the keys after unrelated keys were used causes no issues. Pressing keys from the same group repeatedly causes no parity check. It only fails when a key from the 6 or 7 group is pressed when the immediately prior key pressed was from the opposite group. 

Since the program waits without an interrupt from the keyboard, we know that none of the contacts are electrically active in between the keypresses. It seems odd that the keyboard could have a memory for which group was pressed just before, based on the mechanism. 

I have to recognize the role that the alternating groups play in triggering the error, even if I don't see any physical means to hold state between the keypresses. That is puzzling fact number one. 

The second puzzling fact is that the signals from the keyboard controller logic are gated, thus they are not even routed to the Storage Buffer Register until an XIO Read instruction is executing. When they are routed to the SBR, a single pulse is sent to latch the input-output bus values into the SBR. This is a one time event; any changes on the signal lines from the keyboard do not pass through. All we have is a snapshot at a single clock cycle when the pulse latches the value into the SBR.

The third puzzling fact is that the output of the SBR appears to generate the odd waveform at least one cycle BEFORE it is latched to the input-output bus state. It wobbles up and down in the pattern we always see. 

Trying to fit these together yields a big headache. Signals should not care about the prior state of the keyboard from its prior keypress. These does not appear to be any mechanism to hold the state memory. The signals from the keyboard are not presented to the SBR until a specific pulse during the XIO Read instruction. The SBR will hold that value latched at a steady state for the remainder of the memory write cycle. Somehow the parity checking XOR tree is seeing a signal wobble, starting before the keyboard data is routed to the SBR, although the XOR is fed by an inverter from the SBR. The wobble only happens when keys were pressed in an order that switched between groups I experimentally found. 

TOOK APART KEYBOARD, ANNOYING ISSUES PUTTING IT BACK INTO SERVICE

I opened the console, unscrewed the keyboard and checked it over for possible errors. I readjusted the restore bail contacts which disconnect the signals while the keys are being unlatched. In any case, if they are changing after the read has finished and during a restore, the data is not being routed anywhere. If for some reason it triggered a new false keypress value, there would be an interrupt - but there is not. 

Many of the connections that feed the signal lines which vary between the groups are created by keystem latches. That is, a set of contacts at the bottom of the stem for the key F make a connection to route +12V out of the Hollerith row 6 wire, while contacts at the bottom of the key G make a connection out of the Hollerith row 7 wire. There is no method for both keys to be done simultaneously, even for a brief moment. Since the prior key was read, the key unlatched and the keyboard restored waiting for the next press, that connection state is long gone by the time another key is pressed. 

One problem that I had a couple of times was that the space bar ended up jammed down in the active position after I remounted the keyboard mechanism into the 1130. That put the machine into a tight loop displaying the Hollerith value for space - all zeroes. 

I removed it, tried to adjust the position as I reinstalled, with a few checks that the spacebar was latching and releasing, but when I closed up everything, the space bar jam was back. I ended the work session at that point, but once I get back I will get this installed successfully with a space bar that functions. I can then go on to track signals and test conditions, trying to sort out the mystery.