I did think the mechanism for the spacebar, rotating bars and linkages, was a bit sluggish when it was restored by the solenoid. That is, the keystem for the space key would latch back up but the linkage didn't move the spacebar all the way up immediately.
Some Nye oil on the moving parts and a few rounds of activation gave me a more satisfying and crisp restoration of the spacebar. I put the keyboard back in place so it was ready to use.
WATCHED RAW KEYBOARD INPUT TO SEE ANY INTERACTION WITH KEY SEQUENCE
I put the scope on the debouncers for several signals from the keyboard, including the two that are involved in the alternating parity check symptom. This way I would see the raw behavior and whether there was any residual signal or overlap.
I saw absolutely no variations between the sequences that got the parity check and those that worked properly. The prior key's signal was completely off, at -3V, when the new keypress began. The new key's signal climbed suitably to the +4V level as it should, with no difference based on any prior keypresses.
HUNTING THE MYSTERIOUS ERROR CAUSING THE PHANTOM BUT PREDICTABLE ERROR
The logic in the parity section of the machine looks at the SBR and evaluates the number of bits that are set to 1. It does this for each half of the word, bits 0-7 and bits 8-15. It produces a signal called Even Parity for each halfword which is on when there is an even number of 1 bits. The design of the 1130 requires an odd number, so this signal Even Parity is used to set or reset the check bit that will be written as bit 16 or 17 to provide proper parity.
When the 1130 is gating an input-output word into the SBR, as when we are reading the keyboard, it activates a signal to cause the SBR to latch based on the IO bus, then activates a signal to cause the parity logic to set or reset the check bits. At the end of the clock step when this happens, both check bits are correctly set and the parity is indeed odd for both halves.
However, in the very next clock step, the Even Parity signal for the 8-15 halfword goes on again. This is spurious as the SBR bits appear to remain steadily in the correct configuration and the check bits are correct, so the logic should not indicate Even Parity. One clock step later, the machine will set the Parity Check Stop latch if Even Parity is on for either halfword.
One scope image comparing the first and second halfwords showed the check bit getting set correctly in both, with the Even Parity signals going off, but immediately returning on the bad key sequences. This leads directly to the Parity Check latch being set. I will be probing and capturing signals to figure out what is bouncing the Even Parity line back on.
BENCH TESTING THE PARITY CARD
I took the parity card out and ran tests on the bench to verify that it does latch the check bits appropriately. The card seems to work as it should. I put it back in the machine and continued debugging.
IDENTIFIED FAILURE OF RESTORE KEY ON KEYBOARD, FOUND BAD CARD
I had noticed that the Keyboard Restore key would not activate the solenoids, although they were automatically activated every time the keyboard was selected by an XIO Control instruction. I initially thought it might be a contact oxidation issue, since that key is a microswitch and not connected to the mechanical bits of the keyboard.
Checking the debouncer for the key, however, showed that the switch was working well. The signal would swing from -3V when idle to +4V when pressed, exactly as it should. There was only one gate between the debouncer and the amplifier that fires the restore solenoids. A voltmeter showed that it was not reacting at all to the input swing.
It was a 509 card and there are several of these in the peripheral controller logic for other input output devices, so I swapped in another and the key began to work properly. I moved the card to the workbench where I can track down the failing parts and repair the card.
IS THE SBR CHANGING ONE CYCLE LATER?
One hypothesis is that the SBR is set correctly by the pulse -I/O to B SP, which I do see occurring, but a later pulse grabs some other value and updates the SBR bit inappropriately. The logic of the SBR cards is that it can only be set by three control pulses or by a pulse from the sense amplifier of the memory during a memory read. There is the I/O to B SP (sample pulse), the I to B SP, and the A to B SP. The SBR is called the B register internally, if you were wondering about the names, while the IAR is the I register and the ACC is the A register.
I watched all of them and none were triggering the SBR to latch except for the correct one, I/O to B SP, issued at the correct time. I have to look elsewhere for the source of the issue tripping off the phantom parity error.
AHA MOMENT - HOW THE MACHINE CAN REMEMBER THE PRIOR KEYPRESS
Suddenly it occurred to me, there is a way that the prior keypress state can be retained and accessed just before we read the new one. I kept looking for flipflops or mechanical conditions in the keyboard. The answer was staring me in the face. How do you remember something? With memory.
Yes, the prior keypress was stored in a word in core the last time we did an XIO Read, on the prior keypress. Say that we pressed the F key. The word would have this binary pattern 1000 0000 1000 0000 and then when the G key is pressed the pattern is 1000 0000 0100 0000 which flips bits 8 and 9.
Executing an XIO Read will trigger a core memory cycle for the address from the Input Output Control Command (IOCC) used with the XIO. A core memory cycle first does a read, latching the result into the SBR, then it is either written back or a new value is written for an update.
Thus, when the XIO Read is executing, clock steps T0 to T3 culminate in the OLD value of the word being latched into the SBR, then in clock steps T4 and T5 we latch in the word from the keyboard and generate the check bits. In step T6 we test to see if there is Even Parity.
That is the memory mechanism behind why these errors are so deterministic when bits 8 and 9 swap between keypresses. The old value is stored in the SBR and then we change it with the new key value. That is the clue - the prior state of the SBR matters when latching in the new value.
How and why it matters I don't yet understand, but this resolves one of the big quandaries in this debugging - how the machine could remember the prior keypress. It remembered because we wrote it in the core memory word. Cue Homer Simpson uttering "doh".
No comments:
Post a Comment