More thoughts on the cause of the parity checks on certain keystrokes

TRIGGERING THE IL4 INTERRUPT WHEN A KEY IS PRESSED

Once an XIO Control instruction has been issued to select the keyboard, restoring any previously pressed keys, the twelve bits generated by the keyboard (forming the Hollerith code for the key) are funneled to the Keyboard Response flipflop which will be set if any one or more of those bits turn on. 

The Keyboard Response requests an interrupt on level 4, which diverts code execution to the interrupt handler software. Once the source is identified as the console, the software checks the specific cause via an XIO Sense Device and sees the bit set for KB response. It then issues an XIO Read to grab the value from the key that was pressed and stores that into the memory location pointed to in the XIO. 

I have slimmed down the ALD page to remove unneeded detail. The path marked in red shows the flow of a positive signal from the keyboard (KB Bit 7 - for punched card row 7) that will eventually be stored in memory as bit 9 during the XIO Read. However, the red path shoes all the bits are combined in an OR gate and flow to the controller logic to trigger the Keyboard Response FF and interrupt request. 

The path in green is only enabled once the XIO Read command is issued. Before that read is issued, there is no path from the various keyboard outputs to the Storage Buffer Register where it will be written to memory. In the scope results shown in the last post on this error you could see that the bits for the intended character did sharply turn on right when the XIO Read was issued. 

However, we could see random noise on the SBR bit 9 signal line which began exactly as the Keyboard Response FF turned on. This was what triggered the interrupt initially and the signal on that bit 9 continues to wobble up and down rather than being latched into place in the card implementing SBR Bit 9. 

When the keyboard is restored (all keys up) and selected (KB Sel lamp is on), the +12V is isolated from the circuitry by a microswitch. Once a key is pressed down to latch some contacts forming the Hollerith key code, the 12V is connected to present those bit values to the controller logic. The KB Response flipflop can't be set until the voltage is present on those lines.

This is a simplified version of the keyboard wiring showing the routing of the +12V from the KB Restore Bail Contact switch at the upper left, through the All and either the Numeric or the Alpha buses, through some bail and latch contacts. Latches are under a keystem, while bails are triggered by any of a number of keys. 

We know that the paths from the two diagrams above are involved because no request for IL4 occurs until I press down on a key. The random looking signal on bit 9 is not coming through the 4615 card (assuming it is working correctly) because that would only be present once the XIO Read is issued. Thus we have one mystery - what is causing the random signal on bit 9. 

That may also be the bit that first triggers the KB Response interrupt but we don't know for sure. We see it visible only when the KB response goes active, which is suggestive, but not definitive. The trigger could actually be one of the bits actually part of the Hollerith code for the key, but someone the bit 9 noise is there. 

There is no path from the keyboard to the SBR bit 9 until the XIO Read is issued, thus we may have an entirely different source that is not connected at all to the keyboard. We may only be sensitive to that noise once the controller logic is watching the SBR. Further, the SBR should be latching the value of the keyboard bits only at one clock cycle and holding them steady afterwards, so that the noise, varying with time, should not be from the keyboard.

What is strange is that the parity check issues only seem to crop up when we alternate between keys that have keyboard bits 6 and 7 active. Such pairs include F/G, W/U, and O/P. Typing keys that don't involve those bits get no false parity checks. Typing either of the characters initially has no error, it comes up when I move from one of the pair to the other in either direction. This is misleadingly pointing at the keyboard as the source of the issue, although the lack of an XIO Read and the wavering nature both are inconsistent with a keyboard origin. 

This one is going to take more scope captures and experimentation to further narrow down the possibilities and eventually find the one culprit.