First look at new 1130 system coming in for restoration

INFOAGE MUSEUM (VCF) IBM 1130 FOR RESTORATION

The machine was dropped off and I began an initial assessment to identify areas for early intervention. Overall appearance is good for its age. A few signs of rust especially inside the disk drive and on the display pedestal above the rotary Mode switch. 

POWER WIRING RODENT DAMAGE

The main power box in the machine where the 230VAC is routed, with the power contactors, power sequencing relays and related parts, has openings in the back where the power cable comes in and where AC power is routed out to terminal blocks inside the machine for distribution to the rest of the machine. 

It appears that rodents chose to gnaw there way inside the box to nest, chewing the insulation off some of the AC wires going in and out of the box. I suspect I will have to remove everything and wire it anew with appropriate wires, or at least inspect carefully after removing all the bundles and looms. 

Gnawed wires going to upper relay

Signs of rodent inhabitation

Gnawed insulation to open entry hole

1053 TYPEWRITER FIRST LOOK

I was pleasantly surprised by the completeness of the console printer. The acrylic top plate is cracked but present. The metal cage that fits on the rear to route paper into the printer is missing. Otherwise, everything appears intact.

The condition appears quite good. The rotate, tilt and carrier movement tapes are all intact. Even the ribbon color shift tape is intact. No signs of major damage or corrosion. 

There is the usual crumbling IBM insulation and undoubtedly the oil and grease have solidified in all the joints. However, this gives me optimism that it was well adjusted when it began its decades of quiet moldering. I know how to deal with the lubricant issues and the foam.

cracked acrylic cover

ribbon color shift tape is intact

Rotate, tilt and carrier return tapes intact

Looking promising

Solid condition

Even the nylon piece that maintains tension on the carrier movement cord is intact, although that may not last. These break on most machines and need replacement; not a very challenging replacement. 

SLT COMPARTMENT AND BACKPLANE FIRST LOOK

All of the backplanes, signal cables and power distribution cables appear to be in excellent condition, just a bit dusty. 

Third party modification installed on the machine

DISK DRIVE NEEDS A LOT OF WORK

The drive has covers that should have protected it from the worst of the environment where it was stored, but that area is not sealed in any way. There has been substantial surface rust inside and tons of dirt everywhere. If this can be restored to operation, it will take a pretty major rebuild and cleaning. 

Card cage and rear doesn't look too bad

Rust and dirt everywhere

More rust and dirt

Disk head dirty

My guess is no head crash damage, just filthy

OTHER OBSERVATIONS

The display pedestal with the IBM original lamp holders is in the usual condition I find when I look at 1130 systems, with some of the lamp boards having worked their way out of the honeycomb. It is painfully tedious to reinsert them all but they can't remain as they are.

No rear cover on this one machine either, so back to the designs for the cover I put on the SSM 1130. 

The power supplies and regulators appear in sound condition. Once I repair the damaged wiring, my first priority is to fully test and adjust all power supplies before anything else in the machine receives power. 

The ball head that latches the right rear cover is missing. 

Round hole where the missing ball end post should be

There is a mystery cable which I believe is hooked to the third party modification I spotted in the machine. Of course I have no documentation for this change, but hopefully I can either figure out its interface to the 1130 in order to work with it, or perhaps disable it so that the rest of the system can be made to work.

Now we wait for this system to be picked up and the next restoration 1130 to arrive

PREPARED GUIDE FOR OWNER

I created a guide for the owner with the information they need to keep with the machine. It describes all the repairs I made to the system, the modifications installed and some important operating procedures such as loading the console printer paper properly and opening the various machine covers. 

FINISHED SETUP OF MACHINE FOR SHIPPING

I restrained the disk drive arm so that it won't move in and out. I also put a punched card between the disk heads to protect them. Some covers were restrained to the extent I could do that without damaging the paint. 

READY FOR THE NEXT SYSTEM TO RESTORE

The owner of this machine is also holding the next restoration target, an IBM 1130 for a different owner. When the truck comes to pick up this system, it will roll in the new restoration challenge and I can begin. 

Completed some minor cosmetic adjustments in preparation for returning this to its owner

POWER SUPPLY DOOR WASN'T LATCHING

The IBM 1130 has a footwell underneath the keyboard portion of the tabletop and the right side of that well is a door that covers the main voltage rail regulators (+3, +6 and -3). It should stay latched closed and require a small screwdriver or other straight object to release it by pressing through a hole on the back panel of the footwell recess. 

It was not doing so, because it was misaligned. I had to adjust the hinges for that access door but also the back panel in the footwell needed to be braced outward an appropriate amount so the latch would catch. I crawled inside and then under the footwell, making this work as it should. 

REAR COVER BEHIND DISK DRIVE WAS SLIGHTLY ASKEW

When you face the rear of the IBM 1130, there are two doors that are hinged at the left and right edge of the machine. The right door is long, because the long logic gates are inside and swing out for service. It closes with a spherical head that snaps into a latch on the frame. The left door should swing in and close with only a small gap between the two doors. The latch which I had to build is on the left door - a handle that you lift to release or to lock the left door in its closed position. 

Both doors were sagging at their far ends and thus the top corners of the two doors interfered, having a negative gap when you attempted to close them. The solution was to fix both so they hung with their top edge parallel to the floor, without sagging at the ends. 

After I moved the hinges around and tweaked some things, the doors fit perfectly and look much better as well. 

Successfully ran keyboard/1053 diagnostic program and did some additional testing - console printer in perfect condition now

MY PREVIOUSLY HACKED CODE NEEDED MORE WORK TO RUN BUT EVENTUALLY DID

The hack introduced so this would run on the imperfect 1130 simulator caused the code to complain on a real machine working correctly. I did some hand debugging and found the issues. More hacking but eventually the diagnostic ran through all its routines and the typed output looked excellent.

I hooked up the oscilloscope to watch various signals, including the controller logic Busy signal and the feedback circuits coming from the typewriter. It all looked great. The Interlock signal blocked any requests while the long duration functions - tab and carrier return - were underway. 

The CB Response signal activated at the points in the various cycles and didn't release the controller until the appropriate times in those cycles. This covered the space, backspace, printing, shift and tab initiation cycles. I looked at the millisecond timings and compared to the charts in the FE maintenance manual, finding agreement. The beast has been conquered!

Final resolution of the keyboard Space bar problem

DISASSEMBLY WITH SPECIAL ATTENTION FOR BINDING OR TWISTING

I didn't see anything underneath that was interfering, nor was the unit twisted or torqued in any way. It took it off the 1130 and looked it over. 

INVESTIGATION AND DISCOVERY OF THE ISSUE

One of the bail contacts was twisted out of position and touching the normally open counterpart, thus triggering the 1130 to believe there was a key pressed. It must have snagged on a wire as I was installing the keyboard last time. 

REPAIRED AND TESTING WITH THE CPU

The keyboard works perfectly now - including the space bar. I ran through all the keys and checked the output Hollerith values just to be certain I didn't introduce a fault during all the repair work. Success!

Battling the diagnostic program until I can run it on the physical 1130

NEW SIMULATOR AUTHOR SENT ME AN UPDATE THAT FIXES THE SWITCH ISSUE

The new version of the 1130 simulator, still in development by its author, includes support for the Console/Keyboard switch on the 1130 console with proper indication in the Area Code 1 device status word, bit 5, of the position of the switch.

This would allow me to more fully test the diagnostic memory image on the simulator that I would then be loading into the physical 1130 core memory. I am hoping it arrives any time now

ISSUES SETTING UP DIAGNOSTICS ON SIMULATORS

The proper execution of the keyboard/1053 diagnostic requires a working Console/Keyboard switch on the 1130, however the simulators I had do not implement that switch and default it to the Keyboard setting which blocks the diagnostic from testing the printer. 

Loading diagnostics involves stacking multiple card decks in a card reader and booting from the card reader. The relocatable loader (program 3AA) then reads in the diagnostic monitor (program 300) and the monitor reads in various diagnostic routines. In our case, we want to read in program 304 to test our console printer. 

It may seem simple to just put the three decks sequentially in the hopper and boot the reader, but the lack of accurate emulation of the card reader introduces failures. The simulators treat the readers as simplified devices, which is convenient to shield users from the complications of real 1130 operations, but that infidelity leads to problems. 

The card readers have a hopper into which cards are stacked and a station inside from which each card is read and ejected into the stacker. Because a card has to be fed from the hopper to the internal station prior to doing a read, the operator pushes the start button and the first card is fed into the station without the CPU or program noticing. 

When the bottom card in a hopper is fed into the machine during the read of the prior card, the machine turns off the Ready state. The last card is physically sitting in the internal station but cannot be read because the machine is not ready. This behavior is intentional as in the real world, very big decks of cards are used with cannot all fit in the hopper at one time. Each time the hopper empties, the operator adds more cards from the deck and pushes Start which turns on Ready and allows the program to continue reading more cards. 

However, when the hopper empties and the card in the internal station is really the final card of a deck, the operator just pushes the Start button without adding new cards to the hopper. Pushing Start with an empty hopper turns on the Ready status but also sets an indicator when the final card is read. This bit in the device status word, Last Card, tells the program that we should not loop attempting to read more cards. 

The simulators turn on Last Card automatically as the hopper empties. In real life, I could put the 3AA relocatable loader in the hopper, push start, and then boot it. When it came to a halt with the reader not ready, I could then put the 300 program deck in the hopper and push start. The machine would read the last card of 3AA and then that program would begin reading the subsequent cards from 300. 

When the 300 deck has its last card leave the hopper, the Ready condition goes off. Still no Last Card status. We add the 304 deck into the hopper and push Start. The 3AA program reads the last card of 300 and then the 300 program begins reading cards from the 304 deck. 

When the last card leaves the hopper of 304, if I push Start without inserting a new deck, the last card of 304 is read by 300 but the logic of the program will still try reading additional diagnostic decks, ignoring the Last Card status. 

For the 300 program, one must add a blank card to the end of the last diagnostic to be read by 300. Then, when it gets the Last Card and sees a blank, it begins executing the diagnostic program(s) it loaded. 

Thus the behavior of the reader and the Last Card indicator is quite pertinent to loading the diagnostics properly. the only way I can make this work is to stack the entire set of three programs (3AA, 300 and 304) plus a blank card into the hopper and boot the CR. 

Even after solving the card reader related issues, we have to choose when and how to stop the simulated 1130 in order to dump core contents that can be restarted on the real 1130. Restart is funny with the diagnostics, as one is actually first restarting the Diagnostic Monitor (300) which then restarts 304. Very easy for things to be tripped up so that the program does not start executing properly on the physical 1130. 

GETTING A SUITABLE MEMORY IMAGE THAT WORKS ON BOTH SIMULATOR AND 1130

I did find a version that I had hacked previously so that the monitor believed the switch was set to Console and didn't flag the actual state of the bit 5 as an error. With this version, I can restart on either simulator and see the 1053 output stream. It will not allow me to switch the diagnostic into keyboard mode where it echoes every keypress to the 1053, but I know the keyboard is working. 

TESTING WITH THE CONSOLE/KEYBOARD SWITCH 

I have two routes to testing on with the console/keyboard switch to  run both modes of the diagnostic. First, I can test on the simulator after I receive the new update, letting me figure out a memory load of the diagnostic that works when restarted and uses the Console/Keyboard switch. Second, I can figure out where I hacked the current memory load and adjust it so that it works with the physical 1130 and its switch. 

I will first complete the typewriter side run of the diagnostic to complete the formality that all is done on this 1130 restoration. Later I will do this testing so that they diagnostic runs on the restored machine with both modes depending upon the key setting. 

Making the keyboard Space bar work properly is continuing to be a challenge

LOOKING INTO THE POOR SPACE BAR OPERATION

The keyboard mechanism of an IBM 1130 is the same keyboard mechanism inside the IBM 024 and 029 keypunches, which were introduced along with the S/360, 1800 and 1130 systems in 1964. The mechanism was derived from the earlier keypunches such as the IBM 026 which was introduced in 1949 and continued on designs from much earlier in that century. 

On this machine, the space bar is quite low, barely is detected and may not restore properly. I had inspected the underside and found that a leaf spring associated with the key was out of position and perhaps adding friction. I fixed that, reassembled the machine but the problem persisted. 

I decided to really dig into the unit to figure out what was going wrong with Space and making it work well. That involved splitting the keyboard assembly into its two halves. 

DISASSEMBLY OF THE 1130 KEYBOARD TO IMPROVE SPACE BAR OPERATION

Physically the keyboard is two parts bolted together, the key unit and the permutation unit. A key unit has the physical spring loaded keys, a mechanism that ensure no more than one key can be pressed down at a time, and some levers that project into the permutation unit to select the permutation bar assigned to each key. 

I separated the two as my issue is mechanical, most likely in the linkage from the space bar to the permutation bar but possibly in the permutation bar latch for that key. Both are exposed by the separation. 

KEYBOARD OF THE IBM 1130 - EXPLANATION

It is a complicated beast because it has to convert the push of a single key into the Hollerith code associated with that key. For example, the letter a is a combination of the 12 and 1 rows on a punch card thus its Hollerith code is 12-1. a $ is 11-3-8 as it has three holes punched (in rows 11, 3 and 8). The numbers themselves were very simple, the digit 4 is a hole in column 4 or Hollerith code 4. 

Add to this complication the fact that the keypunch had more characters than physical keys, such that it needed a shift key. This was generally labeled the Numeric key and pushing it would encode an alternate character for each key pressed. 

As you may be able to see, the key marked F has a semicolon (;) printed above the F. If the Numeric shift is held down while pressing that key, the card has a code of 11-6-8 but without the shift key this must produce 12-6 instead.

Handling the code translation for shift as well as the need to emit multiple row signals for a single key press involved a combination of mechanical and electrical solutions. The keylever would latch down and lock the keyboard, but in that latched position it will cause a permutation bar to be pulled downward in the back half of the machine called the permutation unit.

The Hollerith code was generated by switches activated by the permutation bar so it had to remain down and locked until the computer had captured those bit values. A restoring solenoid was activated by the computer (or the manual KB Restore button) which pushed the permutation bar back to its idle position and pushed they key back up. Thus typing at speed involved the keyboard latching, the computer grabbing the character and then restoring the keyboard before the user's finger next pressed a key. 

Each permutation bar has fifteen notches in it vertically, which align with fifteen pivoting horizontal bails. A bail has a microswitch at the end, thus pivoting a particular bail closes the circuit for that bail. Each bail has tabs extending backwards for every key that should pivot this bail. Lack of a tab means the bail does not energize. 

Tabs on a bail to associate it with certain keys

Contacts on the sides of bails, switched when bail rotates

As we can see, pressing a key activates certain bails so that we translate one key into a pattern of 15 bits. The astute reader may wonder at this point why not just use 12 bails, so that the output is the direct Hollerith code for that key as it twists selected bails. The reason is the Shift key and the second set of characters associated with most keys. 

At the bottom of most permutation bars is a microswitch that is closed when the permutation bar is latched downward. Thus, we actually have 15 bits from the bails plus 1 bit from the latch contact below the permutation bar. 

The shift keys (Numeric and Alpha) direct power to bails and latches. Some bails are only powered by the Numeric condition and others only by the Alpha condition while one is powered by the joint Alphameric bus. Similarly the latch contacts are powered the Shift, Numeric or Alphameric buses. Alphameric is the always powered whereas Numeric and Alpha are switched by the Numeric key. 

Wiring of 1130 keyboard

The bail contacts are circled in green, the remaining are the latch contacts. This clever connection of latch contacts, bail contacts and the Numeric key along with the selective use of tabs to activate bails produce the Hollerith codes for all the keys.

A few of the keys on the keyboard do not latch down nor activate permutation bars - Numeric and KB Restore. Some do their encoding purely through the latch contacts - Space bar, Erase Field, End of Field, Backspace and Interrupt Request - even though they latch down the permutation bar. 

CAN'T FIND SOURCE OF PROBLEM IN EITHER HALF

I looked carefully, tripped and reset the permutation bar for the Space key many times, verified that the linkage from the key on the key assembly was good as well. 

As is visible in the top picture, the keys have those long levers with right angle hooks. When a key is depressed, the hook is pulled backwards into the key unit. That hook fits around the triggers you can see in the upper opening of the picture immediately above this text. It pulls forward on the trigger there and the permutation bar is moved downward to its latched position.

These are the permutation bars with their latches at the top half of the picture. The far side which you can't see has the fifteen notches that can move tabs on the bails. In the case of the Space key, the hollerith pattern is an absence of holes (bits) so there are no tabs fitting into this permutation bar. 

The bottom of each permutation bar will press down and close a set of contacts (the latch contacts) when that bar is locked down. In the case of the Space key, the only electrical connection made is the latch contact below the permutation bar, which tells the controller logic that a space was pressed. 

I can see nothing wrong or even different with the space permutation bar and any other one. Similarly I can find nothing wrong with the space key mechanism and its lever that trips the permutation trigger - the same as the others on the unit. No signs of corrosion, rubbing or other friction. 

REASSEMBLED AND TRIED AGAIN

I put the two halves together, the keyboard back in the 1130 and closed everything up. The space bar was working fine as I held the keyboard in my hand, so I was hopeful. Alas, when closed up in the machine, the space key was back to its bad ways. Even worse, when I powered up the machine, I heard nonstop restoring which is an indication of some new problem I introduced in the keyboard probably a contact that was disturbed. 

RAN OUT OF TIME BUT WILL SOLVE THIS TOMORROW

Tomorrow when I return to the shop, I will bring two things. I will bring a version of the printer diagnostic that I believe will function well enough to work out the 1053. I will also come with a new theory that something is mechanically binding when the keyboard unit is screwed down into the 1130 or when the lamp & pushbutton plate is placed over it.