1132 Printer controller logic appears to be working properly. Installed 1442 reader/punch SLT cards to begin testing that logic

CORRECT SLT CARD FOR PRINTER IS JUST ONE 0000 ADDED IN SLOT M6

After I checked every signal net from card M6, it showed this was a relocation of the 0000 card from the slot B3 where it was shown in every ALD I have seen, with an 0509 card sitting in that slot for some unknown reason. This is a different engineering level than any I have seen.

EXTREMELY IMPORTANT TO GET THE ALDS THAT MATCH A SPECIFIC MACHINE

For many computers, the schematics for a particular model are the same for every serial number of that machine. This is definitely not true for IBM mainframes from the 1950s through the 1970s at least. The documentation, called Automated Logic Diagrams (ALD) are unique to the serial number. They eliminate gates and connections based on the exact configuration. 

I have collected as many scanned ALDs as I can find for IBM 1130 systems, hoping to between them amass all the logic for various peripherals and features. That is how I have ALD information on the 2501 card reader and the synchronous communications adapter (SCA) that was not included in my own manuals because they were not configured on my machine. Recently I got copies of the 1133 ALDs, but there are still devices for which I have no documentation. The 2250 graphics terminal and the 1231 optical mark reader are the two which were normal options for 1130 systems. 

PRINTER SPACING, SKIPPING AT HIGH SPEED AND PRINTING CHARACTERS

I was able to issue XIO commands to cause the printer to start print mode, where it interrupts on IL1 to inform the software when each new character position on the 120 print wheels is approaching the spot in front of the paper. I set up patterns in the fixed memory locations x0020 to x0029 where the printer controller will cycle steal to fire hammers for each position with a 1 bit set. 

The software must issue an XIO Read to get the code value of the character that is ready to print. The software then sets the 1 bits in the fixed area 0020-0029 and the controller uses that to fire appropriate hammers. The software issues an XIO Control to stop printing when all characters that are needed on the print line have been printed. 

The XIO Control command to start the carriage skipping and we will then get an interrupt each time a brush detects a hole in channels 1, 2, 3, 4, 5, 6, 9 or 12 of the carriage control tape. The Sense DSW command shows which channels had holes detected, so that the software can issue an XIO Control to stop skipping when the desired channel was reached. 

It takes quite a bit of software to control all of this, more than I was willing to develop and toggle in for the testing. Once I saw that proper character codes were read by the XIO Read, that the selected hammers would fire when the printer was started, and that the carriage would start and stop skilling, I knew the functionality was there. I saw the interrupt level activated and saw appropriate DSW bits each time I tested. 

There is only one condition I didn't check - the print scan error test. Since the software must respond to an interrupt request to read the character code, then must set up the bits in the fixed area before the printer begins fetching, it is possible if the software is delayed that the printer wheels will r each the point where the controller fetches the fixed area and fires hammers.

To detect when the software didn't complete its task in time, the hardware makes use of one bit position in word x0029 to detect the problem. It depends on the software following a process where it clears that last bit (bit 15 of 0029) when it first responds to the interrupt for a new character getting ready to print. The software reads the character code, sets up bits in locations 0020 to 0029, then sets bit 15 of 0029 to a 1. This means the software completed its task. 

After the interrupt is requested for a new character approaching, there is approximately 11.2 milliseconds delay before the fixed locations are fetched and hammers fired. If during the fetch, bit 15 of word 0029 is not set to a 1, then controller detects a print scan error and indicates this in the DSW with bit 4 turned on. 

The software should delay through 47 interrupts with character codes, thus returning to the character that was being printed when the print scan error occurred. It would then set up the bits in 0020 to 0029 to reprint the character, presumably without error. 

The software must also perform 'idle scan cycles', meaning setting the locations 0020 to 0029 to all zeroes except for bit 15 of the last word. This causes no hammers to fire. For some situations, the software must count up 16 interrupts for approaching characters on the print wheel but ignore it, instead issuing the idle scan cycle. 

INSTALLED CARDS IN COMPARTMENT A-B1 FOR THE 1442 CARD READER/PUNCH

I installed the 31 SLT cards that implement the read/punch controller logic into their assigned slots in the compartment. I am not yet ready to cable up my 1442 peripheral to the machine, but can verify some behavior right away. 

The controller responds to the Sense DSW command for its area code (device address) and gives appropriate status. I see the Not Ready condition signaled with bit 15 turned on, plus bit 2 indicating an Error. There are several errors that can turn on this bit, such as various feed checks and jams. It also detects feed movement when the clutch has not been activated and it detects cards blocking the photocells when no card should be present in that area. 

When I get back to the workshop I will test which of these errors are set and determine if it is logical that they were triggered. With disconnected wires, they usually are treated as a logic high by the SLT gates they feed. This is likely the impetus for one or more of the error conditions. 

Massive time waste - circuit different than ALDs - but made significant progress

 CLUE FROM MY EARLY NOTES

When I surveyed the cards in the 1130, I listed an 0509 in slot B3 rather than the 0000 that every copy of ALDs that I have seen lists. I also had spotted an 0000 card in slot F6 which is not part of the 1132 nor the 2501 controller logic pages. The 0509 provides ten inverters while the 0000 is six NAND gates, so quite different.

This in fact explains the lack of connectivity to most of the pins of B3 from B2. Today I traced the wirewrap that IBM applied to the machine in the area of B2 and B3. I found many signals running from B2 down to slots F6 and M6. I had noticed an 0000 in the spot and that gate matches the pin usage well. 

I painstakingly worked out the actual wiring for the machine and knew that all my repairs with wirewrap were wrong. I pulled all the wires off and inserted an 0000 in F6. The machine came up without the continual carriage spacing issue! No more spurious interrupt on level 1! It did respond to pushes of the Carriage Space button on the printer too. 

The status from a Sense DSW still showed carriage space busy, however, which is not correct. I did try executing an XIO command to drive a space of the printer - that worked perfectly but did not raise the interrupt since the controller needs the carriage space busy signal to turn off before it triggers the interrupt. 

DEBUGGING THE CARRIAGE SPACE BUSY LATCH

It appeared that part of the carriage space busy latch was implemented in the M6 position. One that I did not note as having a card present when I first examined the machine, but that could be an error on my part.

I will spend the afternoon tracing out the gates for this latch and watch signals until I find the flaw and correct it. 

WHAT WORKS WELL ALREADY

I have already verified that an XIO Sense DSW returns appropriate status bits, at least for carriage movement, carriage brush 1-12 state, absence of paper forms and line space operation completion. We know interrupts happen on IL1 for these conditions. Presently I have a jumper installed that blocks the interrupt but I removed that to move forward. 

I also operated the manual line space button which does advance the carriage one line position. Finally, I proved that the logic for entering the Ready state performs properly when the Start button is pressed as long as the motor is switched on. 

Preparing for backplane testing after wirewrap repairs

SLOT A2 AND CONNECTOR T1 TESTED FOR CONNECTIONS INTO THE BACKPLANE

The backplane of the 1130 (and S/360) is a four layer PCB made of glass epoxy with circuit patterns photoetched onto each layer. One internal layer provides a ground plane and the other routes power horizontally, with it divided vertically into the horizontal strips for the three power rails. 

The side of the backplane that has pins used with wirewrap is used for horizontal traces. The side where SLT cards plug in has vertical traces. Through plated vias connect the front and back to allow signals to change between horizontal and vertical segments. 

Normally the first and last columns, A and N, are reserved for cables to plug in, as are sideways connectors at the top and bottom which are labeled T-1 to T4 at top and T5 to T8 across the bottom. SLT cards are generally plugged into the columns B through M in vertical rows 2 through 7, although cables can go into B or M. More rarely still, an SLT card could be put into A or N. 

Since our connectivity breaks occurred between B2 and B3, I naturally had tested connectivity for cards C2 and C3. During that testing I verified the connections to A3 as those were routed to cards C2 and C3. I had not tested the slot to the right of B2, namely A2. Nor had I tested connector T-1 which spans across above B2. 

There are no cables plugged into T1 through T4. Wirewrap to those pins was apparently used for debugging by IBM. I also didn't find any any broken connections from A2, A3 or A4. 

CARDS REINSERTED BUT 1130 STAYED IN POWER ON RESET

I put the SLT cards back into the compartment but when I powered up, the system remained in reset mode. Trough a process of trial and error, I found that the problem occurred when card B2 was in the slot. This was the location of extensive wire-wrap repairs I had made, thus this likely was a self inflicted problem.

I began checking all the nets and connections. I found two links that need additional wire-wrap connections and found that the reset input to pin D05 was somehow connected to pin B07, which has an output which keeps the reset signal at logic low. I ran out of time today - got a very late start because I had to accompany contractors into units at our condominium complete which burned up most of the day. 

Tried out demo monitor I originally built for SSM

MONITOR IS PERMANENTLY RESIDENT IN CORE, HOSTS MULTIPLE DEMONSTRATIONS

I wrote some software to load into an IBM 1130 when a museum does not have peripherals nor the disk drive operation to run the normal Disk Monitor System (DMS), a batch processing executive program. The code will allow up to 16 demonstrations to be loaded into the machine and updated individually, but take advantage of shared services from the monitor that hosts them.

The museum docent selects one of the 16 console entry switches and pushes the Int Req key on the keyboard to invoke a demonstration. These end with a wait state and code in one of the system registers. Some of the demonstrations use the keyboard or the console printer (typewriter), but others run even when those devices are not functioning. 

LOADED MONITOR AND THE DEMONSTRATIONS

I used my cycle steal (DMA) loader to install the monitor and some demonstrations into the memory of the VCF 1130, then verified that some work correctly on this system. 

COULD NOT RUN THOSE THAT NEED THE CONSOLE PRINTER (TYPEWRITER) YET

I have completed restoration of the keyboard but the console printer needs a bit more work before I reinstall it onto the 1130 where it can be used by demo programs. 

EXAMPLES OF DEMONSTRATIONS I RAN

Calculating digits of Pi using the Rabinowicz-Wagon spigot algorithm, with the results accurate to the 25th place. Accepting keyed in numbers on the keyboard and displaying the binary value in the ACC register. Perform multiplications for 60 seconds, completing 1.2 million of them. 

xxx

xxx

Troubleshooting the B2 card connections causing the 1132 printer line spacing issue

DREW OUT THE NETS FOR EVERY PIN ON B2 AND B3

I used the ALDs and flipped through them in order to list all the other pins connected to each pin of B2 and B3. I will use this for two verifications - modifications detected by wire-wrap and broken connectivity. For both, I will pull all the SLT cards so that I don't see connections inside the cards, only traces or wire-wrap connections. 

LOOKED FOR MODIFICATIONS

I followed all the yellow IBM wire-wrap to the destination pins to see if they indicate that my ALD is not an accurate representation of this board. If this uses an alternative assignment of gates and different wiring, it will complicate things immensely.

Fortunately, this did not seem to be the case, as far as everything I could check with the wire-wrap on the board. Any modified traces are much harder to spot. 

LISTING ALL CONNECTIVITY BREAKS DISCOVERED

I found quite a few pins that did not have full connectivity to all their peers in the net. In some cases, the net had been subdivided, with several pins in one group and one or more in a second. This reduced the number of connections I had to add to the backplane. 

It appears that we mainly have broken connections between B2 and all the other cards. The signals that seemed to be broken appeared to be vertical traces on the backplane. This suggests that this corner of the backplane suffered trauma, perhaps just at the card socket, which severed quite a few connections. 

Possible sign of glass fracture on this side of backplane at B2

I checked the connectivity of the adjacent cards at B3, C2 and C3. These were all fully connected as they should be. I ran out of time due to a satellite launch this evening that I am working, as there are a few more adjacencies I need to test. Namely the top cable connector that spans over the B column, as well as the A2 cable connector to the right of the damaged card slot. I had tested all the links from A3, below it, over to C2 and C3, so the odds are that most are still good. Still, this should be verified before I resume testing. 

WIRE WRAP CONNECTIONS ADDED TO RESTORE LINKS BETWEEN B2 AND OTHERS

I added wires to restore all the nets. Unless I find other issues with the top cable connector or socket A3, I believe I can go back to more traditional debugging with this issue behind me. 

Pulling one card stops the runaway line spacing behavior - mystery short discovered on backplane

DETAILED OBSERVATIONS OF THE LATCH ATTEMPTING TO RESET

The top trace is the +Line Space Latch signal, output of the latch. The green trace is the reset condition that should cause the top signal to drop down to near zero volts. The output never falls below 1.9V, way too high to be considered a logic low state and produce a reset. 

I have swapped all the cards in the controller logic. I also tested all the cards that touch the -Line Space Latch output which never gets much above zero volts even when a reset should occur. It does reset perfectly at power on but not later. 

I couldn't see any wires touching the pins in the relatively small net for -Line Space Latch. It is generated at D3 D10, runs to E3 B13, B3 D02 and B2 D07 as well as to the resistor pullup at J3 D05. With all the cards pulled, this net has infinite resistance to all power rails. 

My suspicion then turned to a short where an output of some other gate is interfering, holding this signal low in spite of the latch attempting to reset. That would be a dynamic situation, explaining why we start out with a good reset at power-on and then fail later. 

PROCESS OF ELIMINATION TO FIND CARD THAT IS INTERFERING WITH OUR NET

I left the latch card (D3) and powered up. No runaway spacing. I added in E3, which allowed for manual spacing. That worked perfectly, turning on the latch which then reset as soon as the carriage reached the next line position and output a pulse on -carriage CB. Still no runaway. 

Next I added in the card in B2. Again, no line spacing issue. Finally, when card B3 was inserted, the issue came back. This tells me that some activity of that card is impacting the signal. 

I put the card on the bench - although I have swapped them all so it isn't a defect in the card. The input pin D02 is working as it should. We just have problems when the card is active. 

TESTING OUTPUT PINS OF CARD IN B3 TO SEE WHICH IS SHORTED TO D3 D10

There are only six output pins on the card which could be driving signals to interfere with our latch on D3. I tested each and found that pin B02 was a dead short to our latch line. This is an output that should not be directly connected to our latch (D3 D10). 

The connection is on the backplane. There is no wirewrap making the connection, but I had previously found that a missing connection between this card for pin D02, which should have been connected to B2 and the reset of the D3 D10 latch net. 

LOOKING CLOSELY AT THE SLOT PINS FOR SIGNS OF THE SHORT

I zoomed in to the backplane to see if I could find a short between B02 and nearby pins on our net - the most likely culprit being the adjacent pin D02. 

I don't see anything shorting here, but previously I found D02 was not connected where it should be, suggesting this area of the backplane has suffered some failure of the printed circuit traces. 

I will need to break the connection - once I find it. The short is either on this side or on the side where the SLT cards plug in. If I can spot the bridging trace I can cut it with an Xacto knife and restore the machine to operation (or at least this problem will be fixed). 

CPU Functional Test (diagnostic) runs to completion

DIAGNOSTIC SITTING IN CORE READY TO BE RUN AGAIN

One of the benefits of core memory is that it retains the value of the data when power is turned off. Thus when I powered on this morning, the code was sitting there ready to be run. I would only need to set the IAR to the start address and push Prog Start. 

USED STORAGE DISPLAY FUNCTION TO LOOP THROUGH MEMORY REPEATEDLY

The CE switches inside the 1130 include a Storage Display switch which causes the machine to run continually reading memory locations and advancing the memory address each time. Since the memory addresses wrap around, this means the system will loop around and around touching every word in memory. 

I left this running for several minutes, so that if we have any sporadic parity check problems this would detect them. The 1130 also has memory diagnostics to write various patterns in memory to try to trigger any errors if I find parity issues. 

RAN CPU FUNCTION TEST AGAIN - THUMBS UP

The diagnostic ran two minutes and 37 seconds, running through every instruction including all variants and boundary cases. It ends successfully when it stops with 3003 in the Storage Buffer Register. Any defects in execution would have produced different stop codes. 

Updated PCBs on order for the Cycle Steal (DMA) Core Loader

NEED FOR BODGE WIRES REMOVED BY NEW VERSION OF THE PCB

Having determined the correct design and wiring for the board by way of the bodge wires and testing, I now know how to build this with no modifications necessary. I redid the PCBs in KiCAD and sent them off the JLCPCB for manufacturing. I expect to get them back in less than two weeks.

WILL REPLACE THE MODIFIED UNIT WITH A NEW ONE

I will remove the wiring and the 0000 card from the VCF 1130 I am restoring, add the new wiring to the header and ready the system for testing a 'production' version of the loader. Once I build the new card I will put it into the system and run it through its paces to verify everything is good. 

WILL BUILD A SECOND LOADER FOR THE SSM MACHINE USING NEW PCBS

Using the new PCB, I will put together a loader for the 1130 at the System Source Museum. When I get up to visit them I can install it so that they have a fast way to loading core. 

Cycle Steal (DMA) Core Loader works - CPU function test being run

BOARD MODIFICATIONS MADE

I identified places to cut traces at the edges of multiple integrated circuit chipss. Two of them had traces underneath the chip, thus I had to remove it with the hot air rework tool, cut the traces and then resolder the chip.

I had to run some bodge from pads of the ICs where I did the trace cuts. In addition, a small resistor was soldered across two pads to provide the pullup for the open circuit outputs. 

The first test highlighted that the logic of my modification needed to be inverted. Again there was a spare gate available on a 74LS04 hex inverter, so I added that into the wiring. A second test then showed that I had to hold the address and data lines longer than the request lines, so I needed to accomplish this, made with another spare gate and more bodge wiring. Finally I had the logic raising the signals exactly as needed to drive the 1130. 

Hacked up board until it worked as I wanted

NOT SEEING THE DATA STORED IN MEMORY

When I check the outputs of my loader I can see the correct address lines activated and the data is displayed in the Storage Buffer Register on the 1130. However, the memory location is not modified. 

Bottom two lines are storage addresses

I traced many signals, first to show the memory cycle, then the various control signals. Finally when I looked at the address lines going to the core memory compartment, I realized that my addresses were not getting through. After a bit of hunting, I realized that the disk drive controller logic was jamming its own address at the same time as I was trying to drive the memory lines. To verify this, I pulled the two SLT cards F6 and G6 from B-A1. Those cards drive the controller's address into the common memory address bus. The loader worked perfectly!

MOVING OVER TO CYCLE STEAL LEVEL 1 FROM LEVEL 0 TO AVOID INTERFERENCE

IBM implemented four cycle steal levels, arranged in priority from the highest, level 0, down to the lowest level 3. Level 0 is assigned to the internal disk drive, level 2 is assigned to the 1132 printer and level 3 is assigned to the 2501 card reader. All other peripherals whose controllers are contained with an 1130 function without use of cycle steal. 

Level 1 is reserved for any peripheral whose controller logic is not implemented inside the 1130 (1131 is the number of the basic unit). This is used to attach either the 2250 graphics terminal or the 1133 expansion box. Using the 1133, devices such as the 1403 printer, 2310 disk drives, 2311 disk drives, 2741 selectric terminals, 2250 terminals and 2400 tape drives could be connected to an 1130. To the 1130, they are all level 1 cycle steal requests, but the 1133 box will prioritize and subdivide the level among all the controllers that are implemented in the 1133. 

For convenience when I first designed the cycle steal core loader, I chose cycle steal level 0 for loading memory since I required the system to be quiesced (stopped and not actively performing input-output). I didn't realize that the disk controller logic would step on the memory address bus when it saw CS level 0 go active.

I also picked level 0 because the 1130 has logic to latch the data value on the input-output bus into the System Buffer Register near the end of the read part of a cycle steal memory access, in support of the disk drive controller. This signal is produced if we are in CS Level 0, at clock step X3 and the disk controller has activated the File Entry Gate used to cause data read from the disk to be written into core storage. My loader raised the File Entry Gate signal and requested a cycle steal on level 0. The existing logic did the rest. 

That won't work because the disk controller interferes with my loader. I had to move to another cycle steal level. Levels 2 and 3 are used by the 1132 and the 2501 controller logic respectively, both of which might create the same kind of interference when they see 'their' cycle steal level is active. This left level 1. 

So far I have never seen an 1133 expansion box although one museum in Europe at least owns one. None are connected to running 1130 systems. The same is true for the 2250 graphics terminal - don't encounter them and not aware of any in operation with an 1130. Level 1 it is then. 

The 1132 printer only reads data from core memory, never write into it, so it doe snot have to latch data into the SBR. The 2501 card reader has its own logic such that when cycle steal level 3 is active at clock step X3, it triggers the same latching of the I/O bus to the SBR. 

There is no logic inside the 1130 to produce the same signal for latching data when using cycle steal level 1. The 1133 expansion box or 2250 graphics terminal controller accomplish this, raising a signal only at clock step X3 but not automatically when level 1 is active.

SPARE CARD SLOT, 0000 CARD INSERTED AND GATE WIRED INTO THE 1130

The compartment where I connect the control signals between my loader and the 1130, gate B compartment A1, has a few unused card slots. B7 did not have any traces connected to its pins, other than the usual power rails. I grabbed an 0000 card and stuck it into the slot. This provides a number of the basic NAND gate used widely in the 1130. 

I used wire-wrap to connect the +CS Level 1 signal from one card and the +X3 signal from another card to my addition in B7. The output of that NAND gate was wired to the other sources that produce -I/O Entry Sample signal, such as the ones I mentioned for 2501 and disk drive controllers. Thus, whenever level 1 is active it will always write the contents of the input-output bus to core memory. Clearly if a 2250 or 1133 are part of the system, this won't work. 

Violet wire wrap connects gate in slot B7

REWIRED MY CORE LOADER TO REQUEST CS LEVEL 1 AND WATCH FOR THAT LEVEL

I just replaced the wire-wrap connections and now my loader will exploit level 1 for its core memory access. I was able to put the disk drive controller cards back into F6 and G6, yet retain full functionality for the loader. 

LOADED AND RAN CPU DIAGNOSTICS

The CPU diagnostics program would normally be loaded a couple of card decks through the card reader. The basic loader would load the CPU Function Test, which would halt at address 0120 with 3000 in the SBR. 

Instead I used the loader to place the code into memory, then set the Instruction Address Register (IAR) to 0120 where it would have been waiting if loaded via cards. The loader put this code into memory in less than a minute - about 4K words of code and data. 

The Console Entry Switches (CES) are used initially. With the CES at FFFF, pushing Prog Start made it wait with 3001 in SBR. Turning CES to 0000 and pushing Prog Start took the program to a wait with 3002 in the SBR. 

At this point, the CES can be set to various options but we wanted 0000 to run the full normal suite of tests. After pushing Prog Start, the tests will run for about two minutes then end with 3002 in the SBR. Any other wait in the SBR (3xxx) indicates a specific failure xxx in the tests. 

The program ran about a minute and then stopped with a parity error. It was the end of my time in the workshop for the day so I will rerun and debug any issues I find. Once this completes successfully we know that the entire CPU portion is working flawlessly. 

CPU function test running

Printer spacing issue little bit of further testing

LOOKING FOR CAUSE OF LOW PULLUP OF -LINE SPACE LATCH AND FAILURE TO RESET

Yellow trace is the -Carriage CB which pulses as the carriage reaches the next vertical position where a print line would be placed. This pulse should cause the line space latch to reset. The green trace is +Line Sp Latch which goes down about one volt during the CB pulse then returns to full on. The purple trace is the -Line Sp Latch signal which is trying to pull up which is the action that will drop the latch. It only reaches about .5 V before falling back to zero when the CB pulse ends. 

TESTING BEHAVIOR OF THE 6250 CARD THAT PROVIDES THE PULLUP

While I don't have any schematics for the 6250 card, I do know the use of the pins on the card and the role in plays at various points in the printer controller logic. Three pins are pullup functions and hopefully the one I suspect will behave differently from the other two. If so, I can then trace out just the wiring of this pin and look for a bad component. 

CARD BEHAVED JUST FINE, NOT THE CULPRIT

All three pullup pins, B05, D05 and B10, deliver +6V as a pullup. The diode oriented circuits that these signals feed are actually insensitive to logic high input voltage. Thus, while +3 is the nominal logic high level, it can be 6, 9, 12 or more, up to the breakdown specs of the diodes involved. All that matters to those inputs is whether they are pulled down to ground through the diode, not whether there is a high voltage; even an open circuit is logic high to those gates. 

I used a debounced pushbutton on my digital testbench to pull the pin down to ground and watched the signals. All three pullup pins behaved exactly the same. I put a 5K resistor in series with the pushbutton, which caused all three to still work fine although the voltage was a bit above 0 due to the voltage drop of the resistor. 

I have swapped every other card involved in the circuit and this card only participates as a pullup. Not a problem on any card. All pins involved in the logic net have infinite resistance to +3, +6, -3 and ground power rails. 

There must be a hidden connection to some other net that is pulling this down to ground. I will have to keep probing.  

Printer controller debugging continues

LINE SPACE LATCH SHOULD RESET WHEN CARRIAGE MOVES ONE LINE

The line space latch will unlatch when the carriage of the printer reaches the next line location. The printer produces a 5ms pulse once per rotation of a gear which moves the paper up the distance between printed lines. This pulse should reset the line space latch, which would remain in the off condition until it is activated by execution of an XIO Control command to the printer with the bit set to space one line. 

One the scope, I can see the pulse from the printer (-carriage CB) and the latch attempt to reset. The +Latch line lowers partly but does not go all the way to logic low. The -Latch line increases a bit but does not get up to a good logic high condition. Thus, there is a brief attempt to reset but the latch stays active.

It appears that something is keeping the -Latch line from pulling up to a sufficient voltage to switch off the latch. I then spent the afternoon chasing down possible culprits, but to no avail.

CHECKING NETS FOR CONTINUITY, SHORTS

I removed all the cards connected to the -latch line and confirmed it had good connectivity between its pins but no connection to any power rail or ground. The net connects pins on B2, B3, E3, D3 and J2 card slots. The pin on J2 is labeled 'resistor' which I expect means it is the pullup resistor for the line. If that failed it would certainly cause issues with the latch operation.

LIMITED SCHEMATICS, MISSING ONE CARD TYPE

The cards in those slots are 0000, 3130, and 6250 types. I don't have any schematics for the 6250, which is the most likely to be causing the issue of course. The card provides debouncers for eleven sets of contacts,  three pull up resistors for nets, an OR gate to signal if any one of the carriage control brushes made contact, and a pulse generator to emit a signal when the print disc slot passes a photocell. 

The print disc slot pulse means that a new character is coming up on the spinning print wheels - thus the CPU is interrupted so that the program can issue an XIO Read to see the character code on the disc. This code indicates which of the 48 characters is next. 

The card has six SLT modules, 13 tantalum capacitors, other capacitor and resistor modules, plus a discrete resistor and 6.8uf capacitor. I will try to figure out how I can test the pullup resistor circuit to assess its functionality. Since there are three such circuits, comparing them might turn up a significant difference. 

REASONS I DOUBT THE 0000 AND 3130 CARDS ARE KEEPING THE LATCH LOW

I have several of each type and swapped them with others. No change to the symptoms. Also, looking at the schematics, both of these card types have diodes isolating the inputs making it unlikely they could pull the line down. 

0000 card circuit of one gate

3130 card circuit of one latch

Believe I have a rework possible on the existing PCB for the loader

DISCOVERED FLAW THAT KEEPS THE CS REQUEST AND OTHER SIGNALS ACTIVE

The design is non-clocked, consistent with the non-clocked design of the IBM 1130. This avoids the requirement to synchronize across clock domains or deal with metastability issues. Four flip-flops establish the state machine for the logic. 

Although these are modern clocked flipflops, the clock is actually the signal from the 1130. For example, when the X6 clock state occurs, the rising edge of that signal becomes the clock to cause one of the flipflops to set its state to 1. A reset signal resets the state machine when a request from the Arduino has been finished - after the state machine raises a 'done' flag, the Arduino drops its request and we reset all the flipflops to the idle state. 

Our first flipflop is set from the rising edge of the Arduino request signal. It then conditions the second flipflop which will be set by the rising edge of the X6 clock state. Each cycle steal is accomplished with eight 450 ns clock states X0 to X7. 

The second flipflop conditioned the third flipflop to be set by the dropping of the CS Level 0 signal from the CPU, which occurs at the end of a cycle steal memory access. The third flipflop conditions the fourth, which is then set when the Arduino request falls. The setting of the fourth flipflop causes a reset of all four flipflops to their idle state. 

When the first flipflop is set I had raised the signals to the 1130 requesting the cycle steal as well as passing along the data and address for the word. Unfortunately, it was not dropped when it should have been. The signal should drop once the second flipflop is activated by the X6 clock state. 

HACK FOUND TO KEEP EXISTING SHIELD WITH MODEST REWORK APPLIED

I had six spare gates on the board, three inverters and three open collector buffers, parts of hex gate chips that weren't fully utilized. I found a way to use two of the open collector buffers to form an AND logic gate since the correct condition for asserting the cycle steal request, address and data is that we have requested a cycle but not yet reached X6. That is, flipflop one is on and flipflop two is off. 

The line to send signals to the 1130 is pulled up to +5 by a new resistor I will add to the board. Two open collector buffer gates are connected to this line as well. If either or both of them pull down the line, it is logic low and we don't assert signals to the 1130. Only when both of the are at logic high do we want signals passed along. 

Thus, one open collector is hooked to the Q output of the first flipflop, so that it does not pull down the common output line if Q is logic high. The other open collector buffer is hooked to the notQ output of the second flipflop, so that it does not pull down the common output line if the second flipflop is not yet set. 

Once the X6 signal arrives and sets the second flipflop, our common output goes low and we have isolated the 1130 from the board. In the idle condition, with the first flipflop inactive, the common output is still pulled low. 

Simplified section of schematic

The simplified extract above shows the use of signals to act as the 'clock' of the flipflops. The green circle shows the new components (actually just using two formerly spare gates). The red circle is where the control line previously ran to drive signals out to the 1130, and the red wire is the replacement connection. 

I will have to cut traces where I applied VCC to the inputs of the unused gates. I will have to cut the line that previously drove the output signals, instead hooking on a pullup resistor to VCC. Finally, I will have to connect the inputs and outputs of the two open collector gates appropriately. 

It is possible that one or more lines that I need to cut are underneath a chip, in which case I have to remove it temporarily to change the traces. 

Found another broken trace on A A1 backplane

TRACING THE RESET SIGNAL THAT STARTS 1132 LOGIC OUT IN KNOWN STATE

The 1130 has a master reset line that initializes all the stateful parts of the machine. That line is held in reset (logic low) for about 6 or 7 seconds during power up, but it can also be set to logic low when pressing the Reset button on the console. 

Since the 1132 has some status that seems illogical involving several latches, one avenue I explored was the possibility that the latches were not initialized properly by the master reset. I traced the net between all the pins that received the master reset signal and discovered that a pin on a card in the B column of the backplane was not connected to the reset nor to the other pins that are fed by the reset. 

I resolved this with a wirewrap connection. I remembered that I had found and fixed another trace failure in a card in column B in the last few days. The backplane may have suffered some trauma that caused traces to sever, either the trace itself disrupted by a crack in the glass substrate or a failure of the connection between trace and pin. A crack is more likely if the problems appear localized to the right edge of the backplane as viewed from the wirewrap side, but are in several nets. 

I suspect that I will need to develop a full net connection list for this side of the backplane and test out all the connections with a VOM, rather than hoping to find each failed trace through debugging. 

Debugging Cycle Steal (DMA) core memory loader

THE CPU STOP SIGNAL DID NOT DO WHAT I EXPECTED

I was watching the +Cpu Stop signal in order to block my loader if the processor was active running instructions or doing input output with peripherals. However, when I looked at the signal, it did not really do what I expected. 

When the machine initially powers up, it is not running, but the stop latch is not set! The latch is set by two conditions - when a parity check occurs and when the user pushes the Imm Stop button. However, the button press only activates the stop latch if the CPU was actually running, otherwise it does NOT turn on the stop latch. 

I then moved on to a signal generated by the Run logic of the machine, which at first blush seemed good until I noticed small pulses on every clock cycle, not really turning on the Run signal but the pulse was big enough to trigger my loader logic.

The reason for those is a known quirky behavior of the flip flop circuit from IBM SLT technology. Essentially it has a set and a reset input and offers two outputs. One is logic high when the flip flop is set (called Q in modern flipflops) and the other output is logic high when the flip flop is not set (not Q). 

The flip flop is generally turned on or turned off by a pulse on the set or reset input. However, if the flipflop is in the off state and a reset pulse arrives, the flipflop emits a small pulse on the Q output. The flipflop was at logic low, since it was in the off condition, and it doesn't change its Q or notQ outputs, but there is this glitch pulse that looks like a very brief logic high. 

The same quirk exists when the flipflop is on (Q is logic high and not Q is logic low). If a set pulse arrives, the flip flop will emit a brief logic high pulse on the not Q output but long term not Q remains low. 

IBM protects against this by placing AND gates in front of the set and reset inputs, with one signal to the AND gate coming from the Q or not Q output. Thus, if already set, no additional set pulse gets through. If not set, no additional reset pulse gets through. 

However, sometimes they don't put the protective gates in front. The Run flipflop is a case in point, where the reset input is not protected by an AND gate. A number of conditions can stop the processor, such as the end of an instruction if in single instruction mode, or the end of a memory cycle in single memory cycle mode. If the processor has executed a wait instruction or was stopped by the Imm Stop button, it will also reset the Run flipflop. 

All of these conditions are tied together (a wired OR gate) to reset the flipflop. In addition, other outputs are wired together to the Q output. One of them produces very  short pulses - glitches. This is why that signal is unsuitable for my loader to monitor.

I did find another related signal that does track logically with the running or stopped state of the 1130. I changed the wire wrap to my B1 header block to bring that to the core loader. 

SCOPE SIGNALS FOLLOWED THE STATE MACHINE AND 1130 CYCLE STEAL

The data values I typed into the loader were displayed on the Storage Buffer Register and when I displayed those locations, the data I had loaded was there. However, I noticed that the RUN lamp lights and does not go out. 

The scope showed me that I was continuing to hold up the Cycle Steal request line, so that the processor was repeatedly providing cycle steal memory accesses. I expected to see the request dropped once we were sure we had been granted a cycle steal access, but that didn't occur. I suspect a flaw in my logic board (shield) and will dig into the design at home tonight. 

Yellow - request, green - granted, purple - X6 cycle

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. 

Finished wiring header blocks and verified operation of address and data connections

DATA CONNECTIONS FINISH THE HEADER BLOCK TO BACKPLANE CONNECTIONS

I used the wire wrap tool to link all 16 bit positions of the shared input-output device data bus up to the left side of the B1 header block. I then verified that there were no shorts to adjacent pins either on the header block or down on the card slot backplane pins. 

VERIFIED THAT DATA AND ADDRESS ARE INJECTED TO THE CPU

The connections for both address and data are inverted logic, thus pulling one of the pins to ground will assert that the associated bit position is 1. The nature of SLT gates allows me to pull them down as what IBM calls a wired-OR gate. With traditional digital electronics, I would have had to break the connection between the 1130 gate and its next destination, then wire those up to a new OR gate that will isolate the original 1130 gate and my new input. Fortunately this is not needed with the Diode Transistor Logic used in SLT.

The pins I connected to on the backplane for data are part of a wired-OR shared bus, the Input-Output bus. Every peripheral device is wired to this bus and will introduce any data that should be passed inbound to the 1130. Other devices on this bus include the 16 Console Entry Switches (CES) on the front of the console printer. 

When the 1130 is switched to Load mode, it routes the CES to the input-output bus. Any CES that is turned to 1 will pull down its bit position on the bus, but if the CES is turned to 0, it does nothing. Then when the Prog Start button is pushed, a memory cycle is triggered to load the input-output bus contents (usually the CES) to a core memory location. 

I left all the CES down, set to 0, thus none of them were pulling the input-output bus down. I then hooked a jumper to each of the 16 data positions on header B1 and the other end to ground. I hooked up to each position and observed the proper light illuminate on the Storage Buffer Register which reflects the bus when in Load mode. 

Next, I used Load mode to set the IAR to every address with just one address bit at 1 - 1000, 0800, 0400, etc. I stored the same value as the address in its location. Thus, if I were to load the IAR to address 0020, for example, in Display mode and push Prog Start, it would read 0020 and display the value therein which is 0020 due to my setup. 

That allowed me to test my address bits on the B1 header. I would connect a jumper between ground and each address pin, in turn, then push Reset and Prog Start while in Display mode. This caused the 1130 to take a memory cycle and display the contents of memory in the SBR. Each pin caused the machine to show an SBR value that matched my address jumper, proving that each address bit was working appropriately.

Wiring up the header blocks for my Cycle Steal Memory Loader

LATEST VERSION OF MY LOADER WHICH PUTS FILES FROM A PC/MAC INTO CORE

Earlier versions would toggle switches and push buttons virtually to match the actions of a human operator using Load mode of the 1130. This however was slow mainly due to the debouncing interval for the buttons. 

I redesigned the loader to use cycle steal, which will trigger a core memory cycle to read or write a specific address. This will be much faster, allowing even the largest programs to be loaded into memory in almost no time compared to the hour or more with the prior loader. 

CYCLE STEAL - DMA BY ANY OTHER NAME

Modern computers allow faster peripherals to transfer data to memory without requiring the processor to explicitly read the data and write it to memory. Instead, a mode called Direct Memory Access (DMA) allows a peripheral to request access to memory, transferring data without passing through the CPU. This means the CPU does not need to take interrupts or waste instructions moving the data. 

IBM calls this technique Cycle Steal when they developed it for computers in the fifties and sixties. Since mainframes of those eras are built around core memory, the heart of their structure involves memory access cycles. I will use the 1130 as a more concrete example.

The processor takes a memory cycle called I1 to fetch the contents of a memory location which becomes the new instruction it will execute. If the instruction has the bit on indicating a long format, then the instruction is two words long; the machine takes another memory cycle called I2 to retrieve that. 

Instructions that make use of an index register must take another memory cycle called IX to read and sometimes write the memory location for the index register (addresses 0001, 0002 and 0003 are the three index registers). 

Indirect addressing is indicated by another bit in the first instruction word, which requires the processor to gain grab the contents of memory with an IA cycle. That is when the calculated target address of the instruction is just a memory location which has the true intended address inside it. 

Performing the purpose of the instruction can involve additional memory cycles, up to three, which are the E1, E2 and E3 cycles. Thus, a long, indexed, indirect instruction could take up to seven memory cycles to complete. A memory cycle is therefore the atomic operation of the 1130. 

Cycle stealing blocks the processor from making a memory cycle, instead allowing a peripheral to have one memory access cycle. These can occur between any sets of other cycles. An instruction might have completed its I1 but then a cycle steal uses the memory before the processor resumes taking its IX cycle. The processor and software is not aware that cycles are stolen, the only evidence is elongation of the time it takes to execute software because of the 3.6 us it takes for a memory cycle. 

Fast peripherals raise a flag requesting a cycle steal. As soon as the current memory cycle completes, the requester is given the memory to read and rewrite one address. For example, disk drive uses cycle steal to transfer 320 words between disk and memory, slipping the memory cycles in between instruction oriented cycles as needed. 

There are several levels of cycle steal, with higher priority levels given access to memory first before lower priority requesters. When no cycle steal request is present, the CPU resumes executing instructions. 

My new loader has some circuitry attached to an Arduino. Using the USB cable to open a serial connection with a PC, terminal or Mac, the software in the Arduino requests cycle steals. The loader requires that the processor be stopped before it will perform cycle steals, which eliminates the need to worry about priorities among cycle steal requesting peripherals. 

The loader raises the request for a cycle steal on level 0. When it sees that the processor has given control of memory to cycle stealing (a CS Level 0 signal becomes true), it sets up the address and data on the same buses that other peripherals use, then at appropriate steps during the memory cycle it activates the File Entry Gate signal so that the memory will write the data we injected. As we see the cycle near completion, we drop the signals and wait to see the CS Level 0 end. 

The memory cycle time is 3.6 microseconds, which is how long it takes to load one word of core memory. The Arduino then has to accept the next line of input over the serial connection to request the next transfer. The Arduino processing and serial line time is much bigger than the cycle steal time, thus that becomes the pacing element in how fast we can load core memory using this technique.

HEADER BLOCKS INTERFACE ARDUINO TO BACKPLANE PINS

I created small header blocks that are fastened above the compartments A1 and B1 of the B gate. Wire wrap is used to connect a pin from the backplane to a pin on the header block. Thus for compartment B1, we connect address bits 1 to 15, data bits 0 to 15, and File Entry Gate signal to the header block. For compartment A1, a small number of control signals such as CS Level 0 Request and CS Level 0 active are connected to the smaller header block above the backplane. 

These header blocks also attach ribbon cables which connect those signals to the shield that is fitted atop the Arduino. The Arduino stack is mounted inside the machine as well, with the USB cable routed out of the back of the machine for attachment when loading contents into memory. 

WIRING PARTLY DONE TO THE HEADER BLOCKS

I used my wire-wrap tool and appropriate wire to connect each pin of the header block to its assigned pin on the backplane. I wanted this as neat as possible, which means fairly close to the shortest distance but without any strain on the wire. 

I completed the wiring to the A1 header block and did half of the B1 header block. The sixteen data bits are still to be wired, then it will be done.