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