Traced back to problem in the keyboard! Meanwhile CPU seems flawless

SIGNAL ANOMALY SPOTTED

Testing the card involved setting up quite a few signals into the card in order to check each bit output. The area got very crowded with cables, many forcing signals to ground so that the circuits would work right. In no case could I see the debouncers causing the odd pattern that was characteristic of the error. 

After checking the cards on the testbench with no issues found, I began scoping various signals related to the bits causing the parity check. When I watched both bit 8 and bit 9 at the same time, I spotted the cause of the changing parity. 

Green trace is bit 8, purple trace is bit 9

When bit 9 is a logic high, the scope showed bit 8 blipping on for a short period then off, while bit 9 turned on right after 8 went low. This makes no sense in the context of reading the keyboard. 

TRIED ALL OTHER KEYS - CONSISTENT ISSUES WITH BIT 8 - BIT 9 TRANSITIONS

I began systematically hitting keys, noting when I saw a Parity Check falsely detected. When I typed a G after an F, I get the error (and the same going in the reverse direction). When I type a P after an O, or a W after a V, the error occurs. Several special characters such as * and % also triggered errors. 

If I type some other character and then a P, it works fine, but if I typed a character with bit 8 first and then type P, the Parity Check is thrown. This has to originate from the keyboard mechanism itself, which encodes characters using a complex circuit combining bails (contacts operated by certain keystems) with latch microswitches under specific keystems, along with the Numeric key. 

I took a quick look at the diagram before I pull the keyboard out of the machine for an in depth investigation. I noticed that bit 8 is unique in that it is fed through a pair of back to back diodes. If a diode isn't (e.g. a short) we might be charging up one of the debouncers one way and then draining it off as bit 9 turns on. 

Other possibilities include sludgy stale lubricant on one of the bails, which causes it to stick in one orientation for one of the paired keypresses and then flip to the other. What is confusing here is that the mechanical motion should be complete before the CPU takes the interrupt and issues the read to pick up the key code. Perhaps the tight loop I am using for this test is a worst case minimal delay before reading, which combines with a poor response of the moving parts due to sticky lubricants. 

EXERCISED CPU BY HAND FOR AN HOUR, TRYING MANY INSTRUCTION VARIANTS

I walked the CPU through instructions, including variations, with every single one performing properly. The 1130 has several addressing modes. An instruction can be short (one word) where the effective address is relative to its current location, or long (two words) with a full address in the second word. It can apply the contents of one of the three index registers to the effective address. Finally, it can treat the address as indirect, reading from that address to get a different address to finally use with the instruction.

For example, if an instruction is at address 0200 and is short format with the remaining bits (displacement) set to xx0F, then the effective address takes the Instruction Address Register (IAR) while the instruction is executing (0201) and adds the displacement to form the address 0210. 

If in addition, the instruction uses index register 2, then the contents of that are added to the effective address 0210 we just calculated. If IX2 has 0040 in it, then the effective address becomes 0250. 

Finally, if indirect addressing is specified for the instruction, then we pick up the contents of location 0250 - lets say it has 006A stored in it - so that the final effective address is 006A. For long format instructions, we skip adding a displacement to the IAR, instead just taking the second word as the effective address before we add index registers or apply indirect addressing.

All these variations worked perfectly. I tried the Load Doubleword instruction which fetches a pair of words from the effective address (and address+1), putting the contents in the ACC and EXT registers. If the effective address of a doubleword instruction is pointing to an odd address, then the CPU will instead just fetch the word at the effective address twice, putting the same value in both ACC and EXT. This worked correctly.

I tried all the AND, OR and EOR (exclusive OR) functions, which worked great. The effective address computation use the add/subtract circuits, so we know they are working properly as well.

Finally, I tried a simple Modify Index and Skip (MDX) to branch to the effective address, as well as a Branch and Store IAR (BSI) to store the address after the BSI in the effective address location and set the IAR to effective address + 1, beginning execution at that point. This worked properly short, long and indirect. 

The next time I work on the machine I will focus on all the conditions that are used for the conditional branching instructions, things like ACC is zero, ACC is negative, or Carry occurred). These are used with the Branch or Skip on Condition (BSC) instructions. 

The MDX instruction adjusts index registers or memory locations, either executing the next instruction or skipping over one instruction word - I need to test all the variations to be sure it works well. 

I have used the input output instruction XIO successfully for the keyboard testing, so it is working well, thus I will be left with some minor instructions to round out the test.