Repaired the Carry/Overflow lamp PCB and tested its operation with the LED replacement 'bulbs'

ANOTHER LOOSE SOLDER JOINT FOUND AND CORRECTED

The Lamp Test connection for one of the SCRs was also unsoldered. It is now properly affixed. Using the bench power supplies and switches, I was able to verify that the bulbs light with the logic signals as well as under Lamp Test.

WORKING ON IMPROVING LOOSE CONNECTION OF NYLON HOLDER TO PINS

The pins don't fit very securely into the bronze cylinders in the nylon holders, thus the bulbs can easily work themselves off the ends of the SCR pin, such as during movement of the machine from one location to another. 

I am going to work on ways to improve the grip of these, before I install too many more lamps of either incandescent or the new LED type. 

NEED TO RESOLDER THE PCB TO THE WIRING OF THE PANEL

The PCB with the Carry and Overflow lamps was unsoldered as it has direct wiring of Ground, 7.25VAC and Lamp Test signals. Now that it is fixed, I have to reattach a pair of wires to each of the three solder terminals to reactivate this set of lights. The logic signals plug onto a pin on the rear of the SCR, thus no soldering needed for those connections.

WORKING ON CONVERTING THE STORAGE BUFFER PCB TO USE THE LED BULBS

I unsoldered the PCB that holds the 16 lamps for the IBM 1130 B register, also called Storage Buffer Register (SBR) on the front panel or Memory Buffer Register. I will convert nylon housings to hold LEDs with the 470 ohm resistor, then install these on the end of the 16 SCRs.

Once they are securely in place, the board can be reinserted into the 1130 display panel and the Ground, AC and Lamp Test wires soldered onto the PCB terminals. If I am satisfied with the appearance of these, 

Working on light display panel of 1130, developing non-incandescent replacement bulb, discovering bad workmanship

IBM 1130 DISPLAY PANEL HAS DARK LAMP POSITIONS AND BULBS ARE FAILING

The display panel of the 1130 uses incandescent bulbs with wire leads, placed in a nylon holder and plugged onto a board with an SCR driven by the logic signal associated with the lamp. There are no new manufacturers of these bulbs and new-old stock is severely limited. 

The challenge is that the wires corrode where they exit the glass envelope, so many of these bulbs fail because the wire breaks off, rather than through a burned out filament. Handling the boards that hold eight to sixteen bulbs in order to change one bulb can result in broken wires on bulbs that previously were working. 

I had to loan quite a few of my own bulbs to get the VCF 1130 panel usable, but there are still dead positions and each time I address this, more of the original bulbs snap their wires off. I decided to build a replacement that I can put in the nylon holder instead of the almost unavailable incandescent bulbs.

REPLACEMENT BULB PLAN

I decided to use a yellow LED, soldering on a 470 ohm resistor to limit the current, placed into the nylon holders. When I tested it, it appeared to glow satisfactorily and should look fine illuminating the display panel legends. 

I tried to install them on the bottom left board (from the rear of the display panel) which has only two lamps, for Carry and Overflow status. The Overflow lamp has never illuminated but Carry was working. When I looked closely at the board, I saw two problems. First, the Overflow SCR had the ground lead broken off near the plastic body, so it would not work. Second, the Carry SCR had a lead that was never soldered by the IBM factory. Instead, it was just bent into contact with the PCB trace. 

BAD WORKMANSHIP FROM THE FACTORY

You can see in the picture that a lead from the SCR is not actually soldered in place, it is just folded over the trace and solder only coated below it. I repaired it after this picture was taken. 

Parity light working correctly now

REMOVED CARDS ON BOTH SIDES AND CHECKED FOR SHORTS

One possibility for the problem is a partial short of the signal trace between the card on B-B1 J3 and the one on A-C1 D5. These are 3817 and 3819 cards, respectively. With the cards out, the path was a complete open circuit and no adjacent pins or power rails had a resistive path. 

ADDED IN THE DRIVER CARD AND OUTPUT WAS 2.9V AS EXPECTED

With the 3817 card back in the machine, I powered up and saw that the signal path was at 2.9V with no parity error and low when an error was encountered. This cleared the 3817 card of involvement. 

ADDED A DIFFERENT LAMP DRIVER CARD, VOLTAGE NOW .0.9V BUT LAMP 

There were a couple of extra 3819 cards in the machine because it had a paper tape punch configured into the system with its attendant logic cards placed in B gate compartment B1. I took one and inserted it in A--C1 D5, where the voltage with no parity error remained at 0.9V but the lamp was completely dark. A real parity error was forced and the lamp lit up fine. 

FIRST PASS DEBUGGING BAD 3819 CARD BUT NOTHING OBVIOUS

The 3819 card is a 300ma driver, using a transistor in an SLT module as the first stage and a discrete transistor on the card to support the full 300ma current flow. It has eight identical such circuits but we are concerned with one of them which is connected to the Parity lamp. 

I couldn't find any signs of difficulty on the circuit in question. All its characteristics were identical to the other, correctly working circuits. Apparently the discrete transistor is partially conducting, causing the dim lamp. I would need to set up the circuit on a testbed and probe the various voltages and currents in order to figure out why this is happening. 

STICKING WITH EXTRA 3819 CARD SINCE WE DON"T NEED THE ORIGINAL

Because we have a couple of spare 3819 cards, due to peripherals which the museum does not have, I simply left the spare card in place so that the issue is resolved.

Repaired 3817 card that accomplishes parity checks; still have dim light

OUTPUT LEVEL INVALID ON THE 3817 CARD AT 0.9V

I pulled the 3817 card that implements the parity checking to see why the output wasn't up near 3V. After some reverse engineering I could see that the card uses 361435 SLT modules (AC multitrigger) for its three flipflops, one of which is the Parity Error state.  

By comparing the readings against the two working flipflops (setting the two parity check bits during a write to memory), I spotted an anomaly with transistor T3 of the module, which if it were partially conducting would produce the results I saw. I looked through all of my spare card stock but none had a 435 module I could swap for the suspected bad one on this card.

Fortunately, the machine was configured to support a paper tape punch, but does not have that peripheral. I could therefore grab the SLT cards for the feature and make use of any 435 modules on one of them. I yanked all the tape punch cards out of the machine (from gate A compartment B1) and indeed there are quite a few 435 modules on those cards. 

Bottom of the SLT module

Removed from donor card

Module replaced on card

I swapped over a module from one of the cards and plugged my 3817 back into the 1130. It still generates correct parity and detects parity errors, so the fix didn't make things worse. However, we still have the 0.9V output when it should be pulled up to 3V. 

I plan on pulling the 3817 card from B-B1 and the 3819 (lamp driver) card from A-C1, then measuring the signal path to look for something pulling 3V down to 0.9, causing the error. 

Tracing down the annoying dimly lit Parity Check lamp anomaly

PARITY LAMP DOES NOT BEHAVE AS THE OTHER STATUS LIGHTS DO

The status lamps on the 1130 should be completely off or brightly illuminated, depending on the condition. For example, the File Ready lamp will light when a disk cartridge is spinning and the heads are loaded, if the disk is not ready, it is off. The Forms Check lamp lights when the paper is not inserted in the Selectric based console typewriter, but goes out totally when the printer is ready for operation.

With the Parity lamp, however, there is a dim glow at all times, except when an actual Parity Error has occurred and caused the lamp to achieve full brightness. This is incorrect behavior and annoying to me. It began when the 3819 SLT card that drives the lamps took a catastrophic failure as a tantalum capacitor shorted the +48V to ground. 

The card is repaired and all traces damaged by the power event have been repaired or jumpered around. Somehow this abnormal behavior remains and I am on the hunt to find and correct the cause. 

When a Parity Check occurs, a flipflop in the machine records that status. When the flipflop is in its idle condition, the notQ output should be at 3V. Only when the flipflop sets will that output drop to nearly 0V and cause the 3819 card to light the Parity lamp. 

When I looked at the input to the 3819, I saw 0.89V, which is not a valid logic level. The card is driving the lamp weakly because of this, causing the dim glow. Since the flipflop notQ output is nearly 3V, the input to the 3819 should be close to that. 

This is not a very involved set of connections. The notQ output is in gate B, compartment A1, at card slot J3 pin D04. A trace from pin D04 routes the signal to card slot A7, pin D02. Instead of an SLT card, that slot has a cable plugged in. 

The cable carries the signal over to gate A, compartment C1, where it is plugged into card slot N6. Pin D02 of slot N6 carries the signal to card slot D5, pin D09, which is the input on the 3819 card that drives the Parity lamp. The only other connection in that link is a 0.22uf capacitor from slot N6 pin D02 (our signal) with the other end plugged into ground at another card slot of the SLT board. 

I isolated the cables and compartments to look for the cause. There are no shorts in the cable and the signal has continuity all the way from B-B1 J3 D04 to A-C1 D5 D09. There is no high resistance that might lower the 3V output of the flipflop to the observed 0.89V. 

Cables unplugged

There are not many candidates for the cause of this behavior. The flipflop output could be falsely low. The signal path could have a hidden short to some other signal that is often at ground level, but does not show up as a static short to ground when the machine is powered off. The 3819 card could have a remaining fault. 

I have already replaced the capacitor. The 3819 card has been swapped with no effect on the behavior. The flipflop notQ output appears to be validly high. That doesn't leave many remaining candidates for the failure root cause. 

 I have checked for static shorts to ground, but not dynamic ones that might be triggered by an erroneously connected trace pulling to ground when the machine is operational. There may be a completely unsuspected issue X that is behind this. In any case, I will keep after this until I find and eradicate the problem. 

Slightly frustrated that I can't imagine a fault in core memory that fits the observed symptoms

EARLIER PARITY ERROR HAD A CLEAR PATTERN AND CAUSE

When I first worked on the machine to diagnose its parity errors, I found that anytime the address bit 9 had a value of 1, the result from memory was a full word of zeroes with both parity bits incorrectly also at 0. This is what you see when core was not actually read. The Y axis lines through the core are selected by bits 9 to 15, with bits 9, 10 and 11 selecting one of eight groups of Y axis lines; bits 12 to 15 select which of the 16 wires in each of those groups is to be activated.

I checked the card responsible for selecting the four groups of Y where bit 9 was a '1' value, and found that it was not properly inserted into the card socket. Once I pushed it into place, the parity error went away.

NEW ERROR IS AN ENIGMA

Errors of this type, where they occur at regular address ranges, point at specific cards, wires, diodes and other components that logically could cause the failure. The new error, however, both fits and does not fit that profile.

Now, when we are accessing the upper 4K of the 8K core memory, we get parity errors at certain address ranges. The X axis lines through core are selected by bits 3, 4 and 5 accessing one of eight groups of X wires, with bits 6, 7 and 8 picking which of the eight wires in a group is actually used. 

Thus, if the flaw was in the cards, diodes or wires where bit 3 is a '1', it would make the machine fall over at many addresses beginning with 0001 0000 0000 0000 but that is not what happens. In addition to bit 3 being on, bit 9 is (again) a '1' when the errors occur. 

Bit 9 affects the Y selection for all addresses, both in the upper 4K and the lower 4K, so a flaw in that would cause parity errors in the lower 4K. Bit 3 is part of the X selection and thus should have no interaction at all with Y address components such as the ones for bit 9 = '1'. 

Finally, when a parity error is signaled, I see valid bit patterns in the data word and parity bits, such that I don't see anything that is a true parity error. How a flaw in detecting parity would be specific to certain range of addresses is a mystery to me. 

LOOKING FOR AN EXPLANATION FOR THE FAILURE THAT MAKES SENSE TO ME

I really want to understand what type of fault would give the symptoms I am experiencing. I prefer to understand why instead of just finding and changing something by blind luck. I will keep at this. 

Completed documentation for 3467 SLT card - drives read and write coincident current lines

These are the pages that are similar to what IBM produces - based on all the SLT cards for which I do have access to the documentation. I reverse engineered this card to build the appropriate documents which would help in future core memory restoration efforts.