Solved issue with line space latch, but still spacing repeatedly

FOUND DEFINITIVE SIGNAL PROOF OF CAUSE OF LATCH ACTIVATING

The turn-on conditions are when an XIO Control command is being issued by the user for the device at area 6, which is the 1132 printer, at time T6 of a memory cycle, with the U register (saving the Input Output Control Command IOCC) has bit 15 set on. This is how a programmer requests to space down one line. 

No instructions were being executed, but the line +Printer Control Mode was logically high, thus anytime U Reg bit 15 was on, it would trigger a space. The logic gates that combine XIO Control, Area 6 and T6 were working correctly and the signal from them was a logic low, not high.

I then discovered that the trace connecting the card at K2 that produces the +Printer Control Mode signal was not connected to the other gates which use this signal. Disconnected in SLT often means it appears to be a logic high (1). I used wirewrap to complete the connection and the line space latch was no longer an issue. 

STILL HAVING CARRIAGE SPACE AND REPEATED SPACE RESPONSE INTERRUPTS

There is more wrong in the controller logic, as it was still moving the carriage and the controller was triggering a request for interrupt level 1 with the bits indicating carriage space response (completed) and carriage busy. WHen I get back to the shop I will track down these issues, resolve, and continue testing until the controller can handle the printer properly. 

Core memory repaired, operational again

WIRING FROM DIODE ARRAY TO BACKSIDE OF THE BACKPLANE, SLOT J2

I soldered a wire on the top left lead of the diode array for addresses with bits 9 to 11 of 000, routing it up past SLT cards to slot E2 from the rear of the backplane. There, I soldered it onto pin B09 which I had previously checked was unconnected to the rest of the board. 

WIRING ON BACKPLANE FROM SLOT E2 TO CARD IN SLOT G3

The current on the wire will be around 265 ma. I wanted to verify the effect of 30 ga wire, the usual for wirewrap on the backplane. The wire has a resistance of about 0.1 ohms for the length I am using, which produces a voltage drop of .0265 V and consumes 7 mw of power during a read cycle. This is well below its max recommended capacity in a circuit of around 800 ma. 

I therefore wrapped a wire on pin B09 of slot E2 and routed it to connect on pin D10 of slot G3. This completes the circuit path from the Y read drive card to the diode array. Just to be cautious I wrapped a second wire on the same path. 

TESTING RESULTS

The machine was now able to read and write from locations with addresses in that range - of the form xxxx xxxx x000 xxxx (binary) - which used that diode array. I used the Storage Load function to put a pattern of all 0 in core, then used Storage Display function to cycle through the locations. Then I used Storage Load to store a pattern of all 1 bits in core, with Storage Display working perfectly. The last test was to put a pattern of 8001 hex in every location to verify that the parity bit is working for odd parity as well as the even parity of the first two tests. 

The core memory is working again and I can get back to debugging the printer issue and then testing other aspects of the 1130. 

WORRY IN THE BACK OF MY MIND

With several sense wire breaks and now a connectivity break for one of the read drive lines, I have to worry that there is some condition on the core stack that might lead to further breaks on that bottom board. At some point I will run out of unassigned pins on the backplane and the task of routing extra wires will become too cumbersome. Plus, when the machine is trucked back to its home in New Jersey, the vibration and jostling might well induce further failures if the core stack is 'on the edge'. 

I therefore did some preliminary design thinking about a replacement for the core stack. Rather than using the SLT cards and wiring inside the compartment, I would just intercept the four control signals (select, use, read and write), plus the address, the incoming data word and the outgoing sense bits. 

Nonvolatile SRAM is much faster than the core memory access times, allowing easy engineering of a substitute with a relatively simple state machine to drive its response to CPU core access requests. I found a part, for example, which provides the 8K words plus parity in a single chip for about $12. It uses a lithium battery to preserve contents while powered off, with a life of at least 10 years. 

Therefore if the worst happens, I can disconnect power to the core stack, insert a small board into the compartment with the nonvolatile RAM, and have the machine operate exactly as it would have with the core installed. The one capability that would be lost is the ability to play songs over an AM radio near the core stack. 

Core memory issue crops up again; new break in continuity on core module backplane

WHILE DEBUGGING 1132 PRINTER, SUDDEN STEADY PARITY ERRORS

I was taking traces using the scope and sporadically executing a XIO Sense DSW command to see the status returned by the controller. Out of the blue, when I pushed the Prog Start to try another sense command, the Parity Stop struck. It seemed to be a hard error. 

CHECKING SIGNALS AND VOLTAGES ON STORAGE

I verified all the important voltages on the memory backplane and then monitored the memory signals with the scope. Most looked fine, until I checked the Y read drive current which was not present during the read half of the memory cycle. 

SPENT A BIT OF TIME TESTING ADDRESS BITS TO THE Y READ DRIVE CARDS

One possibility that could produce this error is when the gate driving read current to a block of diodes on the core stack, responsible for a range of memory locations, does not activate because one or more of the addressing bits are wrong or missing. I quickly eliminated that possibility.

FAIRLY EXHAUSTIVE TEST OF ADDRESS RANGES TO NARROW DOWN THE FAILURE

Still suspecting that the issue was a failure of the Y read drive and Y read gate current, but seeing the current flow correctly for writes, I realized it would likely be one or more cards rather than all reads. To pinpoint the card involved, I began varying the address from which I tried to read memory contents. 

ADDRESSING 101

The addressing for core memory uses bits 9 to 11 for the high side of the Y address. This selects one group of 16 wires in the Y axis. Using bits 12 to 15 to select which of the 16 lines in each group will be active allows the selection of one of the 128 wires running through core in the Y axis. 

Bits 3 to 5 select the high side of the X address, picking one group of 8 wires for the X direction. Then, bits 6 to 8 select which of the 8 lines in each group will be active. This picks one of 64 wires running in the X axis. 

CHECKING ALL Y ADDRESSES WITH X HELD STEADY AT 000000

I set bits 3 to 8 to all zero, then varied the lower address bits to see which ranges worked and which had parity errors because the cores were not flipped. Starting at 000 0000 repeated the solid parity checks, but when I set the upper three bits to any non-zero value, all sixteen locations selected by the bottom four bits worked well. In other words, for bits 9-11 at 001, 010, 011, 100, 101, 110 and 111, all sixteen values for bits 12-15 read perfectly. It was only when 9 to 11 were set to 000 that I had solid failures and they were all in sixteen values of bits 12 to 15. 

CHECKED ALL X ADDRESSES WITH Y HELD STEADY AT 0010000

I had a suspicion that I knew the failure already but for completeness sake I varied all the upper bits 3 to 7 just in case there were addressing problems with the X lines also. Every value from 000 000 to 111 111 worked just fine. 

MEMORY ADDRESSING 101 CONTINUED

The current was flowing fine on the write half of the memory cycle, which means that the Y wires were intact running through the core stack. Further, reading and writing use the same wires but alternate the flow of current such that the read flips a core to the 0 magnetic direction and a write will flip the core to a 1 magnetic direction until the inhibit wire current in on to block the flip. 

Each high part of an address, X or Y, is connected to the common side of a diode array. Diodes oriented in one direction (of current flow) are connected to the 8 or 16 wires in a group. Diodes oriented in the opposite direction are also connected to the same 8 or 16 wires. 

rotated 90 degrees left in real life

Focusing specifically on the Y axis since that is where we have the failure, the diode arrays have 16 connections. Physically there are two arrays of 8 connected to the same common point. That common point is fed by the read driver/write gate card for the particular value of address bits 9 to 11 that are wired to the common point. Since we have eight combinations of bits 9 to 11, there are eight wires connected to eight pairs of diode arrays, one for each address combination. 

Diagram of diode arrays associated to address bits

RECOGNIZING AND VERIFYING THE FAILURE

The write gate side of the diode array worked just fine for bit 9-11 of 000, but the read driver side did not. The path of the read driver signal for Y high bits 000 comes out of the G3 card at pin D10 and is routed to a jumper block at D5. There, the signal is passed to pins on the core stack, routed through the bottom PCB board of the stack and then discrete jumper wires carry the signals from the bottom board to the top board where the diode arrays are mounted. 

The signal for reader drive high bits of 000 goes to the very outermost clip on the bottom and top board, which may be why it was at risk. However, I don't see any damage there. More likely this is yet another failure of a trace on the core stack bottom board, where we previously experienced three sense wire trace failures. 

Diode board on top of core memory stack

I verified this by first proving connectivity from G3 B08, for bit 9-11 value of 001, to the second set of diode arrays on the board. Then I checked for G3 D10 to the first set of arrays, where of course we found a nearly open circuit. 

Jumpers from bottom board to diode board

PLANNED REPAIR TO BE EXECUTED ON NEXT VISIT TO THE SHOP

The fix will be similar to how I repaired the sense wire breaks. I will solder a wire to the diode array, route it to the backside of card slot J2 which is unpopulated on the IBM 1130. Two pins are unused and not connected to any traces - D02 and D11. For convenience of access I will use pin D11. Then on the backplane side I can run a wire between J2 D11 and G3 D10 restoring connectivity. 

Red circle around diode lead to attach wire

J2 slot with red circles on pins D02, D11

Checked signals from printer, voltages, still troubleshooting a continually spacing carriage

CHECKING INPUT SIGNALS FROM THE 1132 TO THE CONTROLLER LOGIC

I wasn't sure that the switches were still working properly nor that the switch signals we coming in correctly from the 1132. Since the interface uses a number of positive logic signals, any open circuit or failed part will appear to be asserting the logic signal. Image all the buttons appearing to be pressed simultaneously!

The circuit for debouncing charges a capacitor with 6V while the switch is unpressed, then discharges through a voltage divider (pair of resistors) to -3V. Thus the signals should appear to have a single digit negative voltage when not asserted, then deliver a pulse of about 4V. Holding a button down does nothing after the first pulse is emitted. 

I hooked the scope up to four signals at a time and verified the initial state as well as the operation of the button push. All the signals and the pushbuttons performed as they should. 

CHECKING VOLTAGES DELIVERED TO THE 1132 SLT BACKPLANE

The 1132 is fed power from the 1130 system - 230V AC, 12VDC and the main logic levels +6, +3 and -3V. A power supply inside the printer generates 48V to fire hammers and operate clutches for carriage movement. Everything checked out, all the power is good. 

DEBUGGING CARRIAGE SPACING AND RELATED INTERRUPTS

The symptom of this failure is the carriage continually running on the actual printer, the interrupt level 1 being raised, and the status to an XIO Sense Device showing carriage space response, carriage moving, and printer not ready bits (bits 2, 3 and 5). 

With a four channel scope, collecting data involves iterating to watch up to four signals at a time, hoping to find a causal signal at each step and proceeding back until a clear failure is spotted. Often time has to be devoted to studying the ALDs and deeply understanding the controller mechanisms so that you first understand what normal should look like and then can intelligently guess at possible defects. 

LINE SPACING LATCH IS ACTIVE

I found the signal -line space latch was at logic low, meaning that the latch was active. This fires the solenoid that unclutches the carriage allowing movement. This should be reset when the -Carr CB signal goes low, which is a 10 us pulse each time the carriage moves to a new vertical line position on the printer. 

SYMPTOMS TIED TO LATCHES BEING SET

The line space latch was set, but that should only take place when an XIO Control command is issued to Area 6 (the 1132 printer) and that command set bit 15 to request a space down of one line. This was never executed on the CPU, so the latch should not be triggered. 

When the line space latch is active (-line space latch goes to logic low) then the space carriage busy latch is set. This shows up as bit 3 with an XIO Sense DSW for the printer. It will only be reset when the Carr Space Int flipflop is reset after the XIO Sense DSW with a reset bit to clear the cause of the interrupt. 

When the -Carr CB pulse arrives, it resets the line space latch. When that latch goes to logic high, if the space carriage busy latch was set and the +Allow Space Int line is high from the printer, then we set the Carr Space Int flipflop which is one of the drivers of the request for an interrupt on IL1. The +Allow Space Int line is a debounced relay contact set on at the same time as the short -Carr CB pulse. 

The Carr Space Int flipflop shows up as bit 2 of the XIO Sense DSW. The other bit set in the DSW is bit 5, printer not ready, which is simply due to our not having pushed the Start button on the printer to make it ready. 

To sort out the mess above, which I am sure is hard to follow, I had to redraw schematics from two ALD pages plus several pages of the 1132 schematics in order to figure out how it all should work. The obvious conclusion is that somehow the line space latch is being triggered incorrectly, almost as soon as it is reset by the end of the line space movement from its previous iteration. 

The latch itself is implemented on a 3130 card which is a quad latch card, containing circuits to implement four latches. I had swapped this card with another 3130 from a different peripheral device controller, however the defect remained the same. I do have the schematics for the card, just in case.

The card which drives the inputs to the latch is a 509, consisting of ten inverters. I also have the schematics for this. Interestingly, the inverters do not use a pullup resistor making it hard to accurately observe the state of the signal with an oscilloscope, logic analyzer or VOM. I do have other 509 cards that I could swap, since I did not try changing this card. 

Debugging the cycle steal (DMA) loader - the plan when I get to the workshop

SCOPE MONITORING OF KEY SIGNALS IN THE CYCLE STEAL PROCESS

The shield that is fitted to the Arduino has a state machine to step through a cycle steal. Once the Arduino raises a signal to start a cycle, the shield must assert a request for a cycle steal on CS level 0. It waits until the processor grants the cycle steal, turning on the -CS Level 0 signal, at which time the shield must pass the storage address and data values through to the 1130.

Each cycle steal memory cycle takes eight clock steps, four for the read of the core location and another four for the write stage. While normal instruction execution uses the T clock for its eight steps, named T0 to T7, that clock is held while a separate X clock advances for the cycle steal. Those are X0 to X7.

When we reach X6, the data has already been transferred to the Storage Buffer Register and written to the memory location, thus we can drop our data and address signals. As the cycle steal ends, we will see -CS Level 0 drop. At that time the shield will notify the Arduino that the cycle is complete. When the Arduino drops its request signal, the state machine goes back to idle and waits for a next request.

I will monitor -CS Level 0, -X6, -CS Level 0 Req, and +Storage Write Cycle on the oscilloscope in order to judge whether the state machine is moving as I expected and if it seems properly synchronized with the 1130. That is a microscopic level of evidence I will look for. 

TESTS USING THE LOADER

As a higher level verification, I will have first store a known pattern A5A5 into all of core so that I can immediately tell if any location is changed by the loader. I will then connect to the loader with a tablet over USB and try a few commands. 

After enabling the loader with a line containing #, I will set a starting memory location into the Arduino with the @0100 command. This is saved in the Arduino and is where the next data word will be stored, autoincrementing after each store. I will then write three words in succession, each on its own line sent to the loader. First, 0000, then FFFF, then 5A5A. 

I will observe the 1130 display panel as this happens to see if I spot the activity and if the registers are updated in any way. I expect no change to the Instruction Address Register (IAR), Accumulator (ACC), Arithmetic Factor Register (AFR) and Accumulator Extension (EXT). I may see the Storage Address Register changed to show the address where the loader placed the last word of data, but I don't believe this will happen. Finally, I will see the last data value in the Storage Buffer Register, which I do expect since the process of writing to core loads the SBR. 

Using the Display mode, I will check the words at 0100, 0101 and 0102 for the patterns I intended to load. If these are correct, I will look at adjacent words (00FF and 1013) to be sure I am not touching locations that should not be changed.

CHECKING FOR STRAY DATA IN MEMORY

If all that looks good, I will restore 0100 to 0102 to the default pattern A5A5. A small hand loop is inserted in low core to read every word of memory and compare it to A5A5. It will stop at any location that differs. Except for my small hand loop, there should be no stops. 

USE THE LOADER WITH A SIZEABLE PROGRAM

As a top level proof of concept, I will upload the CPU diagnostics into core and run them. This will execute every instruction and variation of instruction processing as a checkout of the soundness of the IBM 1130 and at the same time, of the soundness of the core loader. 

Cables arrived and hooked to the cycle steal (DMA) core loader

CABLES ADDED, ALMOST READY FOR TESTING

My cables arrived and I hooked the Arduino sandwich to the two header blocks on the 1130 logic gate B. I continued my work on the 1132 printer controller debugging, with no interference from the attached cables and controller. 

REMAINING WORK

The Arduino stack will be mounted inside the 1130 frame. I haven't finalized the location or mounting method yet, but don't expect much of a problem ahead for that. 

A pair of wires have to connect the Arduino sandwich with the +12V power rail of the IBM 1130, so that it powers up with the machine. When that is hooked up, the loader is ready for testing. 

Beginning debugging of the 1132 printer controller logic; hooked up my printer

CPU NOW GOOD, TURNING TO LOOK AT ADDITIONAL PARTS OF THE MACHINE

Because of how well the CPU seems to be free of defects, with every instruction type and variation that I tried I found it working exactly as it should. When I finish the cycle steal memory loader, I can run the exhaustive CPU test diagnostic, but I am waiting on cables. I expect to work on the loader on Saturday.

Each peripheral has controller logic built into the 1130, responsible for handling the XIO commands aimed at the device, controlling the device's operation and interfacing with interrupts, memory, cycle stealing and other aspects of the CPU. I have tested the keyboard controller logic already but for most, the peripheral device has to be functional to get the logic fully tested. 

I am making good progress on restoring the console printer (typewriter) thus soon I can test out that controller logic. The disk drive, on the other hand, has quite a bit of work needed before I can spin it up to test. 

This machine was configured with controllers for the 1132 line printer, the 1442 card reader/punch, and the 2501 card reader. I have the printer and the 1442 reader but do not have a 2501. I can shake down the controllers using my peripherals, that would just leave a need to fake out the logic in lieu of an actual 2501 being connected. 

I decided to work on the line printer next. The cards were inserted back into the compartment (A-A1) a few days ago. I found the logic was triggering an interrupt on level 1, claiming that a line space operation had just completed. The logic used positive signals such as +Carriage Space Sw to signal when pushbuttons were activated. In SLT, an open connection is the same as a logic high, so the logic was responding to multiple pushbuttons, as far as it knew. 

I temporarily blocked off the interrupt request in order to work on the keyboard issue. Now it was time to debug the controller logic itself. Rather than trying to jumper around to deal with all the inputs from the printer I decided to hook up a real printer. 

CABLED UP MY 1132 PRINTER TO THE 1130

My 1132 printer was next to the VCF 1130. I didn't even need to move it around. The printer has two long cables attached with special connectors at the end. One carries all the signals between the printer and CPU, while the other carries power. The 1132 is powered from the 1130 system; it does not have its own power cord.

FOUND ONE BROKEN TRACE ON A BACKPLANE

As I was tracing down the signals that caused the 'space complete interrupt' condition, I discovered that a connection which should have existed between two pins was nonexistent. Using a wire wrap tool, I bridged the pins with some wire. 

This completed a circuit to begin driving the carriage to skip and turned on that interrupt condition as well. At this point, I realized I first had to validate the correctness of the pushbuttons and other signals coming in from the 1132 to the controller logic. The circuitry is a bit odd for those buttons.

Rather than use the normal debouncer circuit (what IBM calls an integrator), an RC network to allow a signal to switch between two states and hold either level steadily, the 1132 had its own circuit design. It would charge a capacitor while the switch was in its normally closed position and then drain the capacitor and output when the switch was thrown to the normally open position. 

Typical oddly drawn IBM documentation

This produces a single pulse rather than a steady level, but that means holding a button down for a long time still only generates one pulse. Usually a single shot would be triggered by the edge of the input signal, providing the same one-pulse only effect, but the 1132 did this with discrete components and no logic gate at all.  The output sits at -3V until a button is pressed, when it jumps up to 4V and rapidly declines as the capacitor is discharged. 

When I get back to the shop, I will monitor every input line from the 1132 to verify that they are working correctly. I should see -3V on them while not activated and using a scope I can watch the pulse as the button is pushed.