Had fun building demo programs - particularly the ones that calculated Pi

RELATIVELY NEW SPIGOT ALGORITHM IS A GREAT FIT FOR THE IBM 1130

In 1995, Stanley Rabinowitz and Stan Wanger published a paper on a spigot algorithm for calculating the value of Pi. It has a number of features which align well with the limitations of the 1130 hardware. 

This algorithm does not save any of the prior digits, calculating the next digit without needing to have stored a perhaps very long string of prior digits. An 1130 system with 4K or 8K words is going to have trouble with memory intensive approaches.

This algorithm strictly uses integer arithmetic, no floating point at all. The 1130 machine architecture only supports integers. Using multiplication and division instead of more complex mathematical operations, the algorithm is easily implemented. 

The number of digits that can be accurately produced by the algorithm from the paper is related to the number of stages used to calculate each digit. A stage has a fraction and a running value, accepting a carry from earlier stages and generating a carry value for the next stage. 

Each digit being produced involves some simple operations applied from the rightmost stage to the leftmost and the final stage value is the digit that is output. Starting over from right to left creates the next sequential digit of Pi. 

Each stage stores a fixed numerator and denominator of a fraction, plus stores the working value of the stage. Thus we need three words for each stage. To produce N digits accurately, this algorithm needs 3Pi*N words. If you want 100 digits correctly, it needs about 960 words of memory (320 stages). Thus even a 4K machine could generate more than 400 digits of Pi.  

The time it takes to calculate a round is 245 microseconds. Thus a round of 320 stages requires 78.4 milliseconds and this produces digits at the rate of 12.76 per second. The entire 100 digit output would take only 7.84 seconds. Not bad for a machine with an execution rate of only 33.3K multiplies or 12.5K divides per second. 

Since the demo monitor will be supporting multiple demonstrations, the programs I wrote only had 80 stages and thus produced just 25 digits of Pi accurately in a half a second (not counting typewriter output delays). The typewriter operates at 10 to 15 characters per second, so the actual demo takes a couple of seconds. 

Cobbled together toolchain to build and test the demo programs and monitor

FIRST CUT WAS MANUAL ASSEMBLY - TOO TEDIOUS

At first I just wrote the instructions and then the hex values for each. Since the IBM 1130 has relative addressing for its short format instructions (single 16 bit word), each one has a displacement that is -128 to +127 words from the address following the one I am assembling. I have to calculate the distance, convert to hexadecimal, and then form twos complement for the negative displacements. 

I then transferred the words into a text file in IBM 1130 simulator load format, essentially four hex characters per line to load a word. An @ sign prefixes an address which changes the location where the next word will be placed. 

Every time I find a bug and make a change, I have to go through the code and recalculate any short instruction where it or the location it references have been moved. This is tedious. It then requires me to scan the load file I built and copy those changes into what is a long text file of four hex character lines. 

MOVED TO THE 1130 ASSEMBLER UNDER DMS TO ASSEMBLE THE CODE

By typing the instructions in the correct format for the assembler, which involves strict column positions for fields and other requirements, I could boot up DMS2 on the simulated IBM 1130 and assemble my code. The heavy lifting of calculating displacements was all done by the assembler, but I could just take the hex words listed next to the statement and transfer them to the text load file. Much easier.

Still, when I made changes, I had to manually locate any lines in the load file that were affected and adjust them from the new assembly listing. Still labor intensive but a step forward.

PYTHON CODE TO READ ASSEMBLER LISTINGS AND CREATE LOAD FILE

I whipped up some Python to read the printer output of the assembly job, which is a text based file produced by the IBM 1130 simulator. I grabbed the hex data words and output them into a new text file in the load format. I would look for the ORG assembler directive (origin) and grab the address to form the @xxxx lines in the file. 

I didn't want to recreate the assembler so I was not tracking how the address changed from statement to statement. I simply began a section from the ORG address and then snagged each word that the assembler formed from the statement.

I did run into some issue with some directives, which would fool my script into injecting a false word into the load file. EQU is a directive that makes a symbol table entry with some value, but does not reserve space or generate any words to go into memory. I had to skip past these. 

As well, the END directive outputs the supposed starting address that DMS2 should branch to when executing the code, but it is just an address not a value to put in memory. I had to skip it or I put spurious hex words in the load file. 

The most troublesome directive was the BSS - block started by symbol - which reserves space in memory. It would therefore be bumping up the address into which the next real hex word should be placed. One form is BSS 3 which means reserve three words here. I would have needed to keep a running shadow copy of the address that the assembler was using so that I could add 3 to it. 

Another form was BSS E 0 which means reserve one word if the next address is not an even number, otherwise do nothing. It is used to ensure that some double words are properly placed where the machine requires the first word to be on an even address A and the second word to be at A+1. If the double word in question was placed at an odd address, then the machine would pick up A for both words and never see the second word. 

In order to shadow the current address where the assembler believes the next statement will be placed, you need to know the sizes of every statement that came before from the last ORG. Too much work involved in that. 

I resolved to code with DC - define constant - so that BSS 3 would become three DC 0000 in a row. That gave me a load file output that put all the words in the right place, where the assembler intended them. Once I knew the limitations, however, I was able to quickly change, reassemble and process the listing to have a new load file I could load into the simulators memory. 

Demo monitor completed and tested; working on various demos to run under the monitor

DEMO MONITOR FULLY TESTED AND READY TO GO

The monitor, which will be resident in core memory, enables an easy demonstration experience. By raising the Console Entry Switch corresponding to the desired demonstration and hitting the IRQ button on the keyboard, the monitor will begin executing that chosen demonstration code. 

It has the ability to host sixteen different demonstrations. Some will be able to run without a working console printer (typewriter), some without a working keyboard, and can be designed to highlight different aspects of the machine. 

The monitor provides various services that can be leveraged when writing individual demonstration programs, such as printing a string of text to the typewriter or accepting an (edited) stream of characters from the keyboard. Other routines validate whether input is a valid number, or convert a number to a stream of typewriter characters that represents the number in decimal. 

DEVELOPING DEMONSTRATIONS TO RUN UNDER THE MONITOR

As one example, a demonstration will perform twelve million multiplications, which occur at the rate of 200,000 per second. This is reflected by the alternation of the lights in the bottom register (EXT) of the machine, which is almost fully lit for one second and then almost completely dark for the next, as a kind of metronome. The demo lasts sixty seconds. 

Another demonstration prints a simple welcome message on the console printer. I have been working on writing the demonstrations and testing them. The first two I mentioned are complete and I am currently working on a third that lets the user type in up to 32 characters on the keyboard. 

This sounds like a simple application that just reads and then spits out the same data, but the reality with the 1130 was more complicated. Keys on the keyboard produce a Hollerith code for the character, stored in the leftmost 12 bits of each word. Typewriter characters are selected by a six bit code, plus 1 bit for upper/lower case side of the ball. These have no correlation at all.

The keyboard of an IBM 1130 is the mechanism from an 029 keypunch, which is why it produces twelve bit Hollerith. The key A on a keypunch causes the 12 row and the 1 row to get a punch, with nothing in the 11, 0, 2, 3, 4, 5, 6, 7, 8 and 9 rows. Thus it is 1001000000 in binary. The 1130 word for the same key is 1001000000000, just padded on the right to get to the 16 bit word size. The typewriter code for an A is 00111100 or 00111110 depending the hemisphere of the typeball. 

This means the program must translate from one character encoding to another. That was par for the course with the IBM 1130 - different encodings for the card reader/keyboard, typewriter, 1132 printer, 1403 printer and paper tape. 

The program also shows off the keyboard editing functions where you can abandon the line to start over (Erase Field) or backspace to replace a mis-keyed character, but the entire entry is not complete until the EOF key is pressed. The EOF is the predecessor of the Enter key of today. 

SOME OTHER DEMONSTRATIONS I AM ENVISIONING

Two are very similar, but they differ in whether the console printer (typewriter) is available. The user types in two numeric values (pressing number keys, sign and then EOF), which are displayed either on the typewriter or on the display panel lights in the ACC register, then the program adds them and presents the result on typewriter or in ACC. 

Another will calculate digits of Pi using a Spigot algorithm, thus no floating point which is not a hardware data type of the 1130. It will print them out digit by digit, with the speed of the digits typing reflecting the working of the algorithm. 

A music playing program exists, which plays a tune that is kind of recognizable from an AM radio held near the core storage compartment. This program is written in Fortran, but I will need to convert it to assembler in order to fit it into memory without needing the regular disk based monitor and its subroutines. 

There are also other programs - games - written in Fortran that I might convert to assembler and implement as a demonstration. 

Still have an issue with bit 7 inhibit

HIGH 4K HAD ISSUES WITH BIT 7 INHIBIT BUT LOW 4K SEEMED GOOD

I had been getting persistent parity errors in the upper 4K, as soon as the memory address crossed the threshold into the upper section. I saw bit 7 and 11 as troublesome in that area. However, it did appear that the lower 4K was working properly, at least until the flakiness from the loose connector arose.

AFTER CONNECTOR RESEATED, BEGAN SEEING ISSUES IN LOW CORE

I would load some data in memory and relatively quickly see a parity error. Further, the data coming back out of memory did not match what I had attempted to write. For example, I tried to load this sequence of words starting at location zero:

• 080B
• 3001
• 0000
• 0804
• 0805
• 0806

As soon as I got to locations 3 or 4, the parity light came on. Where I tried to load 0804 into memory, what came back was 0904 and the left side had a parity error since it did not have the P1 bit set. This issue with bit 7 inhibit is repeatable at locations 3 and 4 but did not arise at locations 0, 1 or 2. 

Once again I suspect that we have excess write drive current for some types of addresses which the inhibit cannot overcome. I don't see a route that would cause bad transmission of an inhibit bit value only with certain address ranges, but that doesn't mean it can't exist.

Some areas that could be failing:

• Diodes shorted thus combining currents
• Leakage and coupling between adjacent drivers causing extra current

Bit 7 inhibit is handled by two separate cards, depending on whether it is above 4K or not. The existence of bit 7 inhibit failures in all 8K of memory rules out the inhibit cards themselves. 

The leakage between adjacent driver pins is a known failure mode of these core memory modules, as described in the IBM 1130 Field Engineering Maintenance Manual. Unfortunately, the fix for that is to replace the entire memory module since the leakage is occurring on the SLT backplane that hosts everything in the memory module. 

If the worst happens and there is such leakage, it does not mean that it is impossible to repair or tweak the backplane. It just means that IBM decided it was unreasonable to attempt that in the field when a spare part could be ordered and the factory could rework as they choose after the fact. 

This is going to be a vexing investigation. I am going to have to begin scoping the memory during these operations to try to spot a smoking gun. 

This is not an issue with individual cores or lines of cores. It is not an issue with the read process, because that is reliably flipping cores back to the zero state and recording the pulse on the sense line when they were previously set. If it was not resetting reliably, we would see bits read as 0 when they should be 1. Instead we are seeing bits read as 1 when we intended them to be zero. That can only happen during the write phase when the core flips to 1 but should have been inhibited. 

Found one cause of flaky memory operation and finished reconfiguration without two CRs, LP and PT

FINISHED RECONFIGURATION OF DEVICE CONTROLLERS

I had pulled all the cards that implemented the device controllers for the 2501 and 1442 readers, the 1132 printer and the paper tape punch since the devices are not currently available to hook to the machine. I have the cards and can reenable them if/when the VCF museum restores one or more of the peripherals.

I found the machine triggering an interrupt on IL4, which was due to a signal line that was driven by the 2501 device controller. Adding a jumper blocked this spurious interrupt request. The main issues when certain peripherals are not configured in the machine is that certain requests like interrupts and cycle steal are positive logic signals - requesting when high - and SLT logic interprets an unconnected wire as logic high. Thus the jumper to pull that wire to logic low.

FOUND A LOOSE CARD IN B-B1 COMPARTMENT, CARD IN E7

I did a hand check of the seating of all the cards in the B gate, which is essentially the CPU plus memory. I did find the card in B-B1 E7 to be wiggling around, so I popped it back in place. 

DISCOVERED A LOOSE CABLE CONNECTOR INTO MEMORY COMPARTMENT

I was doing some load and display tests of memory locations and kept seeing odd results. I decided to set a word to FFFF - all bits on - which looked correct in the Storage Buffer Register as I did the load, but when I read back the word I saw that bits 1 through 9 were coming back as zero. The parity didn't add up so it causes a parity error on the first read. 

I realized that this looked like a failure of the B bits to drive the inhibit current and the fact that it was a range of bits was suspicious. The CPU would have sent all 16 B bits as 1, meaning no inhibit. It calculated the parity bits based on this - each half of the word had an even number of 1 bits thus the parity bit was also set to 1. When it read back as 803F, the left word had a single bit (bit 0) turned on but the parity P1 was also set - an error. The right half word had six bits set to 1, thus it did need parity P2 to be correct and thus was good parity. 

Thus the failure happened after the memory parity generation circuits saw the B register and before memory acted on them during the write. Looking at the ALD, the B bits come into the memory compartment (C1) as inverted logic, thus if they are to write a 1 in that position, the signal would be pulled to ground (notB is false therefore B is true/1). 

Further, the bits that were missing were all on one connector (T1) plugged into the top of the memory compartment. I visually inspected the connector and could see that it was loose. The card covers on the compartments fit into side mounting plates which block the A and N columns of the SLT card, so that any connectors on the left or right can't be directly accessed until those plates are removed. 

The top and bottom connectors are rows 1 and 8 are blocked by the frame itself, with no easy access. One can remove the adjacent row of cards (all cards in B7 through M for example) to get fingers down into the space for the row 8 connectors. For the top, however, there is the possibility of removing the grating at the top of the compartment that allows the air coming from fans below to be blown out of the card compartment at the top. 

Connector dangling out of its slot

I found that the connector was completely unattached. I plugged it back in and cured that problem. While I was doing that I saw that the plastic cable retainer, which keeps the cables to the side so they don't block the airflow out of the compartment, had come loose from the wall of the compartment because the foam double sided tape had disintegrated with age. The old foam looked like loose rust, which is very dangerous indeed in a compartment with electronics and cores. However, it was just gross nonconductive foam. 

I glued the cable retainer back where it belonged and closed up the compartment. I began loading code into the machine to do some tests, but the day came to an end so this will have to wait until tomorrow.

Grating back in place

Wrote demo monitor program for use by museums without reader, printer and disk

FRAMEWORK TO HOST MULTIPLE DEMONSTRATIONS

This is intended to have up to 16 demonstrations loaded in the machine, any of which can be selected easily by flipping on the Console Entry Switch for the desired routine and hitting the IRQ (Interrupt Request) button on the keyboard.

This has the interrupt handler for the keyboard, console printer and IRQ button which makes it easy to do input-output with these devices. There are defined areas where the calling demo code uses to know when its request is fulfilled. 

For example, a caller can put a flag FFFF into the input communication word, then activate the keyboard with a Keyboard Select. When the user presses a key, the interrupt handler reads the value of the key pressed and puts it into that communication word, then resets the keyboard. For typing on the console printer, the user stores any nonzero value in the output communication word, then issues the print to the typewriter. The interrupt handler will zero out that word when it has been successfully printed. 

SUPPORT FUNCTIONS PROVIDED TO MAKE DEMO WRITING EASIER

I included some support to make demo programs easier. Initially these are routines to print one character, a routine to print a string to the typewriter, and a routine to let the user type in an input string of up to 32 characters, terminated by the End of Field (EOF) key. 

FUTURE SUPPORT ROUTINES ANTICIPATED

I anticipate a routine that will format a number as a string of characters for typing and another routine that will accept a typed in number, do error checking and then return a numeric word as the output. 

WILL WRITE SOME DEMO ROUTINES NEXT

Some will be simple, such as a task that multiples two numbers a fixed number of times (many thousands) then ends. It will not require any access to the keyboard or console printer. 

Others will make use of the printer, such as a program to calculate and type the digits of PI to some set number of places.

Simple games, music playing programs and others are candidates to build as demonstrations. 

All but three lamps are lighting on the display; possibility that device controller logic is stepping on memory access

GATHERING SPARE SCRS FOR REPLACEMENTS

The 1130 has a row of eight bulbs on the display panel marked CE 1 to CE 8. These were intended to be temporarily wired to some logic cards to display certain conditions that the customer engineer believed might be an error condition or an important indicator while debugging. 

Row of removed SCRs and bulbs for the CE positions

Modern logic analyzers and other tools allow such logical conditions to be observed without having to wire up a light. Thus these are unneeded and are a source of spare SCRs that won't be missed. I carefully unsoldered all eight SCRs from the display panel and tested all of them. One of the SCRs was shorted so that the bulb was always lit, but seven of them were good spare parts. 

Seven good spare SCRs

INVESTIGATED EACH DARK LAMP POSITION AND CORRECTED

Since there are many possible reasons for a dark lamp, I had to check several ways to find the cause. After visually inspecting the PCB for bad solder joints, I tested the bulb on the workbench to eliminate that cause. I then unsoldered the SCRs and brought them to the testbench to check them out for proper function.

I did find one that was unwilling to light. The others were all working properly, which turned my suspicions back to the PCB solder connections. I soldered the SCRs back on the board and used some cut off wire leads from components as connections to ensure good connectivity from the SCR pin to the metal bus on the PCB.  This fixed almost all of them, suggesting that some solder joints will look intact but still fail to conduct properly. 

FINAL TALLY - THREE DARK PLUS ONE THAT IS ONLY DARK ON LAMP TEST

I have one bit on the Instruction Address Register (IAR) row that is not lighting. There are two status positions, ZR and AC, that are also dark. Another bit on the IAR will not light up with the Lamp Test but when the actual IAR bit is on, the lamp lights up. This suggests the bad joint is to the test pin on the SCR but it could be a failure inside the SCR. That last situation can be fixed by soldering a wire to recreate the lamp test path to that SCR. 

Almost every position lighting on Lamp Test

Because of the risk of joints cracking, incandescent bulb wire leads snapping, signal pins snapping and other issues that come from manipulation of the boards, I am going to call this good enough for now. I might do a quick continuity test on the SCR pins to ground and test, as I could resolve that by soldering a wire jumper without pulling the boards out 

PULLED ALL THE DEVICE CONTROLLER CARDS FOR 1132, 2501 AND 1442

When I would run a Storage Load operation to cycle through memory storing an all zero bit pattern set on the Console Entry Switches, I would see flickers of a few bits turning on, mostly bit 7. This corresponded to the condition that caused the Parity error stops. 

Once possibility is that something is jamming that bit on sporadically and based on the timing it could be the reason that sometimes an inhibit fails (turns off too soon) or similar race condition pops up. The device controllers in the machine are all able to put bits on the common bus, so they could be the offender. 

Looking at the connectors on the machine, we can see that it had device controllers for a 2501 card reader, a 1442 reader/punch, an 1132 printer and a paper tape punch. The machine does not have any of those peripherals attached right now, although it might have some back at the VCF museum that will be used later. 

PC8 is the signal connector for a 2501 reader, PC7 is for the 1132 printer and PC6 is for the 1442 reader/punch. The smaller connectors PC1, PC2 and PC4 are the power connectors for those three devices. In addition, there is an SMS paddle card connector inside the machine where a 1055 Paper Tape Punch would be connected. 

I looked up all the cards involved in those device controllers and pulled them from the machine. I am always add them back in and test them later in anticipation of their eventual use, but debugging will be simpler with these out of the mix right now 

NEED TO DISABLE SOME LOGIC NOW THAT DEVICES NOT CONFIGURED

When I first powered up after pulled all the cards that constitute the device controllers above, the machine immediately showed requests for Interrupt Levels 0 and 1 as well as incorrect memory output. IBM documents jumpers that should be installed to disable various signals based on the devices configured for the machine. 

Specifically, when there is no card reader and no 1132 printer, interrupt level 0 and 1 are disabled by jumpers. I added the jumpers and the issue with interrupts went away. 

I still have some funny issues with data going into and out of the B register (SBR) which is undoubtedly drive by some enabling gates associated with the removed device controllers. I have to work through the jumpers and diagnose the condition, but I should be able to get back to a workable base where I can continue trouble shooting the parity errors (or find they have disappeared along with the device controllers). 

Minor tweak needed for pushbuttons; tab working well; display panel continues to earn my hatred

TAB AND RETURN WORK WELL

Having freed up all the moving parts on the carrier and left of the frame, I have the tab function working just as it should. Similarly, carrier return works perfectly. Space will need an adjustment or more work. 

PUSHBUTTON ADJUSTMENT WARRANTED

The three pushbuttons (Tab, Space and Return) are not pushing the actuator rods far enough down to reliably trigger an operational clutch. I can see that they need adjustment to provide more contact and more travel.

The pushbuttons are connected to the operational area by thin metal cables protected by outer sheaths. These transfer the inward push of a button to a downward pivot of the arms that push down on the actuators. The sheaths are anchored by a plate which is screwed down to hold them in place. By moving the sheath in or out a bit, one can adjust the movement of the arms. 

In fact, I found that one of the two screws holding the plate down was loose, thus the sheaths must have backed out a bit over time. The only challenge in working with them is that the axis of the screw is directly behind many parts, so that a screwdriver can't be inserted to turn the screw. 

The last time I had to adjust the plate on a Selectric, I had to disassemble some of the parts that blocked the path so that a short screwdriver could fit inside to loosen and tighten the screws. I will decide how much I need to do since it is essential that I adjust the position of these sheaths. 

THE DISPLAY PANEL HARDWARE REMAINS MY MOST DESPISED PART OF THE MACHINE

Not only do I have to contend with the wire lead bulbs which are snapping off at the glass envelope every time I pull a row of lamps out to work on those that don't light, but the dark positions can also be caused by three other issues. 

The bad solder joints on the PCBs holding the SCRs and bulb mounting pins cause many a position to not light with the Lamp Test because of connectivity errors. Often this also means they won't light when their associated signal is on either. Some pins refuse to solder nicely to the thin traces. 

A few of the SCRs are dead - probably shorted out in the past during maintenance activities and not replaced since the system was ready to be decommissioned years ago. I have to unsolder them, unsolder a donor SCR from an unused position (CE lights) or my own display panel boards, then add the new SCR to the PCB. 

Finally, the signal pins can snap off from the repeated bending of the signal leads moving around as they are unhooked and hooked to rows being worked on. I had another pin snap off today and this will require me to again excavate the plastic housing to expose metal, then solder on the broken pin. 

I have plenty of LED replacement bulbs, but when the position is bad because of solder joints, dead SCRs or broken pins, it doesn't restore that position to lighted operation. I really want to get all the positions lighting as this makes debugging of the machine so much easier, plus the machine should have all its blinking lights working if it is restored. 

Short visit to shop: replaced transport pulley, working on tab mechanism

I PUT THE NEW TRANSPORT PULLEY ON THE TYPEWRITER - TENSION IS PERFECT

The tension maintained in the cord that pulls the carrier left and right should compress the springs in the transport pulley to align with a target notch when the tension is ideal. I took off the broken pulley, installed the new one, stretched the cord over the pulley, and found that the pulley was aligned at the proper point. 

New pulley in place

Broken pulley I removed

TAB MECHANISM WORK

The tab mechanism is complicated, with parts on the carrier, in the operational function area of the body and over on the left where it latches a microswitch to indicate that a long (tab) operation is in process. There is also the cylinder with the individual tab fingers at each column that is rotated to set/clear and which unlatches the carrier when it reaches a finger that is set. 

The latch on the left with the microswitch was frozen solid initially but I now have all the parts moving almost freely enough to work properly. There is a small spring that must be attached to one hook which is bedeviling me as it is soooo tiny and hard to manipulate onto the hook. The tab operational function mechanism almost works properly - it mostly fires one clutch turn and turns the tab tilt bar which should cause the carrier to latch up a tab.

The carrier should lock the teeth out of the space and backspace racks, allowing the carrier to move rightward freely. That lock involves sliding a mechanism to the right (as seen from the front of the typewriter) where it latches. When a tooth on that mechanism runs into a tab finger in the set position, it unlatches the tab letting the teeth fall back into the racks to stop the movement. 

I did more lubrication and manipulation of all the parts in the carrier related to the teeth and tab function. There was a spring unhooked which is responsible for pulling the tab mechanism into its latched position, so I rehooked it. This is continuing to improve and I should have the tab operation working well soon.

CARRIER MOVEMENT REQUIRES MAINSPRING TENSIONING AND SOME LUBRICATION

The carrier moves leftward easily but won't glide to the right as it should when the tab function (or space function) moves the teeth out of the rack(s). It is quite stiff, which I believe is due to clutches on the constantly rotating operational shaft being gummed up and introducing drag. I need to lubricate these and make sure they operate properly.

The mainspring must be put on the machine and properly tensioned. This involves positioning the carrier all the way to the right initially, thus I have to free up the binding of rightward movement first. 

The mainspring is prewound a number of turns and installed while the carrier is in that rightmost position. The carrier return function is then engaged to move the carrier all the way to the left margin. This winds the mainspring further, imparting the power that will drive the carrier to the right during space, print and tab operations. 

Unable to get to workshop today, but key parts arrived

NEW TRANSPORT PULLEY HERE FOR 1053

This spring loaded pulley sets the proper tension on the cord that pulls the carrier left and right. The original IBM part had a nylon component which became brittle with age and snapped. This is a common failure on Selectric machines - I have seen it on three of six Selectric machines. 

ADDITIONAL LEDS ARRIVED, PREVIOUSLY GOT MORE 470 OHM RESISTORS

The LED replacement bulbs I build into the IBM nylon bulb holders consist of one of these LED bulbs, a 470 ohm resistor, and fine 26ga wire which mates those parts to the bulb holder. I now have enough to replace every bulb in the 1130 system.

WILL NOT GET MUCH TIME TOMORROW EITHER

I had volunteer duty at the museum at Cape Canaveral Space Force Station today, in two different facilities for four different tour groups plus small batches of visitors. That took the full day and kept me from the workshop.

Tomorrow the condominium where I live is having a fire inspection and as an association board member I have to accompany the inspectors and let them into various units and rooms. That too will chew up a large part of a workday. I look forward to Friday when I have a more normal schedule that provides time to get to the shop. 

Great progress loosening up the 1053, also working on display panel

OPERATIONAL FUNCTIONS RESTORE PROPERLY

The operational functions (tab, space, backspace, return, and line feed) were constantly engaging which blocked the carrier from any other action and in some cases fought each other. The small spring loaded latches which hold the actuation rods in their forward idle position were so gummed up that they did not move at all. Thus, at the end of an operation function when the actuator is pushed forward, it would immediately fall backwards to trigger another cycle.

Lots of fine clock oil and hand manipulation got them all freely moving. Therefore the actuator rods would restore and remain in idle. I was then able to work on print cycles and other parts of the machine that required the operational functions to be inactive. 

PRINT SELECTION WORKING

When I first triggered a print cycle, I couldn't even turn the shaft with the hand cycle tool. Everything was so frozen with solidified lubricant that nothing moved. I had to work on it in sections, by removing the gear that drives the print shaft which throws the ball forward, locks in the tilt and rotate positions and advances the ribbon. With the print shaft disconnected, I could lubricate and turn the rest of the print cycle mechanism to free it up. 

The cycle clutch trigger mechanisms were frozen in place initially. I patiently oiled and manipulated each moving part until it operated freely. Next up I had to lubricate the selection mechanisms that choose how much rotation and tilt to impart, with the biggest issue being the parts for the +5 rotate actuation. More stuck parts that succumbed to oil, hand manipulation and patience, but eventually it was selecting properly. 

I then attacked the gummed up print shaft inside the carrier, flooding all the moving parts with oil and gently rocking the shaft until I got it rotating cleanly. I put some attention into the ribbon advance plate and the selection detent locks next. With that done, I could put the gear back on and join the print shaft to the rest of the print cycle mechanism. 

SPACE AND TAB STILL NEED WORK

The carrier movement is implemented partly with mechanisms on the rear of the carrier that engage with some toothed racks, and partly by tilt bars driven by mechanisms in the body of the typewriter. I oiled and moved the small levers and teeth on the carrier until that part is working properly. 

However, the two tilt bars - space and tab - were sluggish and not moving properly. I did get the space tilt bar working properly, so that I can tilt it by hand and get a carrier movement. The tab tilt bar is still jammed solidly. 

The parts in the body that should flick the space tilt bar enough for a one column movement are not moving properly or not correctly adjusted, because they don't move the tilt bar. The lever that should flick it instead is moves in a clean miss, never touching the end of the space tilt bar. 

The tab bar has a more complex mechanism that includes some latching on the left side of the typewriter which holds until the tab movement is ended by striking a set tab finger at the appropriate column. However, the latch acts as if it is a single welded bit of metal - no movement at all. 

I will continue at the next visit to the workshop until I get the tab and space tilt mechanisms working reliably. One issue that complicates my testing is that the mainspring was not connected properly and thus is unwound. That provides the tension or pull which will move the carrier forward for space or tab operations. I will first have to prewind and attach the mainspring before I can be sure that I have the tab and space performing properly.

STILL TO START ON - CARRIER MOTION CORD TENSION, SHIFTING, AND RIBBON COLORS

Th e tension of the carrier cord is partly set by the mainspring, which I discussed above, but also depends on the transport pulley with its spring loaded tensioner. That part is broken. When the replacement arrives, I will install it and then get the carrier cord properly set up.

I have not yet tried the shift mechanism, which rotates the type ball 180 degrees to position its 'upper case' and 'lower case' sides for typing. This has to work properly before I can check and fine tune the rotate selection of the typeball. 

One last area of the 1053 is the mechanism to select between the two ribbon colors - red and black - by actuation solenoids that add or remove tension to a nylon belt that transmits the tension inside the carrier to affect the amount of lift of the ribbon when a character is being typed. 

SOLDERED SOME SCR JOINTS BUT IAR STILL HAS UNILLUMINATED LAMPS

I fixed all the joints that I could determine had failed on the IAR (instruction address register) row of lights. I installed LED bulbs in all 15 positions, but when doing a lamp test I still have four or five not lighting. Some are the same that have refused to light in the past, but a couple are 'new' failures. Grrrrr. 

More defective solder joints on 1130 display panel

ATTEMPTING TO GET ALL 15 OF THE IAR BITS LIT, I DISCOVERED A BAD JOINT

When I was replacing bulbs that were not lighting, I noticed that the SCR and second bulb pin wobbled a bit more than usual. Looking closely, I could see that the solder joints were bad.

At least three joints are bad in this picture

I am going to do a more thorough inspection of these boards, starting with the IAR board, and reflow every suspect connection. Hopefully that will result in all fifteen lamps illuminating under the Lamp Test function. 

Diagnosing core memory issues now that I have a full display to watch

PATTERN DETECTED IN THE REAL PARITY ERRORS

I noticed that either I had a 1 in bit 11 but a 0 parity bit (bit 17) or I had a 0 in bit 11 and a 1 in bit 17, both of these were where the remainder of the word meant that both 11 and 17 should be 0 or both should have been 1. 

There are two cards that implement the inhibit and sense operations for bits 11 and 17, which are unique to the upper 4K of memory. This fits the symptoms. I swapped the 3475 cards between low and upper 4K, then swapped the 3466 cards between low and upper 4K. These swaps were at K2/L2 and M4/N4 card slots. The error did not go away in the upper 4K so it is NOT the cards. 

Loaded all of memory with all zeroes than ran a Storage Display scan which hits the parity errors and stops normally. By using the Parity Run switch, it continued in spite of the errors. This was illuminating because I saw bits 7, 9 and 11 flipping on sporadically as the display continuously cycled around all of memory. 

These errors are also specific to certain address ranges. That is, they only occur in the upper 4K when bit 9 is a 1 and for certain combinations of the four lowest address bits 12, 13, 14 and 15. It will never get a failure if bits 14 and 15 are both 0, nor does it fail with just bit 15 set. However, it is very reliable in failing when bit 14 is on by itself or other combinations of 12, 13 and 14. 

Somehow in all the swapping of cards and testing, I am now seeing errors occurring in the low 4K of memory, also having the low address bit pattern from the paragraph above. 

IMPLICATIONS AT THE FIRST GLANCE

The issue appears to be a failure of the inhibit line from suppressing the flip of bits 7, 9 and 11 to the 1 state. In every write cycle, the X and Y axis currents will flip every core to a 1 state. By having a counter current in the inhibit wire, that specific bit does not flip and remains at the 0 state it receiving during the preceding read cycle. 

However, the correlation with ranges of addresses makes me think that the core memory is just out of adjustment enough that it is marginally working. Certain wires through the core planes have just a bit more current - the address range correlation is why I suspect this. The inhibit current is right on the fringe and when it is working against the slightly higher current of some of the address lines, it fails to block the flip of the core. 

ADJUSTING CORE MEMORY IS A COMPLEX PROCESS

The brief summary of the adjustment process is 22 steps long, involving setting voltages, measuring temperatures,  adjusting various settings while watching oscilloscope traces, and some differential voltage measurements. 

ALSO NEED TO CHECK WIRE WRAP THAT EFFECTS L2 AND N4 SLOTS

The cards involved in some of the error bits show some wire wrap additions on the backplane. I need to understand these, figure out if they were in compensation for some trace failure that has gotten worse, or are defects introduced as the CHI memory expansion was added to the machine.

x

1053 Operational Unit restoration work

WORKING TO UNSTICK THE OPERATION UNIT FUNCTIONS OF THE 1053

The 1053 operational unit commands the carrier return, line feed, space, backspace and tab operations. A clutch is tripped to provide rotary power for 180 or 360 degrees of the power shaft rotation. This is used to pull down on linkages near the rear of the machine that implement the operations. 

The mechanisms and linkages for the operations can have several rotating parts, spring loaded, all of which must move freely for them to restore and leave the carrier free for normal typing operations. The links that trip the clutches in the first place must also move freely, as they are restored near the end of a clutch rotation and must latch back into the idle position. 

I need all of this freed up before I can work on the character printing aspects of the machine. If it is simultaneously trying to return, tab, space and print, the results are not good. 

Repaired broken SCR pin, SBR row of display panel fully operational on LED bulbs, making more LED bulbs

COMPLETED THE CONNECTION OF BROKEN OFF PIN TO EXPOSED SCR NUB

I worked out a way to hold the broken off pin in forceps, with some tape insulation to keep it from sucking away the heat as I solder. I was able to zip tie the forceps along the PCBs of the display panel so that it held the pin directly against the exposed metal nub of the SCR. 

I had hacked away some plastic since the pin broke off flush with the surface - this gave me enough metal that I could solder to it. I practiced this with another SCR that was loose, before attempting the repair in situ on the PCB.

Broken pin was in the center of the rear face

Successful connection on the test SCR

Holding broken pin in forceps

Aligned in position ready to solder

Successful repair

SBR FULLY OPERATIONAL NOW, CAN HAVE CONFIDENCE DEBUGGING PARITY ERRORS

When the 1130 takes parity errors in the upper 4K, it displays some bits in the SBR as well as the two parity bits P1 and P2. If I have all 16 lighting up in the SBR, I can evaluate whether there is or is not really a parity error. 

Each side of the SBR, the first or second eight bits, has its own parity bit. The scheme is that the eight bits plus the associated parity bits must have an odd number of 1 bits. If I see that the bits are indeed odd for both halves, then the failure is a false parity detection driven by some more subtle error. If I do see that the parity is even in one side or the other, I can perform lots of reads and writes to detect a pattern as to which bit(s) tend to have the issue. 

BUILDING MORE LED BULBS

My nemesis, the IBM 1130 display panel interior

Each time I can force myself to sit down at the soldering station, I convert more holders to LED bulbs using the labor intensive process I worked out. I don't even have enough LEDs and resistors for the entire panel worth of bulbs, but the needed parts are on the way and should arrive in a couple of days. 

Start with an LED

Tie a resistor on one lead

Solder the resistor to the LED lead

Trim off the LED and resistor unwanted leads

Line up some 26ga bare wire

Solder the wire to the other LED lead

Cut off the excess LED lead

More 26ga wire to attach to other end of resistor

Soldered wire onto resistor

Trim off resistor lead

Insert into nylon bulb holder

Lock wires into holder

Trim off excess wire

Manufactured more LED bulb replacements; still hate display panel design with a passion

CONTINUED THE LABORIOUS PROCESS OF BUILDING THE BULB REPLACEMENTS

I removed wire lead remnants from holders. Then I soldered a 470 ohm 1/16W resistor to the + LED lead close to the diode, cutting off the remainder of the lead. A 26ga wire was soldered close to the diode on the - lead and the original LED lead snipped off. Another 26ga wire then was soldered to the other side of the resistor, close to its body, with its remaining lead snipped off. The assembly is fed into the nylon bulb holder. The 26ga wire ends are snugged against the side notches of the holder and cut short.

This was repeated 20 times today as I built up toward my goal of a full set of replacement bulbs for the machine. I would pull incandescent lamps, many of which I had originally borrowed from my own 1130 lamp assembly when I began the VCF machine restoration. My lamps were restored to my machine.

I removed and held onto any incandescent bulbs that were still working, with intact wire leads. The holders were thus emptied and ready to be used for replacement bulbs.

STILL HATE THE LIGHT PANEL DESIGN OF THE IBM 1130

The design of the display panel makes changing bulbs a very fussy and challenging task. The thin PCB with a group of up to sixteen bulbs attached is soldered to heavy wires on one side with little slack. It is barely possible to slide the first bulb out of the honeycomb cell because the wiring is so taut.

The attachment of the nylon bulb holder to the PCB is via a pair of pins. One is on the end of the SCR and the other is flexibly attached to the PCB by a pigtail. It is difficult to push the flexible pin into the holder at the same time that you are pressing the SCR's pin into the same holder. 

Because of the flexible lead and the circular nature of the pins, the holder can and often is rotated a bit off plane. Each of the sixteen holders can end up with its own rotation and bend off axis from the honeycomb cell it must enter. Therefore, it takes quite a bit of wrestling, shifting the board various ways, until you can coax all the holders into their cells. Often it takes a screwdriver to force one or more holders into alignment. 

Finally, the signal lines slide over a narrow pin on the rear of each SCR. The act of moving boards around to change bulbs puts stress on these and they can get bent over. There is considerable risk that one of the pins can break off of the SCR, rendering it incapable of displaying that signal. 

As previously discussed, the incandescent bulbs have a tendency to have their wire leads snap off at the glass envelope. This can happen as they are twisted or bent during the act of inserting the PCB row into the honeycomb, but it has become much worse due to the corrosion of the spot where the wire enters the glass envelope as a consequence of aging. 

I had designed and installed an entirely different mechanism to hold incandescent bulbs in place behind the honeycomb - it is installed on my personal 1130 as well as the machine owned by the System Source Museum. The frustration with the IBM designed parts drove me to this and many others have fought to a standstill with the lights of their own 1130 systems. 

LOST AN SCR PIN WHILE WRESTLING THE SBR BOARD INTO THE PANEL

I populated the entire 16 bulbs of the Storage Buffer Register (SBR) with my LED replacement bulbs because it is essential I see the exact pattern of bits coming from memory as I debug this system. Having failed lamps in the SBR was a problem, and each pass changing incandescent bulbs introduced a few more snapped wire leads in other lamp positions. 

During the process of wrestling the PCB, I had to pull against the wiring, bend the board against the wires enough to have the first bulb holder enter the first honeycomb slot nearest the wires. It then had to contend with the rotated and off axis holders, moving the PCB left, right, up and down as I tried to get all sixteen holders to fit into the honeycomb. 

The signal wires that are plugged into the rear pin of the SCRs are easy to grab or move as you fight to get a good handle on the PCB for all the maneuvering. Sadly, one of the pins was bent one time too many and snapped off right at the surface of the SCR. 

Spare SCR where I broke off the pin (center)

PREPARING TO SOLDER A PIN BACK ONTO THE SCR TO RESTORE FUNCTIONALITY

I dug out some of the hard plastic that encapsulates the SCR assembly to expose enough of the pin metal inside the part that I could solder to it. I took a damaged SCR from my parts supply and tested the process, having snapped off the pin and then excavated before soldering. I was able to form a good connection between the broken off pin and the exposed nub. 

Repair successful

I am loathe to pull the board out again to work on the SCR needing the pin repair, so I am working out a way to hold the broken pin in place behind the PCB as it sits in the display panel, allowing soldering. The mechanical aspects of securing the broken pin and placing it in contact with the nub remain a challenge, but I am comfortable there is enough room to do the repair once I figure out the holding method. 

Holding broken pin prior to soldering

Replacing bulbs that are out - three steps forward, one step back

FAILURE MODE OF VINTAGE WIRE LEAD INCANDESCENT BULBS

The display panel of the IBM 1130 is similar to those used on the earlier 1401 system as well as the low end models of S/360 such as the model 30. A frosted panel has incandescent bulbs behind it, fitted into a plastic honeycomb that separates and holds the individual lamps. 

IBM uses bulbs with two wires extending out of the glass envelope. They are fitted into nylon holders so that pins can be pressed into the holder's bronze cylinders to make contact. When a bulb burns out, it can be removed from the holder and a replacement inserted. 

However, the point where the wires enter the glass envelope is susceptible to corrosion and failure. As these have aged, many of the wires snap off clean at the glass surface. Often both wires snap off because the corrosion  attacks both equally. 

The Lamp Test function of the 1130 lights all the bulbs, allowing a quick identification of which lights are not working. There were about 20 or 25 that were not working when I checked this morning. Bulbs are mounted onto long thin PCBs that hold up to 16 individual lights. The entire group of up to 16 has to be pulled out of the honeycomb in order to change one lamp. 

When I look at the lamps I removed, most have failed due to the wire breaking off the envelope. For example, here are the few bulbs that are actually burned out, followed by a picture of all the bulbs that failed due to broken wire leads.

Bulbs that won't light

Bulbs whose wires broke off

EACH INTERVENTION TO CHANGE BULBS CAUSES MORE TO BREAK THEIR LEADS

For example, if I pull out a group of 16 to replace two bulbs that were not lighting, when it is put back into the honeycomb some others, previously working, will have failed. Thus, if I attempt to replace every nonworking light position, invariably when I check at the end there will be new dark lamps. 

LONG TERM SOLUTION IS TO REPLACE ALL WITH MY LED BASED BULBS

Only by converting all the bulbs to the LED versions can I stop the failures and keep the display panel fully operational. I am building the new bulbs as fast as I can.

BUILDING LED BULBS INTO NYLON HOLDERS IS A SLOW LABORIOUS PROCESS

Because the leads passing through the bronze cylinders have to be very thin, thinner than the leads of LEDs or resistors, I have to solder 26ga bare wire to the leads of the LED and resistor, making the original lead as short as possible. The original leads and resistor have to fit in a relatively small space inside the nylon holder and the transition to 26ga wire has to be complete before it enters the bronze cylinders. 

I also have to prepare the nylon holders, which invariably have broken off wire from the original failed incandescent bulbs. This wire must be removed first before I can install my LED assembly into the holder. 

I am able to complete about 10 to a dozen LED bulbs per hour. There are a bit under160 lamps in the display panel, thus it will require about 16 hours of time to complete all the replacement bulbs. 

Still on the fence about LED bulbs, but can move ahead for now

POWERED UP THE 1130 WITH A FEW OF MY REPLACEMENT BULBS

As you can see, they don't look jarring, but you can clearly see the difference. Bits 0, 1, 9 and 15 have the LED based bulbs installed, the rest are original IBM incandescent types. The new bulbs are brighter and a bit yellower. 

Began restoration of 1053 typewriter for VCF IBM 1130; might need brighter LEDs for the console

1053 CONSOLE PRINTER REMOVED FROM MACHINE AND PUT ON WORKBENCH

I pulled the signal and power SMS paddle cards from the 1130 and removed the printer. I brought it over to a workbench and removed the cover. With a hand cycle tool installed, it is ready for restoration. My initial visual inspection shows a machine in very clean shape, suffering mainly from solidified lubricants and disintegrating soundproofing foam. 

LUBRICATING FROZEN JOINTS AND GETTING THINGS MOVING FREELY

I began applying the ultra fine clock oil on every bearing and joint,  basically anything that has to move, in order to free them up. I worked each part to restore its normal range of motion and eliminate the friction of the old lubricants. 

There are thousands of parts that move in a Selectric mechanism, so this is a slow process but one that has delivered success many times before. Some parts are hidden deep inside with other mechanism blocking access - these are the most challenging to address. At worst case, I partially disassemble the machine to secure good access. 

TRANSPORT PULLEY HAS FAILED, A COMMON ISSUE WITH THE PLASTICS IBM USED

IBM built a few parts for Selectric using a nylon-like plastic. For the most part, these lose their plasticizer over the decades, shrink and eventually crack. Fortunately this does not impact the type elements ('golf ball') probably because the nylon is plated with a metallic coating to convince customers they are worth the relatively high prices that IBM charged. I suspect that this slows or blocks the outgassing of plasticizer. 

The main hub often develops cracks, producing a thump-thump sort of sound as the machine run. The other part that commonly fails is the transport pulley, a spring loaded pulley that keeps tension on the rope cords which pull the carrier left and right during typewriter operation. This was clearly broken on this machine. I have ordered a replacement and will swap it for the bad part once it arrives. 

NOT SURE THAT THE LEDS I USED WILL BE SATISFACTORY

I am still undecided about the LEDs I chose for the substitute bulbs. They are dimmer and more yellow than the incandescents. They will never look identical - if matching when statically lit, when the machine is operating with signals flickering on and off, they will be too bright compared to the fading of a traditional bulb. I am just looking for a result that is not immediately obvious and jarring. If it requires someone's careful examination to detect, that would be more than good enough. 

Building incandescent lamp replacements using LEDs

ADJUSTED RESISTOR VALUE TO 300 OHMS FOR BRIGHTER LAMP

After comparing the LED bulb to incandescent bulbs side by side on the SAR board I put on the testbench, I decided to decrease the resistor value from 470 to 300 in order to get a more comparable brightness with my substitute bulbs.

SIZE OF LEADS PASSING THROUGH NYLON HOLDER DETERMINES TIGHT FIT

The nylon holders have a bronze cylinder into which a metal pin is pressed to fit when the bulb is installed on the SCR. The wire lead incandescent bulbs that IBM uses have very thin leads which allow the pin to fit into the cylinder and compress the wire. 

The size of the LED leads is relatively enormous, completely unsuitable to pass through the cylinder because the pin can't be pushed in at all with that large wire cross section. Even the leads of the 1/8W resistors I am using are too large to allow for acceptable fit of the pins into the bronze cylinders. 

MY SOLUTION IS LABOR INTENSIVE BUT WORKS

I am using some 26 ga wire to pass through the cylinders. I have to solder the wire to the resistor and LED, having cut off most of the leads from those components. It is a fiddly process but I have been able to create half a dozen test bulbs that fit onto the pins about the same as the original IBM incandescent based bulbs. 

LIVE TEST WITH SAR AND CARRY/OVERFLOW UPDATED BEFORE I BUILD MORE BULBS

Once I have the SAR board resoldered into the display panel and populated with a few of the LED replacement bulbs, I will do a power on test and compared the results. Assuming they pass muster as they are now, I can then dive into the tedium of manufacturing several dozen replacement bulbs.