1052 Console Printer restoration completed, reinstalling on the 1130

FINAL RESTORATION REPAIRS AND ADJUSTMENTS FOR THE TYPEWRITER

I worked for several hours to clean up all the outstanding issues with the Selectric typewriter based Console Printer. It was on the bench, but I wired up AC to the motor so that I could test both by hand and under power. 

The Space pushbutton was not reliably tripping the operational cam. I removed part of the plate in front of the levers and screwed in the standoff that positions the lever so that it now cleanly strikes the cam trigger. 

The tab setting sliders for each column were in many cases still too sticky to move easily when setting or clearing a tab stop at that column, I flooded them all with my super light oil and worked every column until they were all sliding well between the two positions. 

The mainspring did not have enough tension to maintain decent speed when the tab movement reached the columns on the right. I added a couple of turns of tension. 

The shift mechanism that rotates the typeball between the upper case and lower case hemispheres was sticking in upper case even when the solenoids had released the control lever. This lever has a spring that should have snapped it back immediately but something was binding. I lubricated the hinge points where the control lever pivoted, working it back and forth, until I was satisfied that it would jump back as soon as it was released. 

I checked all the rotate and tilt settings, finding them all spot on. This typewriter was very well cared for and properly adjusted, making its restoration much easier than some where I have received mechanisms in terrible condition and maladjustment. 

The print shaft timing needed to be set because I had to release the gear in order to work the print mechanism when I first flushed out the glue-like stale lubricant which left it frozen in place. The procedure is straightforward and I followed it. I installed a half-cycle tool on the machine which will stop the print mechanism at the halfway point through a print operation. 

First the gear is loosened so the print shaft wont turn. Setting up a specific requested character with the selection solenoids, I brought the typehead to its latched position ready to strike forward. I then hand rotated the print shaft until the detent that selects the rotate position was halfway out of the tooth on the typeball. The half-cycle tool was removed and I moved that part of the mechanism forward until the detent just strikes the bottom tip of the tooth. That is where I tightened down the print gear.

I hand selected and half-cycled various rotate positions, verifying that the ball was locked in the proper position and was rotated appropriately if the detent was released. I then turned on the motor and tried various characters, particularly the extremes of +5 and -5 whose proper operation depends on a slew of prior adjustments (which all seemed correct). The correct character was typed in all cases.

I installed a new-old-stock bicolor ribbon (red along the top and black along the bottom). I then adjusted the ribbon shift mechanism until by selecting the proper solenoid, the letters were typed in black or in red. 

I installed the plastic shields that protect the mechanisms inside the Selectric from falling debris - typically that would be paper clips, hair clips and other office materials in the office setting for which the typewriter was designed. 

Finally, I reinstalled the cover over the typewriter mechanism, connecting up the forms check microswitch which detects whether paper is feeding into the typewriter. There is a faceplate that is connected to the 1130 logic but has to be attached to the front of the typewriter. It has the plastic buttons for Tab, Space and Return that push the metal buttons on the typewriter. It has a window which shows the current column position of the carrier and the positions of the left and right margins. On the plate is a rocker which can be moved to set or clear the tab stop at the current column. Unrelated to the typewriter, it also holds the sixteen console entry switches that are another peripheral device used by the 1130. 

TYPEWRITER PUT ON THE MACHINE AND CABLES ROUTED DOWN BELOW

The typewriter was placed on its mounting point just in front of the keyboard and underneath the display light panel. The platen and faceplate are not yet installed on the typewriter, because I ran out of time in the shop today. 

The console printer has two SMS paddle cards which route signals between the 1130 and the 1052 typewriter, plus an SMS power paddle card that provides the 115VAC for the motor, +48V for the solenoids and +12V for the feedback microswitch circuits. I have the two signal cards installed but have not yet plugged in the power card. 

The faceplate will be attached to the typewriter after carefully connecting a tie-rod that connects the tab set/clear rocker with the actual tab mechanism at the left rear of the typewriter. 

I am feeling confident enough in the typewriter that I will move directly onto running the 1132 printer diagnostic which I had loaded into core earlier. Alternatively I could have run a hand loop first, and then loaded the 1052 diagnostic to test the typewriter fully. 

MODIFIED THE ARDUINO, ASSEMBLED THE MEMORY LOADER STACK AND TESTED

I took the Arduino Mega 2560 that I had loaded with the code for the DMA/Cycle Steal loader and prepared it for 1130 use. First, I removed a power pass transistor that powers the whole board with USB power if the main power connection is not active. I only want the board to power up when the 1130 is powered on. Second, I installed a 10uF capacitor between the Reset and Ground pins of the Arduino which block it from resetting the code when a serial connection is opened over USB. 

With the shield plugged onto the Arduino, I brought it over and connected the cables from the 1130 to this instead of the board I had tested yesterday. I used it to successfully load memory with code including the 1132 diagnostic I will use tomorrow. The stack was then unplugged and the original stack returned to service. This new stack is now ready to go to the System Source Museum where I can install the header blocks, link them to the 1130 backplane with wire-wrap, provide 12V from the 1130 to the shield, route a long USB cable to outside of the 1130 cabinet, install the three ribbon cables, and physically secure the stack in place on the machine. 

Diagnostic monitor requires console printer; pivoting to restoration of the 1052

STUDYING THE DIAGNOSTIC MONITOR TO LEARN I MUST GET TYPEWRITER WORKING

Many of the diagnostics for the 1130 system are designed to run under the Diagnostic Monitor II program, which provides services such as interrupt handlers, console printer and keyboard interface and run controls. The monitor is loaded first, then one or multiple diagnostics are loaded by the monitor before they are run. 

The design of the monitor produces typed output when a test starts, when it ends, and as errors are uncovered. It also emits output when options are changed via the console entry switches, or when the monitor restarts. There are some options to skip certain of the messages, such as startup of a diagnostic or errors, but others can't be blocked. 

Rather than rewriting the monitor, I will turn my attention to the console printer, because if I can get the restoration finished and the printer back on the machine, I can run the diagnostics I need to debug the rest of the peripherals. 

Ran CPU and 1132 printer diagnostics; built another loader to install on SSM machine

LOADED CPU DIAGNOSTICS AGAIN AND RAN IT

It flew right through them and ended with the wait instruction, SBR with 3003 displayed, which means that it ran completely successfully.

LOADED 1132 DIAGNOSTICS, HOOKED UP PRINTER, AND TESTED

The only issue I expected to impact my testing of the 1132 is that I can't find my carriage control tapes, nor the punch that puts holes in them. The tests expect a certain pattern of channel punches on the tape as it tests the machines functionality. However, it can work fine without the tape, I think, which the printer will interpret as a tape with all holes punched on every line. 

I cabled up the printer again and loaded a box of paper since the testing will chew through a number of pages. With everything ready, I loaded the diagnostic program and began testing.

1132 DIAGNOSTIC TEST ISSUE

The diagnostic program kept stopping with errors indicating that the console printer (typewriter) was busy too long, which is because the printer is not installed yet. I tried for about an hour to patch around it but the diagnostic monitor that hosts the diagnostic insists on documenting actions on the printer. 

BUILT ANOTHER CYCLE STEAL/DMA LOADER - TO INSTALL ON THE SSM 1130

I broke out the soldering station and put together a second loader. I brought an Arduino Mega home to load the firmware, so that when I get back to the shop I can modify the microcontroller for use in the 1130. I remove the pass transistor that allows the USB to power the board, forcing it to only power on with the IBM 1130 itself. I also install a capacitor on the reset line so that a new serial connection over USB will NOT restart the Arduino firmware, which starts once at power up. 

Tested cycle steal/DMA memory loader and used it to run some diagnostics

CHECKED WIRING TO BACKPLANE FOR THE MODIFIED MEMORY LOADER

Since this loader uses Cycle Steal Level 1 now, rather than level 0 as the earlier version did, it has to be wired to the appropriate pins on the backplane for this. Also, during my prototype testing I used a spare card slot for a gate but the logic is now onboard my shield, thus some wirewrap changes for that. 

TESTED THE LOADER

The loader worked perfectly. I can commit this plan on Github as a finished and ready to copy design. It is now in place inside the machine ready to be used whenever I have something to load into memory. Below is a video of the loader installing some contents into memory.

LOADED CORE MEMORY DIAGNOSTICS AND RAN THEM

I had the high core memory diagnostics - different from low core in that it doesn't test the first 512 words where the diagnostic program itself will sit. There is another version that is loaded high and is therefore called the low core test, but both of them test all but 512 words of the 8K. 

The program ran to successful completion, stopping on a wait instruction with 3002 in the Storage Buffer Register. That was good enough for me, I don't need to load and run the low core version since I have been using low core with everything I have run lately.

LOADED MY DEMONSTRATION MONITOR AND RAN A FEW DEMOS

The demonstration monitor was written for the System Source Museum in Baltimore to show off their 1130 as they don't have the peripherals to use it in the conventional way. Some routines make use of the console printer, which is not yet reconnected to the VCF 1130 so they won't run. However, I wrote a few that could be used when the typewriter was down. 

I ran one demonstration that performs millions of multiplications to demonstrate the speed of the 1130 for doing compute tasks. Another calculated the digits of Pi and displayed them in the ACC register, waiting after each digit for the user to read the value and push Prog Start to get the next. The final demo I tried allowed the user to type in a numeric value on the keyboard and translated it into binary in the ACC register. 

Finished assembly of loader and installed it on the IBM 1130

CONNECTORS INSTALLED AND BENCH CHECKED

After I soldered on the connectors, it was time to closely examine solder joints and then test continuity of every signal net. I used the schematics to beep out connections from every pin of each IC, as well as from the external connectors and the Arduino connectors. All was correct.

STARTUP CAPACITOR ADDED AND LOADER INSTALLED ON THE 1130

A capacitor between the Reset and Ground pins on the Arduino blocks the reset pulse so that the microcontroller does NOT restart when a serial connection is made from a PC/Mac/terminal, only when the 1130 powers on. 

I swapped this shield for the older prototype shield and connected it to the 1130 - three cables, two power leads and the USB cable are hooked to the sandwich. I modified my ideas for physically mounting the sandwich which will give it a lower profile when sitting atop logic gate B, on the side where the SLT cards are inserted. 

Part of the prototype testing, besides many bodge wires, was the use of a temporary NAND gate which I implemented putting a spare 0000 card in slot B7 and using wire-wrap. That logic is now onboard the shield, which allowed me to unwire and remove the SLT card. 

Finished ICs and discrete components on DMA/Cycle Steal memory loader

FOUR CHIPS SOLDERED TO REAR OF BOARD

The last four ICs - 74LS03 open collector gates - were soldered onto the board. These plus the four similar chips on the front of the board are the drivers of the 16 data lines, 15 address lines and the I/O Entry Sample signal that are connected to the IBM 1130. 

The remaining chips on the board are the state machine logic, a driver to request the cycle steal from the 1130, and interfaces that watch 1130 signals such as X6, Run and Cycle Steal Level 1. 

DISCRETE CAPACITORS AND RESISTORS SOLDERED ONTO THE BOARD

Two pullup resistors are used to construct three and gates from spare open collector buffer gates, rather than installing an additional IC to implement the gates. Thus, the output is high when both inputs are high, pulled up by the resistor, but if either input is low the open collector gate will pull the output down to ground. A third pullup is used with an open collector nand gate to convert it to normal gate operation.

Decoupling capacitors are installed near every IC, plus filtering capacitors were used on the two voltage regulator chips. 

THE ONLY REMAINING COMPONENTS ARE CONNECTORS

Most connectors are standard 2.54 mm spacing header strips, used for my cables to the 1130 as well as to connect this shield to the Arduino Mega 2560, but there is one screw terminal connector where the +12V and ground from the IBM 1130 is delivered. 

Managed to get a couple of hours in the workshop today - soldered all the front side ICs on the loader PCB

ALL FRONT SIDE INTEGRATED CIRCUITS INSTALLED

I installed the two power regulator chips and ten logic integrated circuits on the front side of the PCB. 

FOUR MORE ICS TO INSTALL ON THE BACKSIDE THEN CAPACITORS/RESISTORS

The rear side has four more 74LS03 chips to install, then I am ready for the discrete components. Twenty capacitors, most of them for decoupling, plus three pullup resistors. After that, I only have connectors to install before the board is ready to test and use. 

New PCBs arrived for cycle steal (DMA) memory loader - will build and test when I get to the shop next

MY HOPEFULLY FINAL DESIGN OF THE MEMORY LOADER PCBS ARRIVED

This consists of one board that will be a shield placed on an Arduino Mega 2560 plus a long thin board that breaks in two to become the two header blocks where wire-wrap lines from the 1130 backplane come to a connector. 

Header blocks (separated in this picture)

Once I solder the parts on the board, I will install it on the VCF 1130 to test out the new board which replaces all the bodge wires and changes of the previous version. My wife had hip replacement surgery yesterday which will keep me out of the shop for a bit while she convalesces. 

x

Noodling over ideas for how to simulate a 2501 card reader in order to test the controller logic

NORMALLY I APPROACH TIMING EXACT EMULATION USING FPGA

My general approach to emulating machinery that has lots of specific timing with multiple independently operating bits is to use an FPGA as I can guarantee that timing pulses from one part will occur exactly as they should regardless of how many other things I have to emulate for the device. 

However, the effort and time to build and debug the FPGA logic is higher than the effort to whip up some Arduino or Raspberry Pi based device. Since this emulation is going to be used to check out the VCF 1130 controller logic for the 2501 card reader, I need it relatively quickly. However, there is some value in the work as I could mate this to a USB drive reader or even a physical Documation card reader to give an 1130 system a 2501 card reader. 

FIGURED OUT AN APPROACH USING DUAL ARDUINO BOARDS

For simplicity of development and testing, I chose to place the hardware emulation that is timing specific in an Arduino Mega that has nothing else to do, with a second responsible for setting up the card images and managing all the other parts of the 2501 emulation.

The first unit will use the timer interrupts available in the AVR microprocessor on the Arduino. Thus, when the motor is turned on by the controller logic (via signal -motor relay) I start a counter using 250 microsecond timer pops. This is used to generate the three feed 'CB' pulses that tell the controller where the 2501 mechanism is while it rotates. Thus I emit a 2 ms long pulse at 5 ms, at 72.5 ms and again at 93 ms within a 100 ms rotation of the mechanism. These are Feed CB1, Feed CB2 and Feed CB3 signals. 

When the -motor relay signal goes off, the pulses stop by turning off the interrupt handler. This reflects the card reader sitting idly without the motor running until it is needed for a read, feed or NPRO operation 

When a card is being read, there is additional strict timing which I also drive with that 250 us timer. A second counter starts when the controller turns on the -record emitter signal. This records magnetic pulses on a rotating wheel that will generate pulses every 500 us which is the rate at which the punched card moves one column as it moves through the machine at its 600 cpm speed.  

My counter updates twice as fast, which means I can use the odd steps to change the photocell values that represent light passing through or blocked by a hole in the column for each of the 12 rows on a card. On the even step, I fire off a second time for 55 us that is the duration of the emitter pulse. 

The controller logic latches in the rows for which the light is observed at the start of that 55 us pulse and then at the end of the pulse it compares the latched value to the light it is now observing. This is the error checking as if it changes then the emitted pulse is not right in the middle of a card column and we have a read error of some kind. Thus I change the photocells on odd 250 us steps and emit the 55 us pulse only at the start of the even step. 

My timing specific Arduino will not handle the photocell values, however, that will be done by the second Arduino Mega. The first unit simply sends a bit to inform the second Arduino when it has come to an odd step of the column counter. The second Arduino sees those pulses and changes the photocell values. The second box also handles the Start, Stop and NPRO key emulation, the hopper empty detection, the pre-read sensor that informs the controller when the card is in position to begin reading, the Attention error light, the Ready light and other details related to the emulation. 

Powered up 1442 card reader and did some debugging the controller logic

MY 1442 CARD READER/PUNCH WAS NOT FULLY OPERATIONAL 

I had an issue with the punch, which I will repair with a replacement punch unit given to me by a very kind organization last year. In addition, the clutch and moving parts are still a bit sludgy with old lubricants and don't move crisply enough. I was not able to read more than one card before errors were detected because the card wasn't moving fast enough. 

Still, it was useful enough that I cabled it up to the VCF 1130 to test the controller logic cards. I had inserted all the cards that I identified as belonging to the 1442. 

BEGINS NPRO BUT DOES NOT STOP

Non-process runout (NPRO) is the IBM term for clearing cards out of a machine. Feed cycles are taken continuously while the button is pressed down. When I pushed the NPRO button it began feeding but after I released the button, it did not stop. 

I traced the failure to an inverter that wasn't delivering the feed CB - a magnet spinning on a shaft passes by four coils located around the perimeter of a circle, inducing a pulse that IBM called Feed CB1 through Feed CB4. The NPRO latch will shut off at the next Feed CB1 pulse after the pushbutton is released, but it was not getting the pulse. 

MISSING CARD THAT SITS IN VERY UNUSUAL SPOT IN THE COMPARTMENT

An 0000 card was missing from card slot N4. Below is the view of the A-B1 compartment with the SLT cards inserted for the 1442 device controller logic.

SLT card slots are named by the row and column. You can see card slots 2 through 7, from top to bottom. Spaces 1 and 8 are not long enough for a card; instead they take cable connectors at right angles to the way cards are oriented. You can see columns B to M, from left to right. I inserted cards in rows 2, 3 and 4 across the columns B to M. 

Behind the metal braces on the left and right are columns A (left) and N (right). They are almost always used for cable connections as you can see with the masses of yellow and black wires that are connected in those columns. 

However, IBM chose to put an SLT card in slot N4 instead of a connector. We see another connector plugged into slot M6 here, not on the two edges A and N where the others connect. I not only didn't see the empty slot, I couldn't put an SLT card into the slot or remove it without first detaching the metal brace on the right. 

Brace removed and open slot visible on right

I inserted an 0000 card into that slot between the cable connectors at rows 3 and 5. 

Card in place in N4

Next I reinstalled the metal brace. You can hardly see the card now, with the brace blocking the view. 

Where's Waldo - SLT card edition

MUCH IS WORKING CORRECTLY WITH THE CONTROLLER LOGIC

When I place a card in the hopper and hit the Start button, the logic takes a feed cycle to pull the card inside and leave it in the pre-read station. The next feed cycle will pass the card through the photocells to read the eighty columns as the card goes by. 

Card inside, sitting at the pre-read station

The logic for the 1442 requires that there be another card ready in the input hopper before the machine will assume the Ready state. This supports handling of very long card decks, which won't all fit into the hopper at one time. The operator loads the first part of the deck and reads. 

When the hopper is empty, the reader turns off Ready status, but there is still a card sitting in the pre-read station, as above. Putting in the next part of the deck and pushing Start will continue with reading the deck, giving the software doing the reading no clue that there has been an interruption. 

When finally the last part of the deck was put in the hopper and the last card of the deck is fed into the pre-read station, the machine again drops Ready status. Pushing the Start button without having put any cards into the hopper enables a special mode called Last Card. The reader becomes Ready and when the software reads the card there is a special bit set in the device status word indicating Last Card. 

I pushed the Start button another time and the Ready light turned on, testing that part of the logic. 

The Check and Chip Box lights look illuminated but they are not. At this point the machine is ready to read or feed the card when an XIO Control command is issued. Clutches will activate to move the card from station to station and logic will either activate a read or simply feed (move the card forward). 

Motor, clutches and stations for card movement

READING IS A BIT COMPLEX SO I DIDN'T ATTEMPT IT

Like the 1132 printer we checked earlier, this device is very simply thus putting a heavy load on the CPU and the programmer. To read a card that is sitting in the pre-read station, the program issues an XIO Control with the Start Read bit set on. This begins to feed the card through to the next station (pre-punch). 

As each card column passes through the photocell slot, the controller logic issues an interrupt on level 0, the highest priority interrupt. The interrupt handler software must issue an XIO Read instruction to store the word that contains the 12 rows of holes for this current column, padded with four bits of 0 on the right. This happens eighty times, once per card column, and the read must occur before the card moves to the next column position or data will be lost. 

When the card has finished the eightieth column, the reader requests an interrupt on level 4. This interrupt has a device status word bit that indicates the read has completed. You can think of IL4 as the card and machine level interrupt and IL0 as the column level interrupt. 

As you can see, I would have to write two interrupt handlers, one for each level being used, in order to handle the data from the card once I start the read with XIO Control-Start Read. Since I know that my reader is still sluggish due to old lubricants, I know it can't move the card fast enough. It registers errors in the movement; I could only read one card at best when I last turned this off. It isn't worth the work to try a read when I am fairly sure it will fail anyway. 

It is easier to just request a feed cycle - to move a card from one station to the next. We only get the IL4 interrupt at the end of the move if an error is detected, otherwise it just silently executes the request. I therefore set up an XIO Control with the Start Feed bit on and fired off some movement.

FEED CYCLE ENDS WITH FEED CHECK IN READ STATION

The card did move to the next (pre-punch) station however the machine detected an error in the movement through the read station. This is a consequence of sluggishness, as the machine verifies that the card has passed through the photocells, so that none are dark, when a specific Feed CB is triggered. Our card moved too slowly, partly because our clutch didn't start the movement promptly enough. 

JUST ABOUT DONE WITH WHAT I CAN DO WITH THE 1442

Without the ability to read cards or perform other operations without errors, I really can't exercise all aspects of the controller logic. However, once I discovered the missing card at N4, everything else has worked flawlessly on the controller side. 

I do intend to continue restoring my 1442, repairing the sluggishness and replacing the punch unit so that it could process cards normally. It would divert time from restoring the VCF machine, particularly since the museum does not have a 1442 reader/punch to use with the system. Instead, they have an 1132 printer and the 2501 card reader. 

On a side note, the frustrating finicky incandescent lamps for the 1130 display panel are also used inside the 1442 for a status panel. Many bulbs have had their leads snap off and this is really ready to have the bulbs replaced with the LED bulb substitutes I built. 

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