Not the XOR card, moving on to investigate setting of parity bit 2

RETRACING SIGNALS AND ABSOLVING THE XOR CARDS

The issue is that bit 8 and 9 are turning on - correctly - from the keypress of an F or G character, but then they oscillate which defeats the parity setting circuit. It looks like a switch bounce, although it is one machine cycle long and completely repeatable. The bit comes on for a cycle, goes off for a bit less than a cycle, then comes back on steadily.

Green traces shows the 'bounce' shape

The keyboard is mechanical, but the key latches down and doesn't move until the character code is ready by an XIO instruction. Therefore no contact is moving to cause a bounce. Further, bounces would not be so deterministic. 

CHALLENGES DEBUGGING

I had so spend the majority of the day trying to identify the root cause because a number of characteristics of IBM SLT based computers introduce problems that produce confusing or ambiguous results on measuring instruments.

The nature of SLT gates, which are Diode Transistor Logic (DTL), means that for the most part, the only significant action on an input is to draw current towards ground (or sometimes a negative voltage). The absence of a current is a logic high, regardless of the voltage present. 

Some gates will have a pullup resistor so that when the final transistor is not conducting, the output rises to the +3V nominal high level. Others, however, do not and they can appear to be at ground when they are at logic high, since the transistor is not conducting and they are not pulling current through it. 

Thus, signals on an oscilloscope which is primarily a voltage measuring device will appear to be at or near ground. They can have glitches and induced signals in them. However if they are not conducting to pull current from gate they are feeding, then they are at logic high. You just can't tell very well using a scope. 

While the stated voltage levels for SLT are 0V for logic low and +3V for logic high, some circuits in the 1130 can have logic high at 9 to 12V and others can have logic low at -3V. You can't tell from the ALD logic diagrams as all gates appear to be standard SLT. 

To save on components, IBM makes extensive use of wired-OR, just tying the outputs of multiple gates together. The signal would be an inverted one, where a logic low means the condition is true. Thus, wiring together many gates creates a shared bus, where any one or more gates can pull the signal low to assert it. 

This matters because the source of an anomalous signal is hard to find when they are wired together into these shared bus 'wired-OR' nets. The output goes down and it could be any of the connected gates that is doing this. If the gate is defective, then looking at the inputs to each gate won't help, because the assertion of the signal is an error. 

The bus can be multiple bit also - the Storage Buffer Register constitutes sixteen bits, each of them a shared bus for that particular bit. In this case, I was debugging a problem where bit 8, fed from multiple sources, was activated with that funny bounce. 

Finally, life is complicated because SLT cards often have multiple circuits on them, which can be assigned to a number of different parts of the machine. Otherwise, the straightforward way to find which gate is pulling down a wired-OR is to yank out the cards implementing the gates one by one. However, when a card is performing other functions at the same time, those can be essential. If the card is pulled, the machine won't work enough to create the situation you are trying to debug. 

Bit 8 is fed by the controller logic for the keyboard, console entry switches, 1132 printer, 1442 card reader/punch, paper tape punch, 2501 card reader, and the internal disk drive. Another source for bit 8 is the logic to process an interrupt; bits are injected onto the SBR to appear to be a BSI Indirect instruction, causing the next instruction to be executed from the location pointed to by the interrupt vector for that interrupt level. 

SLOWLY, PAINFULLY FOLLOWED THE FAILURE UNTIL I FOUND A SUSPECT CARD

The signal is generated in the keyboard controller logic, putting the value on the shared bus when the computer is executing an XIO read instruction for the area code of the console/keyboard. Further, it is during an execution memory cycle of the instruction execution where the value of the keypress is latched into the Storage Buffer Register for writing to the memory location specified in the XIO instruction.

A double size SLT card, number 4615, implements a lot of functions for feeding data from the keyboard and the console entry switches. One of the functions is debouncing of the signals from the keyboard. This is implemented by an RC network plus a diode. I began to suspect that the network was oscillating when the signal switched on. 

Two of these cards are in the machine, at slots A-C1 B2 and A-C1 C2. I swapped them since the one at B2 or C2 seemed to be causing my problems. The problem changed, so that I could type the F and G keys with no falsely detected parity errors. However, other keys would fail, since the problem was just kicked over to the other signal lines from the keyboard. 

WILL BE DEBUGGING THE CARD IN THE COMING DAYS

I do not have the schematics for the 4615 card. It always seems to be failures in card types whose schematics are unavailable! I will put the card sections through its paces on the workbench to try to spot the problem, but undoubtedly I will need to reverse engineer at least some of the circuitry in order to fix it. 

The circuits the two cards implement are listed above, but the names such as C1 refer to sections of the SLT card schematic, which I don't have. We can look all the functions that are on card C2:

One of the debouncer circuits was used for the typewriter End of Forms contact. Another used for the Keyboard Restore button on the keyboard. A third used for the Prog Load button on the console. The rest of the debouncers are for the console entry switches and contacts in the keyboard. 

The rest is mainly for gating signals, implementing compound gates with multiple AND gates feeding a NOR, so that a particular SBR bit is fed from the console entry switch if doing a read of Area 7, otherwise it is fed from the keyboard contact if doing a read of Area 1. There is one large OR circuit so that if any of the keyboard contacts are active, the output is logic high which is what triggers the interrupt request after pushing a key. 

My issue was with bit 8, most likely the debouncer (what IBM calls an integrator) or the gate it feeds. Because the symptoms changed when the cards were swapped, it appears to be card specific and thus a defect. 

There is another possibility, however. If the gating signal that routes the keyboard contacts onto the SBR bus has the bounce shape, it would produce the same effect. The card receives three signals, +XIO Read, +Area 7 and +Area 1 which when combined to gate either the console entry switches or the keyboard contacts to the SBR when performing a read. If these are not correct it might cause that bounce-like signal. 

A maze of signals exist for gating the bus onto the SBR as well as signaling that we have a read of the keyboard. I expect to spend some hours checking all of these until I find and track down the source of the bounce. 

Testbench ready

FOUND SUSPICIOUS WIRE FRAGMENT ON B-B1 BACKPLANE

I did find a bit of wire sticking out from a pin which might have been a wire that should have continued to another location. At some future point I might be chasing a problem and the solution ends up as a wire wrap from this point, something that may have been done by past repairers. 

Bit of wire sticking diagonally left and downward from a pin