All but three lamps are lighting on the display; possibility that device controller logic is stepping on memory access

GATHERING SPARE SCRS FOR REPLACEMENTS

The 1130 has a row of eight bulbs on the display panel marked CE 1 to CE 8. These were intended to be temporarily wired to some logic cards to display certain conditions that the customer engineer believed might be an error condition or an important indicator while debugging. 

Row of removed SCRs and bulbs for the CE positions

Modern logic analyzers and other tools allow such logical conditions to be observed without having to wire up a light. Thus these are unneeded and are a source of spare SCRs that won't be missed. I carefully unsoldered all eight SCRs from the display panel and tested all of them. One of the SCRs was shorted so that the bulb was always lit, but seven of them were good spare parts. 

Seven good spare SCRs

INVESTIGATED EACH DARK LAMP POSITION AND CORRECTED

Since there are many possible reasons for a dark lamp, I had to check several ways to find the cause. After visually inspecting the PCB for bad solder joints, I tested the bulb on the workbench to eliminate that cause. I then unsoldered the SCRs and brought them to the testbench to check them out for proper function.

I did find one that was unwilling to light. The others were all working properly, which turned my suspicions back to the PCB solder connections. I soldered the SCRs back on the board and used some cut off wire leads from components as connections to ensure good connectivity from the SCR pin to the metal bus on the PCB.  This fixed almost all of them, suggesting that some solder joints will look intact but still fail to conduct properly. 

FINAL TALLY - THREE DARK PLUS ONE THAT IS ONLY DARK ON LAMP TEST

I have one bit on the Instruction Address Register (IAR) row that is not lighting. There are two status positions, ZR and AC, that are also dark. Another bit on the IAR will not light up with the Lamp Test but when the actual IAR bit is on, the lamp lights up. This suggests the bad joint is to the test pin on the SCR but it could be a failure inside the SCR. That last situation can be fixed by soldering a wire to recreate the lamp test path to that SCR. 

Almost every position lighting on Lamp Test

Because of the risk of joints cracking, incandescent bulb wire leads snapping, signal pins snapping and other issues that come from manipulation of the boards, I am going to call this good enough for now. I might do a quick continuity test on the SCR pins to ground and test, as I could resolve that by soldering a wire jumper without pulling the boards out 

PULLED ALL THE DEVICE CONTROLLER CARDS FOR 1132, 2501 AND 1442

When I would run a Storage Load operation to cycle through memory storing an all zero bit pattern set on the Console Entry Switches, I would see flickers of a few bits turning on, mostly bit 7. This corresponded to the condition that caused the Parity error stops. 

Once possibility is that something is jamming that bit on sporadically and based on the timing it could be the reason that sometimes an inhibit fails (turns off too soon) or similar race condition pops up. The device controllers in the machine are all able to put bits on the common bus, so they could be the offender. 

Looking at the connectors on the machine, we can see that it had device controllers for a 2501 card reader, a 1442 reader/punch, an 1132 printer and a paper tape punch. The machine does not have any of those peripherals attached right now, although it might have some back at the VCF museum that will be used later. 

PC8 is the signal connector for a 2501 reader, PC7 is for the 1132 printer and PC6 is for the 1442 reader/punch. The smaller connectors PC1, PC2 and PC4 are the power connectors for those three devices. In addition, there is an SMS paddle card connector inside the machine where a 1055 Paper Tape Punch would be connected. 

I looked up all the cards involved in those device controllers and pulled them from the machine. I am always add them back in and test them later in anticipation of their eventual use, but debugging will be simpler with these out of the mix right now 

NEED TO DISABLE SOME LOGIC NOW THAT DEVICES NOT CONFIGURED

When I first powered up after pulled all the cards that constitute the device controllers above, the machine immediately showed requests for Interrupt Levels 0 and 1 as well as incorrect memory output. IBM documents jumpers that should be installed to disable various signals based on the devices configured for the machine. 

Specifically, when there is no card reader and no 1132 printer, interrupt level 0 and 1 are disabled by jumpers. I added the jumpers and the issue with interrupts went away. 

I still have some funny issues with data going into and out of the B register (SBR) which is undoubtedly drive by some enabling gates associated with the removed device controllers. I have to work through the jumpers and diagnose the condition, but I should be able to get back to a workable base where I can continue trouble shooting the parity errors (or find they have disappeared along with the device controllers).