Some good news about the 1130 core memory but not yet functional

CHECKED THE CONCERN ABOUT SHORTED SENSE WIRES ON CORE STACK

The maintenance manual lists some common failure modes for the core memory, such as shorted diodes, but there is one class of problems that can't be repaired in the field, requiring a replacement core memory stack. Obviously that would be a worst case scenario.

The reason I worried about this was due to seeing sense bit 7 come on for any address with the next to lowest address bit turned on - 2, 3, 6, 7,10, 11, 14 and 15 for example - which would be easily explained by a short between address bit 14 and sense bit 7. The process of verifying this involves pulling a jumper block off the backplane to isolate the core stack and then testing for circuit continuity between the sense wire and the address wires. 

The way that the core memory stack is connected to the 1130 is to mount it onto the backplane, with pins sticking through holes in the backplane to make wire connections to the core stack. Alongside those pins that fit through the backplane are pins on the backplane itself. The jumper block slides over all those pins and connects core plane pins to backplane pins. 

I pried the jumper block off which connects the sense wires for bit 7. There are six wires in total for bit 7. In order to reduce noise pickup for a more reliable sensing, there  is a separate wire through each 2K of cores. Thus, our 8K stack has four sense wires wound through each plane. Each pair of sense wires is tied together into a common ground, with two 2K wires sharing a common ground end. Thus the need for six pins - four sense wires and two common grounds. 

Three different cards send a current through the addressing wires when bit 14 is a 1. Bits 12, 13, 14 and 15 are decoded to produce one of 16 lines in a 4 to 16 demultiplexing operation. Half of the outputs have bit 14 as a 1. The upper and lower 4K halves of the core stack have their own 4 to 16 demultiplexing card. Thus I had to check each of the four sense wires and the common grounds against all those outputs that drive current through the addressing wire when bit 14 is a 1. 

I found infinite resistance between all six of the sense wire pins on the core stack and all the addressing outputs where bit 14 is a 1. Thus I no longer am worried that we have a short on the core stack, the one essentially unrepairable part. 

SCOPING THE READ SHOWS A FAILURE TO DRIVE THE X AXIS CURRENT

The core memory works by driving a carefully controlled current through one X and one Y axis wire - sending it in one direction to read and then in the other direction to write. I don't have a good current sensing scope loop, which is the ultimate way to check that each addressing line is producing the correct current. 

However, IBM indicated a test point on the current control card that manages the size of the current. It is one end of a 10 ohm resistor on the outside of the SLT card, easily reached by a scope probe. 

Test point is left side of the resistor on the bottom

I thus hooked one probe each to the X and the Y axis current control cards (at card lots B2 and M2). The point sits at -3V until the current is flowing. With the correct size of current, the voltage should jump up to -1V. I triggered the scope on the +Read Cycle signal, watching the Read Strobe and the two test points. 

X AXIS CURRENT NOT FLOWING DURING READ

I could see that the read operation produced a good strobe and a Y axis current, but nothing on the X axis. The write operation that immediately follows any read does show both X and Y activated. That explains the parity checks when any address is read at this point. No core is flipped during a read because we don't have the coincident current from X and Y combining to overcome the core hysteresis. It does correctly flip the core to the 1 state during the write cycle, unless the sense wire has an inhibit current to offset the effect of X and Y which leaves the core as a 0. 

It won't be hard to track down the reason why we are not completing a circuit on the X axis from the read driver to the read gate. Since this occurs on all addresses, which therefore use multiple distinct cars for the driver and gate logic, it must be something common that is blocking the read. When I get back to the shop I will hunt this down and correct it.