Rescue 1130: 2014 Pickup of an IBM 1130 System and More: Memory problems continue, some progress on other areas

DISPLAY PANEL LAMPS

I spent about four hours carefully removing all the original bulbs for the six registers, inserting new bulb in the holders and replacing them on the boards. I finally had enough bulbs to rehabilitate all 94 lighted positions that show the contents of the 6 major machine registers. Maximum memory addressing is 32K words thus the IAR and SAR registers don't implement a bit 0. The rest of the registers are 16 bits wide.

Pile of bad bulbs removed from the panel display

I had just three additional bulbs, which I wanted to use for the three indicators that were burned out the last time I did a lamp test. No guarantee I won't disturb and break others while attempting to make a gentle replacement., thus I skipped this until I am ready to replace all 46 bulbs in that side all at once.

I closed things up, brought up the system and did a lamp test. Drat! 7 of the 94 bulbs are not working. IAR bit 13, SAR bit 10, SBR bits 2 & 14, ACC bit 5 and EXT bits 2 & 5 are out. These are probably cases where the contacts worked loose with all the nudging I have to do in order to get the bulbs to fit into place, but they could be bulbs that were bad when I installed them. After the first fifty, I wasn't obsessively continuity testing these every few minutes.

The right side, which I didn't touch, still has I2, X7, and C out, but now the disease has spread to include outage on P2 and W. Have I mentioned that I hate the light panel implementation? It is very hard to work on it, offering lots of chances to disturb bulbs. At least for the left side, the six register, the bulbs themselves don't have brittle wire leads making things worse, but the 46 on the right side are still the original bulbs with their fragile leads.

Once I am ready to replace the right side 46, I will go in again and fiddle with the left side bulbs that are out, go back to obsessive compulsive levels of checking, and hopefully get the entire panel working properly.

CONSOLE PRINTER (TYPEWRITER) RESTORATION

I installed the cycle clutch latch except for the spring which hooked to it, which was snapped in half when I removed the latch. I removed the other half from its mount inside the mechanism and placed them together to size a replacement spring. I need one about the same size and with similar 'springiness' to assert the same level of pull on the latch.

Halves of the broken cycle clutch latch spring

Stacked in place to measure replacement candidates

I found a reasonably close match to the spring from my stock of new and used IBM typewriter parts, but installation is challenging. The connection looks simple but it is deep inside the machine. Impossible to get fingers in there, even hard to get longer tools to reach the spot. I endured about half an hour of failed attempt after failed attempt, then put it aside for another day.

Parts catalog page covering the cycle clutch latch - spring is #18 on the diagram

I came across another of my specialized tools for working on Selectric mechanisms - this is a Hooverometer which is used to set the height of certain adjustable parts including the cycle clutch latch. Earlier I showed a picture of a hand crank tool to rotate the mechanism manually to specific points in the print cycle.

Hooverometer for adjusting some Selectric parts

CORE MEMORY DIAGNOSIS AND REPAIR

Since there were jumpers on the 1&5 inhibit sense cards for both memories, which appeared redundant to connections that already exist on the cards, I put them back and did a check just to rule out this as a solution. If the three red jumpers were there to deal with defects that a CE had diagnosed, perhaps it would restore normal operation if they are put back on.

The one area that was malfunctioning originally was the place where I had a dangling jumper - highly suspicious. An IBM employee would have replaced the card rather than use a nonstandard set of jumpers, but this could have been a fix applied when the machine was off maintenance from IBM and cared for by someone else.

The outcome of this after a bit of testing was no change. I did some more careful testing of the memories and find that I have growing issues with bits that aren't inhibited when they should be stored as a zero. Memory is divided into two compartments each with a core stack. Each compartment and its stack are logically divided into two 4K halves. The results of testing in the four zones of memory were:

The lower 4K of the first 8K compartment (B1) has bits 1 and 5 always reading as on
The upper 4K of the first 8K compartment has bits 1 and 5 always reading off.
The lower 4K of the upper 8K compartment (A1) has bits 1, 5 and 11 always on
The upper 4K of the upper 8K compartment has bits 1, 2 and 5 always on

The issue in the first 4K of memory occurred after I did some swapping and monitoring of compartment A1, although the failures here are happening in compartment B1. The third and fourth 4K sections of memory, both in the A1 compartment, continued to show 1 & 5 but added another bit. Not the same bit number for each half, but another bit.

Also, I see that failures didn't move when I swapped cards - A3 x A4 and B3 x B4 - and that the new failing bits are not any of those sockets. On a card basis, the errors happen in A4 and A5 for the top 4K and B4 and M4 for the lower 4K in compartment A1. For the first 4K, the error happens in card B4 of compartment B1. No way this many cards are failing! Something common is causing this problem and I have to find it.

Time to check out the cables and how the connectors are seated. I have no good clue yet that points at a specific defective part with high confidence, but if it is a loose connector for the inhibit signals to write core as a 0, then checking the seating would be good. However, after checking and reseating the cables, no change in behavior.

Connectors in B gate C1, going to D gate B1

Verifying that connectors are properly seated

I checked the quality of the power leads and connections all the way to the core gates, and basically anything else I could think of. So far, memory is unusable in any section due to the sense/inhibit problem.

1132 PRINTER TESTING ON HOLD UNTIL MEMORY WORKS

I went over my program and would have run it with some additional verification code to determine whether the printer is printing correctly or not. However, with memory unusable, this must wait. Same for the 1442 reader/punch.

GOOD NEWS FOR ANOTHER RESTORED 1130

The 1130 running at The National Museum of Computing in Milton Keynes, UK did not come with its ALDs - the museum restored it using ALDs from another 1130. Thus, they were not sure of the exact configuration inside. Peter Vaughan of TNMoC has discovered that the machine has the SAC feature just as mine does. That is excellent because he can create any kind of IO device and therefore can electronically move data in and out without punching it to cards first.

PICTURES OF CARDS IN EACH COMPARTMENT

I took pictures of the cards installed in each compartment, which is a good reference to check instead of running out to the real machine and opening covers. I did this after discussing the SAC with Peter Vaughan, since he had the foresight to have such pictures and could use them to check whether cards used for the SAC were installed in his gates. The images of my machine's card compartments are shown here for those who are curious.

A gate: