Saturday, August 30, 2014

First 8K of memory now working perfectly, plus other progress on 1132, 1442, and 1053 - Aug 30, 2014


I went through voltage verification and other tests first to be sure core is within its proper supply range and adjusted right.I found a few of the logic voltages just a bit out of spec, so I got serious about adjusting my voltage regulators. I wanted an extremely accurate meter, since the specs for some of the voltages require it to be less than half a percent.

I borrowed one from our restoration team workroom at the Computer History Museum and made sure my main logic voltages, +3V, -3V and +6V, were as close to perfect as I could tweak them. The 12V and 48V voltages don't have adjustable regulators, instead relying on ferroresonant transformers, but were well within spec as they were.

The issues were exactly as before, but I had ruled out voltage supply problems. My diagnosis a few days ago was that the parity errors I was getting in the first 8K of memory were caused by a failed circuit on a 5803467 SLT card (also referred to as 3467) sitting in the H3 card slot of B1 compartment of D gate. To confirm, I did some swapping of this 3467 card with others in the same compartment. When I swapped it with the K3 slot, the failure symptoms changed exactly as they should if the card were at fault. Now, addresses of the form xxxx xx10 0xxx xxxx receive parity errors.

To further confirm, I moved the bad card to the M3 slot, which would move the error to address patterns of xxx1 00xx xxxx xxxx and that was exactly what happened! My final swap was to swap the cards in M3 slots of the two compartments, A1 and B1. That moved the failure up to the high 8K of memory. I verified that the first 8K of memory worked perfectly.
D gate (core memory) each compartment is 8K
I have a different problem in the high 8K of core - bits that are reading as on even when they were written as zeroes. For example, bit 5 is always a 1 when a word is read, but if may have been intended to be zero, thus storing incorrect parity. On top of that problem I have the bad 3467 card I moved over from the first 8K compartment. I need to do some very thorough testing to define the exact failures and what address ranges they pertain to, in order to identify what portions of the core and what cards are presumably bad. I will do that tomorrow, after perusing the ALDs some more tonight.


I now have my Mobil synthetic grease (Aviation #28) to use on the card reader, printer and typewriter mechanisms. I am working with the lubrication recommendations from the 1442 maintenance manual, but this is a slow process. First, I need to identify what has to be lubricated, when the name they give is not labeled on any diagram and may be a synonym of the name used in the parts catalog. Then it has to have the dirt, dust and old grease removed before I can lubricate it.

The machine sounds better already, even though I am not done lubricating; I only got through about half the moving parts. I still can't get the machine to go into ready state - it has only done that two times out of a few hundred NPRO cycles and pushes of the start button. I am going to have to do some diagnostic testing to be sure where the issue lies - it could be logic or cabling in the 1131, logic or cabling or switch problems in the 1442, or problems with the signal cable linking the two.

When I manually trip the feed clutch, it does nicely feed cards through the preread, read, punch and stacker corner stations. For some reason, cards aren't nudged into the stacker mechanism rollers so they will pile up  in the corner station. Cards slid toward the rear of the machine from the input hopper (into the preread station), then move right to left to be read and punched before arriving in the stacker corner. From the left rear corner, the then move forward on the left side and drop into one of the stackers.


I worked out programs to test the printer from the processor - code to space a line and to print a line of type. I used Brian Knittel's 1130 simulator to assemble the code and do testing, so I wouldn't spend too much time toggling in code by the console bit switches and mode switch. I wasn't able to test the actual operation, because the simulator declares the XIO to be an error, although the live machine had no problem with them. Not sure whether it is a limitation of the simulator or some more subtle issue in how it emulates the printer, but I had what I needed to move into the garage and try it out on real hardware.

Early and incorrect assembly of program to print a line
I powered up the processor toggled in all the code, but then found that the printer wouldn't power up. It was because I had shifted the 1130 slightly on its rollers, which pulled the power cable for the printer out of the socket - due to the missing threaded hole on the socket. I powered down, inserted the power cord, and the printer came up properly.

The first version of the code did a carriage space - move down one line on the paper. Worked perfectly. That is excellent. I know now that the device sees the XIO commands, it decodes them correctly, drives the printer, and provides status on interrupt level 1. The only function this didn't involve was the cycle stealing that the printer does to fetch the fixed eight bytes to fire hammers, nor the character by character interrupts from the print wheel and the read emitter operation that determines which character it was.

The next version of the program should print a line - my first name two times - but the printer gave a printer scan check error. I put this aside to work on later, but tonight I remembered that I have to set a specific bit in the word at the end of the scan area (addresses 32 to 40, last bit of word 40 must be a 1) otherwise the print scan error is given. The program may well have worked.


The cycle clutch latch piece I had removed had a spring attached to it and to a bracket inside the machine, but the spring broke off from the remote bracket. I have comparable springs to replace it, but getting access to the bracket where it attaches is going to be challenging.

Broken spring from cycle clutch latch
I did a bit of greasing with my Mobil 28 and did a power on test of the belt. Under power, the machine continuously does line feeds (indexes) and it continually types a default character (because the cycle clutch latch is not installed yet). All good for the state this is in and where I am in the rehab process that eventually restores full operation of Selectric mechanisms.

Bit of grease (red color) in the bearing till full
The machine has a feature to select black or red ink under program control - using a ribbon that has one color along the bottom and the other along the top. The tape that threads over multiple pulleys to move the ribbon up or down was broken when I got the machine. A friend I have previously worked with on other Selectric based machines is sending me the proper replacement tape from his shop in Switzerland (Lukas Tschudi of TSCHUDI B├╝romaschinen). 

Remnant of ribbon shift tape

Parts catalog with ribbon shift mechanism parts listed
Peter Vaughan of The National Museum of Computing in the UK, who has restored an 1130 in their collection, sent me a wonderful chart that gives modern substitutes for all the mystery IBM lubricants - always referred to simply by a number like IBM #23 or IBM #10. I knew of the equivalence of Mobil Aviation Grease #28 to IBM #23, but this gives me great alternatives for many other types as well.

No comments:

Post a Comment