Using downtime to create SLT card schematics that I did not already have

HIT BY STRONG FLU TYPE ILLNESS, NO ENERGY TO GET TO THE SHOP

All this week I had relatives visiting and other activities, so I was quite looking forward to shop time starting yesterday. However, only a couple of hours after the last visitors left, I began sneezing, feeling muscle aches and fatigue. Not certain how rapidly I will recover, but for the meanwhile I can't do much except rest in my home.

MISSING CARD SCHEMATICS FOR CORE MEMORY UNITS

I have found several sources for SLT card schematics that cover a fair percentage of the cards in the IBM 1130, but certainly not all. When a problem exists in one of the cards that is not documented, it takes a bit of time to figure out what is going on and where the failure sits.  Fortunately, I do have documentation for the SLT modules that fit on the cards and can work out most of the other components, so the main challenge is figuring out where the traces run on the card and then what the schematic looks like.

I had applied this process to reverse engineer the 3132 card (ten inverters used to generate non-inverted memory address bits from the inverted ones that arrive into the core memory compartment). Knowing that the SLT module on the card is a 479 (isolating inverter, 30ns family) that card was dead simple to work out. 

I decided to produce documents similar to how IBM would (probably did) wrote them, using the other schematic files I have as a template. Each card is documented with three drawings - the logic gate view with input and output pins that you would see on an ALD page, an electrical schematic showing every component and connection, finally a physical layout of the card showing where SLT modules and discrete components are placed. 

Here are samples of the three types of pages:

To complete the 3132, I do need to get to the shop so that I can trace the input and output pins to know to which SLT module and pin they connect, then I can finish my documentation for the card.

SECOND CARD TO DOCUMENT IS THE 3467 READ/WRITE DRIVER AND GATE LOGIC

Physically the 3467 consists of pairs of SLT modules - types 4xx and 4xx - plus eight discrete transistors. The ALD lists the card as having circuit types T03AC(AND), T06AE(probably Core Driver) and T32AH(Core Gate), which can comprise both SLT modules and discrete parts. The schematic is loosely represented in the core memory ALDs thus I only need to work from the SLT module circuit and parts I see on the card, then beep out the connections to finish up that one. 

MISSING SEVEN OF EIGHT CARD TYPES IN THE CORE COMPARTMENT

I happen to have documentation for the 3466 card and will have worked out 3212 and 3467 as described above. That still leaves me with cards that have no documentation currently: 

525 logic and address bit 3,4,5 inverters

3475 inhibit and sense bits

3484 voltage regulator

3491 V-ref and sense control

3773 current control

4683 clock strobe

Solved first problem but new persistent issue in memory

3132 CARD TESTED FINE, MOVED ON TO READ DRIVER/GATE CARDS

I put the card through its paces on the bench and found it was working perfectly. All traces had continuity on the board (backplane) as well. It was time to check the card that would drive lines where address bit 9 was a 1. 

SYMPTOMS AND DRIVER CARD LOGIC

The driver card contains drivers for all the groups where bit 9 is 1, meaning four groups representing the combinations of address bits 10 and 11. When I tested on the machine doing displays of various addresses, I found that all four groups were giving parity errors. The card has four circuits, thus the fault must affect all of them on the card. 

I planned to swap the cards and see if the issue moved to some other set of addresses, confirming it was a card problem. However, as I tried to remove the suspect 3467 card at slot H3, I found that it was loose. It had not been firmly inserted into the board. 

RESEATED CARD H3 AND THE ORIGINAL PROBLEM WENT AWAY

When I powered up again, the original addresses with bit 9 set to 1 were working fine. I was hopeful that this had been the only memory issue and I could move on to peripheral device controller logic debugging.

RAN STORAGE SCAN AND HIT NEW PARITY STOP PROBLEM

Using the Storage Display switch, which cycles through all memory addresses reading the contents, I found the machine stopped in the upper 4K of memory (address bit 3 set to 1) and the groups where address bit 9 is a 1. 

This failure is very consistent. The machine has a procedure to identify the failed driver cards, where you first set all bits to 1 with the Storage Load function, then set the machine to display and use the Storage Display function. It will stop with a parity error with an address whose bits highlight the bad driver card(s). 

In this case, it showed the card for the case where address bit 3 is 1 but also the card for the case where address bit 9 is a 1. The driver cards cover both halves of memory, upper and lower 4K, so if the card works properly for the first 4K with bit 9 = 1 then it shouldn't fail just because we are in the upper half. 

If the card that controls when address bit 3 is a 1 (upper 4K) is the issue it should cause the parity errors immediately with all the lower address bits still 0, but it waits until bit 9 is also 1. Bit 3 is an X axis selection and bit 9 is a Y axis selection. 

Bit three is combined with bits 4 and 5 to pick one group of 8 lines in the X axis. On the other side of the core plane, bits 6, 7 and 8 are used to select which of the 8 lines in the group are active. 

When I get back I will methodically test all combinations of 3, 4, 5 to see which of them cause problems when bit 9 is a 1. The test functions all stop on the first failure (3=1, 4=0 and 5=0) but it may or may not fail with the other combinations of 4 and 5. Similarly I would test to see which combinations of 9, 10 and 11 cause issues when bit 3 =1. 

For this to be a broken wire in core, the symptoms should be limited to a single wire, thus only one combination of 3, 4, 5, 6, 7 and 8 would cause the issue. If a driver card, then it could be groups of eight not a single wire. 

ADDRESSING IN THE CORE MEMORY

Core memory is addressed by driving a current down one X and one Y wire simultaneously, so that the current at the intersection is sufficient to flip the core but the other cores that are only on the X or Y line don't get enough energy to change state. 

Writing involves sending the current in one direction, while reading passes the current in the opposite direction to flip the core in the other direction. If the core was already in that direction (had a 0 value) then nothing much happens. However, if the core was in magnetized as a 1 bit, then flipping it will produce a pulse from the change that is detected by a sense wire that is threaded through all the cores on that core plane. Finally, when the write current is sent, if the desired state of the core is to be a 0, then a counter current is passed through the sense wire to lower the energy and prevent the core being set. 

The X axis has 64 wires and the Y address has 128, thus there are 8,192 intersections with a core that can be uniquely addressed. During a read, a driver sends current down a group of lines and a gate connects only one of those lines on the other side. Thus, eight drivers are used and eight or sixteen gates depending on the axis. 

The X axis read driver is wired through a block of diodes to sink current from all eight of the wires. Each of the circuits on the 3467 card are attached to a different group of eight lines, with one of those card circuits activated by its combination of address bits 3, 4 and 5. The same card will drive reads (sink current) or gate on writes (provide the 8.3V feed for the current), depending on the two control lines that are managed by the logic that manages the process of reading or writing. 

Every group of eight wires that are driven by the upper picture logic is also connected on the other side of the core plane by another 3467 card. When reading, the bottom card feeds 8.3V only to the one out of eight lines that are selected by bits 6, 7, and 8. Each group of eight has the same lines tied together - the first line of each group of eight is tied to the all the other first lines and hooked to the bottom circuit. 

Thus when selecting an X wire, we feed 8.3V through eight of the wires, one per group, going up from the bottom of the core plane to the top card, which sinks current from only one of the groups. The 8.3V on all the first lines of the other group will not flow anywhere because a circuit is not completed, but the first line in the selected group has a circuit to flow through the current sink in the top card. 

Similarly, the Y axis has a card that sinks current from one group of sixteen wires, through a diode array, when doing a read. During a write, it sources 8.3V through the same group of sixteen wires. All this is based on the address bits 9, 10 and 11 to pick which of eight such circuits on the card are activated. 

This is different from X because we have to select 128 unique wires in this direction. On the other side, two 3467 cards are used to select which of the sixteen wires in the group are active.

Each circuit on a 3467 card is assigned to one combination of bits 12, 13, 14 and 15. It will source 8.3V to its assigned wire in each group of 16. For example, bits 12=0, 13=0, 14=0 and 15=0 will source voltage to the first wire of each group of sixteen, with all first wires of the groups tied together. 

We can have errors in reading or writing when one or more of the driver or gate circuits on a 3467 card is not working properly, either selecting more than one wire at a time or not selecting a wire all all. The original error occurred when the 3467 in slot H3 was not fully inserted into the board, thus it was not sinking read current for four groups of sixteen Y axis wires. 

PUZZLES TO SOLVE

Why would bit 9 addressing cause problems in the upper 4K but not the lower 4K, since it is a common driver/gate card? Why would the failure involve BOTH bit 3=1 and bit 9=1 but not occur on either separately? What is common? The bits showing with the parity error do not seem to indicate a valid parity error, which is even more puzzling. One should see each half of the word plus its associated parity bit have an odd number of bits in total. 

Will be testing the 3132 SLT card as I troubleshoot the memory parity error issue

MEMORY BEHAVES AS IF IT IS NOT BEING DRIVEN FOR THE ADDRESS BIT 9

In the 1130, one parity bit covers eight of the 16 bits in a word and a second bit covers the remainder. The scheme for error checking is that there must be an odd number of 1 bits in each half of the word - if the data value has an even number, then the parity bit is set to 1 so that the 9 bits always have odd parity. 

The parity error we receive for any memory address where bit 9 is 1 shows up as reading a word of all zeroes plus both parity bits are read as zero.  Violating the odd parity rule, we lock up with the error. This is the kind of output one would get if the memory was not actually read. If the cores aren't flipped then the sense lines never detect the pulse that occurs when a core had a 1 stored in it. All cores appear to have had 0 in them, but in reality it is likely that we simply didn't flip the cores.

THINKING ABOUT POTENTIAL CAUSES FOR THIS FAILURE

All other addresses work perfectly so we know that most of the memory circuitry has to be okay. We are just not driving the current through the wires the are activated when bit 9 is a 1. There are four groups of wires that could be driven with bit 9 is on, the individual group actually used is based on bits 10 and 11. Then bits 12 to 15 select which of sixteen wires in that group connect to form the single wire through the core stack in one axis. Bits 3 to 8 select the other axis such that one and only one core is at the intersection of those wires. Multiply this by 18 core planes, one per bit of data or parity. 

The selection logic has an AND gate which is wired to bits 9, 10 and 11, either the inverted or true version of them in order to activate the assigned group of wires. Thus when bit 9 is a 1, there are four AND gates with true bit 9, the other inputs being combinations of true and inverted bits 10 and 11 to cover all four cases. 

One of four AND gates driving read drivers for bits 9-11

The input address comes to the memory in inverted form, therefore it only receives -Address Register Bit 9 and the true form has to be generated using an inverter (NOT gate). 

Inverter on card F2 for address register bit 9

Ten of the address bits are inverted on one card - F2 - which is a type 3132 card. It is a very simple card indeed, using five SLT modules. The 479 module has dual inverters, thus the five modules provide for ten signals to be inverted. 

The module used on the 3132 card

This module only requires +3V, not using the -3V bias and +6V pullup rails. The card still implements three tantalum capacitors to filter the rails, for some reason. Each of the ten inverted address bits 6 to 15 are routed to one of the inverters and the output goes directly to an output pin. The pins 8 and 9 are connected on the card, as are pins 2 and 3, thus these inverters use the pullup to +3V for their high output state and sink current to ground (pins 4 and 10) to output a low state. 

SUPER SIMPLE BENCH TESTING SETUP

My bench setup thus requires only one +3V power supply and I can test each bit by switching the input pin between 0 and 3V, verifying that the output pin moves between 3V and 0 based on that input. If the inverter for bit 9 is not working properly, I can swap in a 479 module from one of my spare SLT cards and repair its operation. 

Put instructions through their paces and the 1130 and CPU appears very health; one annoyance returns

HAND ENTERING ALL THE INSTRUCTIONS TO SEE IF THEY WORK CORRECTLY

I toggled in instructions and test data, one at a time, then executed the instruction to validate the expected behavior. 

The load and store instructions, both single word which pertain only to the Accumulator (ACC) register and the doubleword versions which deal with both ACC and the Accumulator Extension (EXT), did exactly what they should. The same was true for the Load Index/Store Index and Load Status/Store Status instructions. 

Shift instructions come with subtypes. When shifting left, one can shift just the ACC or shift the combined ACC and EXT. In the latter case, bits shifting left out of the high order bit position of EXT are inserted as the new lower order bit of the ACC, thus this is treated as a single 32 bit data item. 

There is a variant that is Shift Left and Count, where it shifts bits leftward one at a time until the high order bit position of the ACC is a 1. While it is doing the shift it is decrementing a count field, typically in an index register, so that the instruction will find the position of the first non-zero bit in the ACC. It can operate on ACC alone or on ACC + EXT. 

When shifting right, one can shift only the ACC or shift both ACC and EXT as a combined 32 bit value. As bits are shifted to the right, 0 bits are injected into the high order position of ACC. Finally, there is a version called rotate right which shifts both ACC and EXT, taking the low order bit of EXT and putting it into the vacated high order bit of ACC. This moves a 32 bit value circularly, with no loss of bits. 

Three broad version of branching exist. The Branch and Store IAR (BSI) is used to call subroutines, because it stores the next sequential address after itself in the first word of the target location and then starts executing at the second word of the target location. The subroutine can branch indirectly through that first word to return to its caller. 

The Branch or Skip on Condition instruction will change the next instruction to be executed based on selected conditions. For example, the short version of BSC will fall through if the conditions are not matched but if any of the selected conditions exist, it will jump over the next instruction and instead the instruction one location further. The long version branches to a target location or executes the next sequential instruction. The branch occurs if none of the selected conditions are matched, in a sense the inverse of how the short form works. However, in another way it is the same, as we either skip if any condition is true for short form or skip the branching if any condition is true in long form. If we don't skip, we execute the next sequential instruction after the BSC. 

The Modify Index and Skip (MDX) instruction, short form, does arithmetic on the IAR or one of the three index registers. If the result in the register after the arithmetic is zero or changes signs, it skips the next sequential instruction. If the IAR was changed it is just a jump to that location. The long format works similarly, except instead of updating the IAR, it adds to the value in a memory location or updates index registers. 

I didn't find any instructions that didn't work exactly as they should, but this was still not a comprehensive test. That will take place when I run the CPU diagnostics. 

PARITY ERROR BACK WHEN ADDRESS BIT 9 IS A 1

The issue is back. I had hoped this was simply caused by the CHI modification which I removed, but clearly it is not. This is the next area of restoration work. 

Resolution of Run lamp issues

DETERMINING CAUSE OF RUN LAMP FAILURE TO LIGHT

Since we saw that a direct ground input to the 3819 card does illuminate the lamp, the issue is further back in the machine. It was important to trace connectivity back to the gate which generates the condition which should light the lamp.

A card in slot G7 does most of the logic surrounding the Run lamp and the usage meter. It is the direct source of the signal that is routed to the 3819 card to make the lamp illuminate. I pulled the card and did a bench test of its functionality. The type was 3556, specific to this function. 

Simplified ALD page

The main source for turning on the lamp is CPU activity, but it will also activate if the disk drive is busy doing a seek; even if the CPU is in a wait state, the meter is also turning. Another interesting part of the circuit is where the CE key switch, if turned to the CE position to accumulate time on the CE usage meter rather than the customer usage meter, also blocks turning on the Run lamp. Thus, even if the CPU is executing instructions and the CE meter is rolling, the RUN lamp will not illuminate. This blocks the usage meters in the printers and card readers from running. 

The gates at the bottom right are the ones that directly turn on the RUN lamp, through the connection to the 3819 card. My initial check indicated that the gate is not producing a full high output as it should. This however could be a fault in the signal path to the 3819 card or a fault in that card itself, but I will first check the new card for correct operation. 

The actual circuit on the 3556 card that roll the meter is:

The circuit on the 3556 card that controls the RUN lamp is:

My workbench set up the card with an oscillator simulating the phase A master clock signal and slide switches to set up the various inputs that should control the operation. The 3556 card begins once the three signals from the top left of the ALD page are combined, so I have a switch to indicate that the CPU is working. Another switch indicates whether the CE key is activated or not. A third switch acts as the disk access busy signal. 

What I expect is to see the usage meter output B02 pull to ground when I have either the run condition or the disk access signals turned on. This does not have a pullup resistor on the 3556 card, thus I will have to add one for my testing. I should see it fire off the signal for a minimum of 400ms and continue until the driving conditions go away, with an additional 400ms thrown in for good measure. 

The RUN lamp output B07 should mirror what is happening on B02 as long as we don't activate the CE key signal, otherwise it should be blocked. 

Observing the actual card behavior, I found no output on either gate. There is a pin on the card (B13) that shows the trigger of the oneshot and that was working properly. When the conditions were proper for having the Run lamp and usage meter working, it was active. 

The part of the card circuit on the lower left, with inputs D04, D05 and D06 and output B05 is not used but the remainder is what implements the ALD section you see above. The output of the upper right transistor is what should produce a timed pulse from the circuit along the bottom from the middle to the right. That timed pulse will be visible on B13 and is redriven for more power where it is connected to one of the diode inputs for the B07 output and also to the OR input of the B02 output. 

I had a good signal going into the gate for B07 but nothing coming out. When I began probing the gate on the card (it is in one SLT module on the card) I found that it was not working properly. With a valid input when the run conditions were correct, it was not conducting properly to produce the output.

REPAIRING THE RUN LAMP

I grabbed another SLT module of the same type (451) from a donor card in my spare parts and swapped it on the card. Testing showed that this fixed the issue, with the card now generating the output on B07 that I expected.

I put the oscilloscope on the signal to validate the existence of the 400ms one shot output. Everything looked great so I put the card back into the 1130 and powered up. The Run lamp now glows exactly as it should. 

Dealing with the parity lamp dimness issue

OBSERVED BEHAVIOR OF THE PARITY LAMP

When a parity error is detected the lamp should illuminate brightly but was very dim the last times I had a parity error. Possibilities are that the driving input to the gate on the 3819 card is not at a valid voltage level, or the card is defective in the circuit for this output, or there is something wrong from the output of the 3819 to the lamp. 

TRACING DOWN THE SOURCE OF THE ISSUE

I quickly discovered that the bulb itself was bad - an open circuit. I replaced the bulb and verified that I got normal brightness with a parity error. 

However, after doing some other testing on the machine I noticed that the bulb was glowing dimly, just like before. 

This circuit is unique in having a capacitor across the input to the driver card (3819), a 0.22uf 100V component. If the part is leaky and acting a bit like a resistor, it would pull down the +3V output of the signal source gate. I am going to replace it and expect this will resolve the issue; if not I will keep working at the problem. 

Verifying all circuits driven by the repaired 3819 SLT card; still a couple of issues

SWAPPED IN NEW TANTALUM ON THIS CARD

Because the IBM Tantalum capacitors, rated at 60V, have failed once in this machine and once in a machine in Europe, they don't appear to have enough margin for the poorly regulated 48V DC rail used with solenoids in the machine. I bought a modern 75V rated part to install in 3819 cards which need the 48V rail to absorb back EMF from solenoids they are activating. 

Card with new axial tantalum installed

An IBM 1130 system has at least three 3819 cards, two used to drive the 1053 Console Printer (typewriter) solenoids and one to drive various 12V lamps and a 48V keyboard solenoid. 

Every solenoid in the 1053 typewriter has quenching diodes installed so the 3819 cards for the 1053 do not need access to 48V. It is provided only because the standard card includes this. When I look at the location where the typewriter's 3819 cards are installed, I can see that 48V is not hooked to the card's pin whereas the card which failed has it in order to quench the back EMF of the keyboard restore solenoids. 

When paper tape peripherals are installed, one or two more 3819 cards will be configured in the 1130 system. The VCF machine has the controller for a paper tape reader installed, thus a fourth 3819 card in this machine. It too has 48V supplied to it, so I switched the tantalum to my new 75V part for safety. 

CHECKING ALL LAMPS OPERATE PROPERLY

I was able to check that the Forms Check and KB Select lamps light since I can change the conditions to make this happen. Previously the Parity lamp was seen to light but very dimly. I hadn't seen the Run nor the File Ready lamps illuminate. The KB restore works just fine as well. 

File Ready will only come on when the disk controller sees a disk up to speed with the heads properly loaded. Since the drive is removed now for restoration, this won't happen naturally. However, my grounding the signal line coming to the 3819 I could see the lamp glow as it should. 

Run should light when the CPU is not stopped. It should also blip when I single step instructions. I has not lit. Grounding the input pin does produce a good glow from the lamp, so the issue is upstream in the logic.

The dim Parity lamp circuit is different in that it has a 0.22uf capacitor to ground across the lamp output. I suspect that this capacitor may have a leakage that is dividing the current, producing the dim light. I will experiment with an alternate capacitor. 

However, I also notice that both the Parity and the Run signals come in on a cable at connector N6 thus an issue with the connector seating or an issue with the continuity from the driving logic all the way to the 3819 might be responsible. I will be checking this in an upcoming session. 

Overvoltage Protection Card failure - temp repair waiting on parts - machine working fine again

BENCH TESTING OF THE -3V REGULATOR SHOWED THE CROWBAR CARD WAS TRIPPING

In spite of a proper low 3V output, the overvoltage protection SMS card energizes the 150A capacity SCR to short the regulator output, inducing an immediate trip of the circuit breaker. I pulled the card and began examining components on it. The list of suspects were two IBM 033 Germanium PNP transistors, a Zener diode, a small 1.6A SCR and the big 150A SCR. 

Further individual component testing today showed the zener and the two SCRs were in good shape. I could trigger either SCR to lock on, using current limiting bench power supplies to not overstress the parts. The Zener diode appeared to be working properly as well. 

The two parts which didn't look good were the IBM 33 transistors that form a comparator circuit to match the Zener driven reference voltage against the sampled actual output of the regulator. I don't have any spare boards with type 33 transistors on them, so I had to find an outside source. The sometimes dubious cross reference chart between IBM part numbers and industry standard numbers claimed that a 2N1303 would be a suitable replacement. 

Bad "033" transistors

Schematic of the failed SMS card

TEMPORARY SUBSTITUTE OF TWO 2N4403 SILICON PNP TRANSISTORS

I put in two silicon transistors while I wait for my order of the germanium 2N1303 to arrive. Silicon has a larger diode voltage which changes the circuit operating point a bit, but I can verify that it will provide the crowbar protection at some reasonable voltage point.

Using a current limited bench supply. I was able to observe the card triggering at 3.9V. Since it works consistently at that level, it would be safe to run the machine with the Silicon transistors until the more correct parts arrive that will lower the trigger point a bit more. 

TESTING REGULATOR WITH THE REPAIRED CARD SHOWS IT WAS GOOD

The bench setup supplied the regulator with about 8.2VDC as well as a -8.2VDC bias voltage from a second bench supply. An electronic load was used to change the current draw as a test of the regulation accuracy. The voltage stayed exactly on its set point over a wide range of current draws, so the regulator is good to return to the machine.

REINSTALLED AND POWERED UP THE MACHINE FOR A QUICK CHECKOUT

The regulator went back into the machine and I brought up the system for a quick checkout. It ran the keyboard test loop I had entered previously and seemed quite healthy. Now I can get back to working on the known issues and testing more of the machine. 

Sudden power issue on the VCF 1130; hoping the damage is localized to the Overvoltage Protection card

POWER UP OF MACHINE DURING TESTING - AUTO SHUTDOWN AND LOCKOUT

The protection circuitry of the IBM 1130 is designed so that if anything is not correct with the primary power rails, it will drop power and lock itself out (until the breaker or CE switch is reset) so that the power toggle no longer works. An SMS card has three reed relays in series, each powered by one of the three major rails - +3, +6 and -3. 

As the machine starts up a delay relay provides the main rails time to come up to voltage, before the SMS card tests that all three are correct. The machine stays in reset until the relay time expires. Then, either the SMS card drops power or a relay closes to provide +12 and +48V to the system. 

As the time delay expired this time, the machine powered down. I looked at the regulators for the main rails and saw that the -3V circuit breaker was in the OFF position. Other 1130 systems have had weak CBs that sometimes tripped during powerup; a reset of the CB is all it takes to get the show back on the road.

However, this time, after I reset the -3V CB and reset the lockout, the power up again stopped abruptly as the delay time expired. Once again the CB was tripped. We have a real issue!

DISCONNECTED THE LOGIC GATES FROM -3V TO CHECK ITS OPERATION

I took the connector off the regulator so that it only had its internal 1ohm load resistor. If the issue were elsewhere in the machine, I would expect to see the regulator delivering precisely -3V. However, the CB tripped immediately. This indicates an issue in the regulator itself. 

REMOVED REGULATOR AND PUT ON THE BENCH FOR TESTING

I disconnected the regulator completely and put it on my workbench where I can test with my bench supplies and loads. I set it up with a bit over 8V, the raw level delivered by the power supply to the regulator. There is also a -8V feed that represents the AC bias circuit from the power supply; the IBM design attempts to compensate for load effects by delivering an pseudo-independent voltage to the regulator. 

I hooked up an electronic load set to 1A as a low load, which will also show me the voltage being generated. I then flipped on the breaker with power supplied. 

I saw the same issue, with an attempt to trip the breaker. Since my bench supply was current limited, I just saw the input supply drop substantially and flipped off the test setup. Had I provided full current to the system, 

I chose to pull the Overvoltage Protection card (crowbar circuit) so that I could see how much of the regulator was working reasonably. Without that card, the regulator produced exactly -3V and held steady as I bumped up the load. 

OVERVOLTAGE PROTECTION CARD IS BAD

The crowbar is clamping even with the voltage at acceptable levels. I don't know for sure the exact sequence that occurred but the result now is several transistors and an SCR blown. I will figure out how that happened later, but first I want to repair the card so that I can verify the extent of damage first to the regulator and then to the entire 1130 system. 

TWIN IBM 33 TRANSISTORS FORM A COMPARATOR

The card uses a pair of transistors, one sampling the regulators output and the other drive by a zener diode to a fixed volage. When the sampled output exceeds the reference zener voltage, it triggers the gate of the first SCR. This SCR is a relatively low power 1.6A device, which in turn switches a higher current to the trigger of the 150A capacity main SCR. That SCR will short the entire output of the regulator, resulting in a trip of the circuit breaker. 

TESTING DEVICES TO IDENTIFY FAILED PARTS

The two transistors appear to have failed by shorting internally. I suspect that the lower power SCR is also toast, but the big one is probably okay. I will set up my testers to check out the two SCRs, determine the zener diode voltage, and test the two IBM 33 transistors just to be sure. Since these are germanium rather than silicon semiconductors, the diode checkers built in multimeters sometimes give misleading results. 

SSM 1053 prepared to go home

PACKING FOR SHIPMENT

I prepared the typewriter for shipment to ensure it is not harmed in any way during transit back to its home. Bubble wrap covers are on the three paddle cards that plug into the 1130 and the cables are neatly wrapped and tied. It is in a box labeled Fragile, Caution, and This Side Up. 

INSTALLATION INSTRUCTIONS COMPLETED

Since I am not likely to be present when the typewriter returns to SSM, I put together detailed instructions including plenty of pictures to guide the museum technicians in the mounting and reassembly of the printer onto the 1130 system. 

NEW DEMO PROGRAM BEING PREPARED TO USE WITH MUSEUM VISITORS

I am working out a demo program for the museum that will provide a range of activities, using different peripherals and parts of the machine, to provide maximum flexibility. I will send it to SSM once it is tested and working. 

Repaired the Console/Keyboard toggle switch function

THE TOGGLE SWITCH

On the console next to the power on switch is a toggle switch labeled Console and Keyboard. Its only purpose is to set a bit that is read in the Device Status Word (DSW) of the control keyboard/printer. Software should look at this bit to decide whether to take input from the keyboard or to instead read the console entry switches that sit on the faceplate of the typewriter. This is completely voluntary, the only thing done by the 1130 is to set the bit. 

PROBLEM OBSERVED

When I was running the hand loop to look at characters entered on the typewriter, I could see the DSW and that bit 3 (the toggle switch) was always on regardless of the physical position of the toggle.

I had thought that the switch contacts might be tarnished, but when I had the machine powered up and measured the pin at the output of the debouncer circuit, it was appropriate responding to the toggle switch. The readings were -3 and +5, which is the result of the debouncers, but those two values are completely acceptable as input into an SLT logic gate whose low and high levels are defined as 0 and +3V. 

When I looked at the pin that this signal should be directly linked to on an adjacent pin of the card, the voltages were not there. A continuity check confirmed that the board (backplane) which should have a trace between the pins was defective. 

REPAIRED

A bit of wire wrap restored connectivity of the two pins. The DSW now shows the accurate state of the toggle switch. 

Diagnosing memory parity error on VCF 1130 - fixed and working well

SYMPTOMS

Whenever address bit 9 is a 1, the machine gets parity errors, regardless of the remainder of the address bits. As a refresher, bit order on an 1130 is bit 0 leftmost, with the highest value and bit 15 on the right of the word is the least significant bit. Thus we are talking about addresses of the form xxxxxxxxx1xxxxxx where X means the value doesn't matter. 

BUILT PLAN TO LOOK AT ADDRESS BIT 9 AT VARIOUS SPOTS

Bit 9 is generated in the B gate, compartment B1 and then runs by cable over to B gate compartment C1 where the memory is located. In the memory compartment the bit in question enters at a cable connector in slot A1 pin C09. 

That signal, -SAR bit 9, is also inverted by a board in slot F2, since the logic in the memory uses both +Sar bit 9 and -Sar bit 9 to choose particular memory line drivers. 

I would look at the bit in B gate compartment B1 as well as in C1 at the entry connector and the inverter card. I did check the signal connectivity from the inverter card pins to the driver board pins that are responsible for handling bit 9, which was fine. 

There are two cards at G3 and H3 which produce the Y axis selection for one of eight sets of 16 addressing lines for all the entire 8K array. Each card handles four of the eight cases; for example, card G3 handles bit 9 being 0 and the four combinations of address bits 10 and 11. For a given binary pattern of the three address bits 9, 10 and 11 there is only one group of sixteen address lines which should be connected.

The connection is through a diode matrix and the card will either connect its sixteen Y lines to the +8.3V drive power if writing or sink the current on those lines if reading, since we reverse the direction of current flow between writing and reading. The Y axis has 8 sets of 16 line groups such as we are selecting with our two cards. 

The other end of those 16 line groups are tied together, the first line of each group together, the second line of each group tied together to a different common line, etc. The common lines are thus just sixteen for the entire Y axis, with cards that choose which of those sixteen common lines are active by address bits 12, 13, 14 and 15. Thus our bits 9 through 15 select one of 128 wires threaded in the Y axis.

The X axis is a bit simpler, with bits 3, 4 and 5 picking one group of 8 wires out of eight groups, then the bits 6, 7 and 8 picking among 8 common lines analogously to how in the Y axis we picked among 16 common lines. Having 64 X axis wires and 128 Y axis wires allows us to select one of 8,192 core positions or words. 

STRANGE CHI BOX INSIDE THE MACHINE IS WIRED UP TO MEMORY!

The machine has a thin aluminum box mounted to the wall of one of the gates, with a switch on top that is labeled CHI-IBM. There is a long cable coiled in the machine with a card edge connector at the far end. Previous guesses about this box was that CHI, a third party maker of modifications and peripherals for 1130 systems, used this either for another disk drive or for a third party printer. 

Box pulled from side of gate to investigate

However, as I examined the connections that made into the machine, I found that these were directly interfacing to memory. They grab the output of core sense lines, read the B register and look at the addresses and the storage read/write line. 

Connectors at top

Various plugs and connectors

I turned my attention to the inside of the thin box, which had a PCB with a number of logic chips. I didn't have to reverse engineer it far to discover that the chips are powered over the cable with the remote connector! No external box, no power. These chips are wired into the 1130 but it can't implement its "CHI-IBM" selection with no power to the logic!

REMOVAL OF THE THIRD PARTY MEMORY MODIFICATIONS

I studied where they were connected to determine if they had cut traces on the boards of the 1130 or otherwise made changes to the machine. It appeared that they only had the connectors onto the board and to various pins on the board - these could be pulled off. 

I therefore removed the entire CHI installation. Without the other box it was intended to connect to, this is useless. Further, it may be introducing the memory problem we were experiencing. 

RESULT - NO PARITY ERRORS AT ALL

When I tried the machine without the CHI connections, it worked perfectly. All memory is usable and as a bonus we even got the IX cycle back as a bonus. That was the problem where instructions that referenced index registers were not taking the IX memory cycle necessary to read or store the index register. Index registers on the 1130 are simply core memory address 0001, 0002 and 0003, thus a memory access cycle is needed to get to the index register. 

Keyboard working properly, plus reasonable DSWs from all device controllers configured on VCF 1130

DISCOVERED THAT ONE OXIDIZED SWITCH IN THE KEYBOARD BLOCKED THE RESTORE

After cleaning the contacts, the keyboard does a satisfying click restoring every time the device is selected. I ran the hand loop and checked every key to verify the code returned. This is ready for use.

CONSOLE/KEYBOARD SWITCH NOT BEING SENSED CORRECTLY

When sensing the DSW for the keyboard/console printer device, bit 3 shows the state of the toggle switch marked Console/Keyboard. However, the bit is always on, regardless of the position of the switch. I believed I had tested this switch previously, so we might have a logic failure. To be diagnosed and repaired.

SET UP SENSE DSW COMMANDS TO DEVICES, GOT BACK STATUS FOR EACH

I believed that this machine had controllers installed for the 2501 and 1442 readers, the 1132 printer, paper tape and the internal disk drive in addition to the console keyboard/printer. For each I put in the area code for the device and issued an XIO Sense DSW. 

The instruction loads the accumulator with bits defined for the device. If you issue a request for an area code whose controller logic was not installed, you get back a word of all zeroes. On the other hand, configured peripherals typically show at least a 'not ready' condition bit when you sense their DSW. That is what I saw with the devices above that I tested.

READ THE CONSOLE ENTRY SWITCHES

I set up area code 7 with an XIO Read command and when it executed, the bits I had turned on showed up correctly. Substantial parts of the XIO facility are working properly on the machine, much as substantial numbers of instructions are working properly. This gives me some optimism that this machine will end up restored to full operation. 

Deoxidizing contacts, looking into dim/missing lights with the 3819 card, verifying cycle steal behavior

MY FIRST ATTACK WAS ON THE FORMS SWITCH ON THE 1053

That was indeed an open circuit due to oxide but quickly recovered with Deoxit and exercising the switch. That was the reason that the Forms Check lamp was lit on the 1130 but wouldn't go out when I pushed down on the roller that senses paper in the path. 

SWAPPED 3819 CARD AND SAME CIRCUITS NOT WORKING PROPERLY

I put another 3819 card in the place of my repaired one, into the D5 slot, but the results were identical. Still no Run lamp, a dim Parity error lamp during an error, and no restore of the keyboard. That immediately points the finger at the board (backplane), where traces must have been partially and in some cases fully erased by the 48V surge through the failed tantalum capacitor. 

I will need to run wires to restore continuity to the pins on the backplane, as well as looking for shorts to ground or other issues in that area. 

TESTED THE PINS THAT MY CYCLE STEAL MEMORY LOADER WILL USE

My new memory loader that uses cycle steal, what is called Direct Memory Access (DMA) today, is based on the response to pulling certain pins to ground on the 1130 as well as sensing certain signals that control the progression of the state machine on my device. 

I put the scope on those pins to verify that the signals I sense do what I expected, then grounded the level 0 cycle steal request pin. I did see the machine taking cycle steal memory cycles, however since I didn't present any address bits the machine was reading/writing to location xFFFF which has the bad address bit 9. The result - Parity Error - as one would expect.

My future testing will use the Arduino and my board so that I can target single memory cycles at chosen addresses, which will let me confirm the rest of my assumptions behind the loader. It also will let me load memory locations and verify that the cycle steal mechanism is completely healthy, at least for level 0. 

BEGINNING DEOXIDATION OF THE KEYBOARD CONTACTS

I opened the table and removed the keyboard mechanism to give me access to all the exposed contacts where oxidation will have formed over the decades. 

The bails on the left and right sides at the back of the keyboard are open contacts that will need the most work. I worked with a burnishing tool as well as Deoxit spray, using an ohmmeter to validate when the resistance was back to nearly zero for each contact. 

At the bottom of the keyboard each keylever moves a vertical bar which at the bottom forces contacts closed under that key. This also needed burnishing and spraying to get the contacts down to nearly zero resistance.

I will check that all is well by reinstalling the keyboard and running the hand loop from the CE Handbook that displays the resulting code produced by every keypress. It depends, however, on the restore solenoids being driven, so this test has to wait until I fix the issues around slot D5 where the 3819 card caused damage. 

Digging into the VCF 1130 and identifying issues to resolve

CHECK CONDITION OF ALL RANGES OF MEMORY ADDRESSES

The machine was storing and loading memory just fine at the very low addresses I used to toggle in instructions, but I wanted to make sure that all sections were working. The 8K of IBM memory is divided into two 4K segments with independent addressing and read/write drivers. Furthermore, within each 4K, it is divided into two 2K ranges for sense circuits. 

I therefore wanted to make sure that each of the four 2K segments of memory were able to be written to and read back successfully. I wasn't ready to exhaustively address every word, but I wrote something into each block of memory to see that it worked well. 

IMPROVED GROUND FOR 3819 CARD AND REPLACED FORM CHECK BULB

I noticed that the bulbs were too dim, which suggests that the wire wrap connections I used to restore the ground traces to the 3819 pins D04 and D05 couldn't handle the current requirements for the bulbs and solenoids, developing enough resistance to lower the power delivered to the target device. 

I built a dual pin connector to fit on the D04 and D05 pins at card slot D5, with 20 gauge wire running down to the ground terminals of the terminal block on the A gate. This should support bright lamp operation. 

I mentioned earlier that the Forms Check lamp should have been lit since the typewriter had no paper installed. Pulling the bulb and testing it, I found it burned out. A replacement bulb was installed and it shines brightly now. 

I also set up an XIO instruction to do a keyboard select, which did light the KB Select lamp brightly. There are still issues with that 3819 card, as the Run lamp won't light at all, the Parity error lamp is quite dim, and the keyboard restore magnet was not firing to unlock and reset the keyboard. I don't know if the File Ready light would glow properly as the drive is not ready to power up. 

PARITY ERRORS FOR ANY ADDRESS WITH BIT 9 (MODULO 128) SET

Doing my testing of memory operation at different addresses, I happened upon an address where the machine took a parity error. The lamp illuminated, but dimly, and the machine locked requiring a reset. By the process of trial and error I realized that the parity error occurs with any address where the 128s bit is on (bit 9 of the address) will get all zeroes back include zero from the parity cores, triggering a parity error. 

Since this happens in both the upper and lower 4K ranges of memory, it is not a failed driver or wire within the core stack as these are duplicated. Instead, it is in the addressing logic either in the memory compartment or the CPU itself. I have faced these kinds of errors before with 1130 systems and the diagnosis and repair has been relatively easy. 

INTERRUPT HANDLERS WORK FINE

I pushed the Prog Stop button, which generates an interrupt on level 5. The machine should execute a BSI instruction to store the IAR address where we were interrupted in the first word of the interrupt handler and then branch to execute the second word of the handler. 

I had set up the handler with a wait instruction (0344) that I would recognize, coded an MDX branch instruction at location 0000 that branched to itself, and pushed start. The machine sat in a tight loop at location 0000 until I pushed the Prog Stop button, when it executed the wait instruction I had placed in the interrupt handler. 

TRIED MULTIPLE INSTRUCTIONS

I experimented with various instructions to see if I spotted any anomalies. Instructions such as Load Status properly set the Carry and Overflow flags, for example. I had tried short and long format instructions, indirect addressing and moved on to check an indexed form of an instruction.\

The IBM 1130 uses core memory locations 0001, 0002 and 0003 as the index registers IX1, IX2 and IX3. There is an instruction cycle IX that will read those low storage locations when the associated index register is referenced. 

INDEXED ADDRESSING ISSUE - MACHINE DOES NOT TAKE AN IX CYCLE

However, whenever I coded an instruction with an index register specified, the machine moved directly from instruction cycle I1 or I2 to the execution (E) stage, skipping an IX cycle. The state machine that advances through the instruction cycle stages from I1 to the E stages is pretty simple. There is a set of four signal conditions that are required to be high in order for the machine to move to IX instead of skipping over that stage. 

There are all inverted logic signals, so that high means the condition in the name is not true. Thus, the signal -Index Instruction is low when it is an instruction loading or storing the index registers, otherwise high. The signal -Tag 00 is low if there is no index register specified otherwise it is high. In the same way, a -IA cycle is high if we are not in an indirect addressing instruction cycle, and the -E Cycles signal is high if we are not in the E1, E2 or E3 execution stage. 

SLT treats an open circuit as a logic high, so this cannot be a broken connection causing the IX to be skipped. In many cases, the inverted logic signal is generated by a NOT gate whose input would cause a failure if it were not connected as that would force the gate output low and block our IX cycle. 

A bit of work with the oscilloscope will flag the bad signal, then I can find the root cause and repair it. This is the usual kind of failure I encounter during a restoration. 

FORMS SWITCH ON 1053 TOO OXIDIZED TO WORK

When I push down on the roller on the typewriter, simulating the pressure of paper that is fed into the printer, it should close the circuit and turn off the Forms Check light. However, this switch has been oxidized so badly on every 1130 I restored that I am pretty confident I just need to deoxidize it to clear this issue. 

XIO TO KEYBOARD WORKS GREAT

I toggled in a short routine from the CE Handbook that loops with the keyboard selected, waiting for a key to be pressed. It reads the character code of the key, leaves that in the ACC and resets and selects the keyboard for the next entry. 

 The machine handled XIO instructions properly, such as Control, Read and Sense DSW, recognizing commands sent to its device address (area code in 1130 parlance). However, the keyboard itself was not restoring so that I could only type in one character.

The way the physical keyboard works is that it has to be unlocked, either by the KB Restore pushbutton or the XIO to select the keyboard. If a key is pressed, it locks down and blocks any other keys from being pressed. This also selects the character code using a complex matrix of contacts, with the presence of a nonzero character code triggering an interrupt condition from the keyboard The software has to read the value of the character code which remains active all the time the key is down. The interrupting condition is reset via a form of a Sense DSW XIO command. 

Since the program wishes to read as many keys as the operator presses, it issues another XIO Control to select the keyboard. Part of that selection process is to restore the keyboard, by energizing a solenoid inside the keyboard that pushes all keys up and clears the contacts. 

OXIDIZED CONTACTS IN KEYBOARD

I had pushed the H key, which should encode into a Hollerith code 12-8 which shows up in the ACC as bits 0 and 10 but what we got was only bit 7. This tells me that the contacts in the keyboard are oxidized and not properly generating the character code. Across the rear of the keyboard are a number of bails that rotate to activate contacts on the left and right side. 

Each keystem has protrusions to move the bails whose contacts are associated with that key. In addition to the bail contacts, there are contacts on the bottom of the keyboard below each keystem. Finally, the Numeric button, which pressed, changes the wiring of the bails keystem switches.

Each physical key has two meanings, alphabetic or numeric; a better way to talk about it is that the numeric key selects the upper symbol on the keycap since some keys have two special characters, neither of them alphabetic or numeric. 

Deoxidizer and a contact burnisher will remove the hard oxide that forms on the open air contacts. I use an ohmmeter to judge when each contact is sufficiently clean. Once done, the keyboard is likely to produce perfect Hollerith codes for every keypress. 

KEYBOARD RESTORE MAGNET NOT BEING ENERGIZED

The restore magnet is powered by our suspect 3819 card, but the failure can be somewhere in the keyboard controller logic. We see that the logic correctly sees the XIO and sets the KB Select condition, as well as triggering interrupts and passing along the character code. However, a one shot should have fired to activate the keyboard restore solenoid. We don't yet know where this broke down - controller logic, 3819 card or elsewhere, but it won't be hard to track down and fix. 

STILL WORKING ON DISPLAY LAMPS - BULB LEADS CORRODED AND BREAKING OFF

I got the Interrupt levels 2, 3, 4 and 5 lamps to light, as well as a few of the status bulbs like I1, but in the process the lights for levels 0 and 1 stopped working. The bulbs used with the 1130 are wire lead incandescent bulbs, with the leads threaded down into a nylon bulb holder and held between a pin and the hole in the holder that the pin presses into. 

These nylon holders are then forced into a plastic honeycomb structure behind the front panel that holds each bulb behind the position it illuminates. The bulbs are mounted on wide PCBs that mount up to 16 bulbs from left to right, thus the entire board and all its bulbs have to be pushed in and pulled out anytime a single bulb needs replacement. 

The wire used on these bulbs tarnishes with age, particularly when exposed to corrosive environments such as rodent urine vapors. At the point where the wire enters the sealed glass envelope of the bulb, it is susceptible to cracking off due to the corrosion. 

In the case of the board that holds the interrupt level lamps plus some system state lamps, when I first removed the board a number of the glass envelops remained in the honeycomb as the wires were not attached at all. Interestingly, this is the same level as the SBR register whose 16 lamps also had a very high rate of falling apart. Lamps on the other five levels fared better. 

At the current rate, about a quarter of all the bulbs were either dead or had broken off wire leads. I was able to lend the machine some bulbs from my 1130 system's old light panel circuitry but before this is returned I have to source replacement bulbs. The world supply of incandescent lamps is dwindling, particularly of wire lead low voltage types. 

Testing repaired 3819 card in the machine

INSTALLED IN 1130 AND POWERED UP - NO ERRONEOUS LAMPS LIT

A bit of wire wrap on the board restored the connection for the ground pins D04 and D05 of the failed 3819 card. There appears to be connectivity to all the required pins. 

I put the card back in position D5 of compartment C1 of gate A. This card controls the following:

• Parity lamp
• File Ready lamp
• KB Select lamp
• restore solenoid on the keyboard
• Forms Check lamp
• Run lamp

Nothing was lit, however this isn't a completely good situation. The Forms Check lamp should be shining brightly since there is no paper in the console printer (typewriter). Each time I push the Prog Start to execute an instruction, the Run lamp should light. 

It is possible that these two bulbs were burned out since the errors I noticed and was troubleshooting initially was the spurious KB Select and Parity lights. I will check further on this when I get back to the shop. 

Pleased to report the machine is functioning fairly well

LOADING INSTRUCTIONS AND STEPPING THROUGH THEIR EXECUTION

I used the Load mode to place various instructions in memory, the Load IAR button to select the location when it wasn't sequentially after the last entry, and the Single Step mode to to walk through execution slowly. 

First I entered a short format branch instruction, validating that it did its job properly. I then added the long format bit, which converted this into a MDM (modify memory). I saw the machine step into the I2 phase to fetch the second word of the instruction. It then moved to the Indirect address IA phase as expected. 

A short format Load Accumulator instruction was next, which did indeed deposit the target location's contents into the ACC register. I changed it to a long format and watched that perform properly.

Having data in the ACC, I inserted a Shift Right instruction to move the bits five positions to the right, which it correctly.  

I have seen the addition and subtraction working just fine, as it is used to develop the effective address for instructions, taking the current IAR and adding displacements. I threw in a logical AND instruction which produced the expected results. 

GETTING ALL THE LIGHTS WORKING ON THE DISPLAY PANEL

I swapped in good bulbs and worked to remove oxidation on some other bulb contacts, getting more and more of the machine's lights working as far as Lamp Test is concerned. The remaining bulbs that are not lighting are a few in the IAR, SAR, and SBR registers, four of the interrupt levels, the Carry and Odd conditions, the I1 instruction cycle state, the TC state and one or two others. Maybe 20 not working out of 156. 

It is always possible that some of the bulbs that don't light are due to a failed SCR instead of the bulb, but I have not yet found any that are definitely caused by the SCR. 

It is also possible to have a bulb light from Lamp Test but the driving logic gate doesn't turn it on in normal mode. I have not yet found any that are failing like this.

EARLY DAYS IN THE RESTORATION BUT NO INDICATIONS THIS WILL BE DIFFICULT

This seems on par with the state of other IBM 1130 systems I have restored, where substantial portions of the machine work correctly and the defects are relatively few. 

Replacing bulbs in display and debugging the machine's behavior

BORROWED LOTS OF BULBS FROM MY OWN MACHINE FOR THE DURATION OF TESTING

I had converted my 1130 from the IBM incandescent lighting structure to a different design that I find easier to work with as I replace bulbs and work on the machine. The original long PCBs with the lamps installed were saved and are the source for the loan of working bulbs.

I need to see enough status on the display to identify what is working correctly and what fails. I populated the Storage Buffer Register (SBR) which shows the contents of memory fetches and the value set up in the console entry switches (CES). I also worked on the Wait bit and tried to get the Op Code bits register to light up. 

I didn't have every bulb working, but I could see most light when I flipped on Lamp Test so that I was comfortable using the display to guide my debugging going forward. The Op Code lights work under Lamp Test but were blank, as were the last four interrupt levels and the instruction cycle stages lights. 

I noted where the lights were driven from and began to check each of those conditions. The op code bits are produced by one SLT card and the signals run over a cable plugged into the edge of the board up to the display panel. I checked that the correct card was inserted and that it was seated well. While doing that, I noticed that the adjacent cable, the one that routed the signals up to the display panel, was not fully seated in its socket. 

When I reseated it, the Op Code bits lit up properly. I believe I will take off covers and carefully reseat all the connectors around the six card compartments as many signals travel between compartments on these cables. 

MEMORY WORKS GREAT AT LEAST IN THE LOW RANGE OF ADDRESSES

Now that I could see that SBR, I toggled in some values and stored them into memory locations. They were displayed properly when I went back in display mode. They also were moved into registers such as the Op Code bits during execution of that address. 

CODED A BRANCH INSTRUCTION AND IT WORKED PROPERLY

I put in an MDX 4 instruction, a short (one word) instruction that adds the operand (decimal 4) to the Instruction Address Register so the next instruction will be fetched from that updated location. I put the branch at location x0000 and stepped through its execution. I saw the adder working properly to generate the new IAR value of x0005. 

STORAGE LOAD AND STORAGE DISPLAY NOT WORKING CORRECTLY

The Load operation should take the value I entered in the console entry switches and then as I hold down the Prog Start key, it should loop through memory repeatedly storing that value. The Display function just loops through memory repeatedly fetching the contents of memory. It failed to loop with either function. 

3819 card repaired, tested and ready to reinstall; another card found with a failing tantalum capacitor

SWAPPED CIRCUIT FIVE WITH UNUSED CIRCUIT TWO ON CARD

I rerouted the input and output pins for the circuit (D13 and B13) to the spare circuit, which had been working properly in tests but would not be used in the D5 slot where this card will sit. This was a messy task but finally it was done. 

FUNCTION TESTING ON TEST BENCH

I wired the card in my jig to +3 and +6V, hooked up the grounds, ran the incandescent bulb through +12V to the output pin of each circuit and alternated connecting the input pin to ground (low) or leaving it open (high). I ensured that every circuit had a dark bulb when the input was open and a bright glow when the input is taken low. 

VERIFY +48V CONNECTION DOESN'T CAUSE FAILURES

The only use this card has for +48V is for quenching diodes to return any back EMF that might be produced when solenoids switch off, but the diodes are in a reverse position such that nothing should flow from the 48V input pin to anything else on the board. I checked that the +3, +6, output and input pins were unaffected when +48V was present. 

CHECKING GROUND TRACES AROUND SOCKET D5

Since another team had encountered a similar failure on this card and found their ground traces destroyed on the board (backplane) around this socket, I used my VOM to test connectivity for the normal ground pin D08 as well as the extra ground pins that handle the extra current if all the solenoids/lamps are being drive simultaneously. 

In theory a 3819 card could be pulling 2.4A if all eight circuits are sinking 300ma apiece. That is why the card has three ground pins instead of the usual single ground. A dead short on a tantalum capacitor across the 48V rail drew quite a bit more current than this, vaporizing traces on the card and potentially on the board as well. 

The board has power connectors to pin D04 on both card slots B4 and B5, containing 3819 cards driving the console printer solenoids, with internal traces on the board over to pins D04 and D05 of card slot D5 where the 3819 mainly controls the 12V lamps. There is no connectivity between D04, D05 and ground, either to the same pins on card slots B4 and B5 nor to the standard ground pin D08. This needs to be repaired with some wirewrap to bridge the grounds of the three 3819 cards. 

TESTED MY OTHER 3819 CARDS WHILE I HAD THE TEST JIG SET UP

I discovered that one of the cards was showing only 10 ohms resistance across the tantalum capacitor that covers the 48V supply. This is a failed capacitor and at that resistance would drive almost five amps until it further damaged the card and board. I quickly removed the bad capacitor. 

I ordered a couple of higher voltage tantalum capacitors - not an exact match in size but should be able to cram into the space on the card since it is only 3.5 x 7.6 mm but will verify that when they arrive. I picked 75V parts to give more margin. 

On the 1130, the 48V supply is only regulated (partially) by the ferroresonant transformer and tends to run high, 53 or 54 volts is common to see when lightly loaded. As the IBM capacitor is only rated at 60V, it won't take that much of an excursion to exceed the rating; tantalums are very sensitive to overvoltage and tend to fail in a short circuit, sometimes dramatically. 

Signs that this won't be a quick restoration but the difficulty level is not yet obvious

FINDING BURNED OUT LAMPS IN THE DISPLAY PANEL

The Lamp Test switch should light all 156 of the bulbs in the display panel, allowing identification of burned out lamps that need replacement. Each lamp is controlled by an SCR which has, in addition to its trigger (gate) electrode, a control pin with an internal resistor to the gate so that all lights can be triggered at once. 

Each row of bulbs has the hot 7.25V AC line delivered to one lead and the SCR rectifying the neutral AC and and feeding it to the other bulb lead on any half cycle while the gate is at logic high. There is an 6.2K inline resistor from the logic signal to the SCR gate, which in combination with the control pin 6.8K resistor divides the +3V logic high level but produces roughly 1.5V, easily enough to fire the SCR. 

In normal operation, the control pin is hooked to ground, producing that voltage divider mentioned in the paragraph above. However, when Lamp Test is activated, the control pin is fed +3V thus every SCR is certain to be triggered, either at +3V if the logic signal is also high, or at around 1.5V if the logic signal is low since the divider now works in the reverse direction. 

I observed a few bulbs out in the IAR and SAR register, but quite a few dark in the SBR. Some like the Op Code, part of the interrupt levels, and a couple of clock states were dark but most worked. There are eight lamps on the panel labeled CE, which could be driven by temporary cards inserted into the machine for debugging; these are therefore a good source of replacement bulbs for the many lights that are actually useful. 

I replaced the bulbs in the IAR and SAR positions I noted as dark, but tested the bulbs I removed. Only a couple were actually burned out. This is the first issue to be researched and fixed. Since the control pins are wired together on a bus as is the hot and neutral AC, all the bulbs should be energized. If they don't light but the bulb is actually good, there are only two possibilities:

• The contacts are oxidized and can be cleaned to restore continuity
• The SCR is dead and needs replacement

A replacement SCR that matches the IBM part including the internal 6.8K resistor is unobtainium. One would have to scavenge parts from other machines including S/360 types which use the same lighting circuitry. Eight of them from the CE positions of the panel are a good start on replacements. One might cobble together a small board with a surface mount SCR and resistor that could somehow be mounted in place of the IBM component, but that would be a time consuming fix. 

I then discovered the reason that the SBR (Storage Buffer Register) was so filled with nonworking positions. It had been manhandled sometime in the past, breaking off the leads of the bulbs and in many cases leaving the glass bulb stuck in the honeycomb when the PCB for that row of lights was pulled back. 

I hope that the abuse session that caused the SBR problems didn't also short out any SCRs. As long as power was not applied when this was done, the SCRs wouldn't be damaged but it is very easy to kill the SCR if not careful when it is energized. 

OBSERVATIONS THAT POINT TO DEEPER ISSUES

I tried the Storage Display function, which cycles through memory repeatedly thus immediately verifying that parity errors are not occurring. It worked fine. A good sign that at least the memory appears to be working. The parity scheme was chosen so that if the memory is not returning anything, it fails parity and causes a stop; this is why Storage Display is a good sign that memory is working pretty well. 

The next function I tried was the Storage Load function. When the switch is held up and Prog Start is pushed, it should cycle through memory like Storage Display but replace the contents of memory locations with the value set on the console entry switches on the front of the console printer. As I flipped the switches, I saw the parity bits for the left and right half of the word toggle on and off, thus the value was indeed getting somewhat deeply into the machine. 

Unfortunately, without the SBR lamps working, one can't see the values being selected nor see what is returned on a display operation. I then pushed the Prog Start button but the machine did not loop through all addresses as the Storage Display had; it seemed to do just one cycle and then stopped. This is incorrect behavior. 

When I hold the Reset button down (and during the first few seconds after power up while the machine does a power on reset), the SAR is left at a random address but should be cleared to all zeroes. The ACC (accumulator) is zeroed out except for the low order bit, 15, which is turned on during reset and then goes to zero when the Reset is released. This is also not correct behavior.

When I do Single Step execution, I do see the machine step through the T clock stages T0 to T7 and the IAR increment automatically by one. That is good behavior. However, the machine is not illuminating an instruction cycle stage, it remains blank. It should light I1 initially, and then depending on the instruction it could advance through I2, IX, IA, E1, E2 and E3 stages. Having none lit is not correct. 

Since I can't see the Op Code lights nor most of the SBR, I really can't evaluate what the machine is executing and whether it is doing the correct thing. I will prioritize getting a working SBR display as that will be key to debugging the machine further.