More keypunch debugging, further assembly of the SAC interface box, and an interesting test tool

I had to visit the Consulate of China to apply for a visa for a stopover I will make in December in Shanghai. Two hours round trip to get there plus almost two hours waiting to file my paperwork - all valuable time taken from the 1130 restoration.

Maglev train in Shanghai

My visit will only be a couple of days but one of the things I am looking forward to experiencing is the magnetic levitation train that runs from the airport to a transportation hub. It will reach a peak speed of 430 kph (about 270 mph) - it will feel like a trip into the future for an old science fiction story fan.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I did more testing and validation - still having problems getting the timing right for the read of a card going through the dup station - but the rest seems to be working perfectly. I spent time with the keypunch documentation and derived some relative timings but they don't work in practice.

Interface being debugged

The activation of any hole magnet or the space magnet causes a set of contacts to close which energizes the escapement relay in the keypunch. Supposedly, it takes 12 milliseconds for the card to move to its new target column, after which the punch clutch is triggered starting a punch cycle.

The punch cycle is 50 ms overall, with the pins at their best point to sense at 17-18 ms into the cycle. Based on this, I assumed that the cumulative duration  is 12 + 17, thus if I read the pins at 30 ms after I trigger the punching for the column, it would be the right time. However, the pins are not extended enough to make any contacts, registering every column as containing a space.

My earlier experiments found non-space results at 40ms and 60ms after I trigger a punch, not the 30ms I used which failed. I will work on this more deliberately tomorrow, identifying the range of times when the pins show good results.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I finished the corrections on the first board, installing the replacement resistors for those positions where I had mis-installed the pairs backwards. In addition, I have eleven sets of driver and receiver circuits assembled on the third board, just one more to go. One more board will be needed to hold five more driver circuits. A bit more soldering of components, then wiring of power and TTL signals to the boards, and then I can test these out.

Boards one, two and three from top to bottom

IBM IPAT TEST TOOL KIT

I found an interesting looking tool on eBay, a suitcase unit used by IBM labeled the IPAT 5800 unit. I saw some bus and tag terminators along with ribbon cable, which made it appear to be useful for some kind of IO channel testing. I was able to get it for a low enough price to be worth the gamble.

Inside the briefcase

Control panel - selecting cable, lines and a few test types

Chart to interpret distances of malfunctions

The unit sends pulses down various lines in the cables, displaying on an oscilloscope and allowing the identification of the type and location of any problems - break in a wire at xx feet along the cable, or short or open instead of proper termination - designed to work with 360 style bus and tag cables but also the twisted pair type cables used with the 1130 and with coax cable as used with 3270 terminals.

Keypunch interface in final paces of checkout before release of beta code, with just a few minor issues with the card reading function

Today I didn't have a lot of free time and what I did have was spent at the Computer History Museum helping out with some tape drive, card reader and power up issues on the 1401s. I also worked on a new faster way to scan in manuals which I can use to ensure all documents I have are preserved digitally on bitsavers.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I opened up the punch cable connector and replaced the treacherous pin 20 which supplies the power for the release function activation, since it keeps popping out rather than sliding over the mating male pin of the socket on my interface box. With that corrected, release worked perfectly as expected.

I next fiddled with various delays until I found I could sense the pin values consistently during reading at 60ms after the trigger of the space - I am dropping the space solenoid at 20ms after trigger, then wait another 40ms before reading the sense pin values.

I found some small flaws in how I am recording the values and displaying the resulting card image, which I will fix in the code and do some final testing tomorrow. Once I have read working satisfactorily, everything is ready and I can release this to the other project members for their testing.

Minor work done, keypunch debugging going very well

Feeling a bit better and spent a couple of hours with the machine today.

1442 CARD READER/PUNCH RESTORATION

Peter Vaughan of The National Museum of Computing in the UK has restored an 1130 system much like mine and has been an invaluable source of tips and shared experiences as I work on this machine. When I was disassembling the feed and read clutches to clean up the lubrication issues, I found a short narrow pin with rounded ends sitting in the bottom of the machine compartment.

Peter recognized it from the description, since he had exactly the same thing happen to him while he was working on the 1442. It is a pushrod that must be reinserted in the feed path mechanism. If only he could tell me where my dropped punch is sitting, all my problems would be solved.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I had very solid progress today. The binary mode works properly, as does the automatic multipunch mode. I discovered a small flaw in the code that was blocking the release function, corrected it I thought, but it wasn't working.

Continuity testing showed me that the signal wasn't getting through my interface box. The wires inside the box to the plug on my box were working, but no continuity through the cable. I finally discovered that pin 20 of the female plug had pushed out rather than sliding over and mating with the pin of the male connector on the box.

I opened the connector, pushed the pin back into place, reassembled the connector but once again, no connectivity!  Clearly the pin is not latching as it should into the connector body. The next time I work on this I will open the plug housing AGAIN, but this time chop the wire off the defective pin, toss that pin in the trash, and put on a new pin.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

The third board is now more than half done - seven pairs of driver/receiver circuits installed out of twelve. Once again, ran out of daylight or I would be done.

I began repairing the flaws in the first board - I have just five pairs of resistors left to insert. One of the pair (12K) is already installed into the +5V rail, waiting for me to open the hole and insert the other end where it belongs. The 1K resistor need holes for both sides opened and then the resistors installed. This won't take that much time until it is wrapped up.

Very little done other than root canal and bit of discomfort

Yesterday a molar began to really hurt, last night the dentist set up an appointment with the oral surgeon, and today I stumbled through my appointments on Tylenol w Codeine until the root canal was done at lunchtime. I felt okay for a short while and did a bit of soldering on the SAC interface, but now my jaw is swollen with an inch diameter bump over the tooth and I am down for the count again. Nothing is going to happen today and I hope that I can resume later tomorrow.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I corrected the flaws in the second board, which only needs its wiring now to complete it. I didn't get to the first board, which had nine pairs of resistors to replace, because I ran out of steam.

I did start board number three but only put in one pair of driver and receiver. 

Mostly keypunch interface testing and wiring of SAC interface cards today

1442 CARD READER/PUNCH RESTORATION

Still no sign of the punch that fell off the top of the reader yesterday and may, therefore, be down somewhere inside the machinery where it could do damage when the reader motor runs. Hunted on my hands and knees for a while - if it is not in the reader it must have bounced and rolled quite far, as I have examined all the straight line places it could have reached if it just dropped vertically and then rolled.

I lubricated more cams I found around the machine, meanwhile working each moving part to be sure it isn't sludged up. The read clutch spins with almost zero resistance, but there is still noticeable drag on the feed clutch. This may be normal, since it actuates so many cams that are pushing arms up and down, but I will keep at this for a while longer just to be sure it is as loose as necessary to ensure good reads.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I had moved the keypunch around in order to get better accessibility to my 1442 for its restoration work. However, when I next tried to access the new interface box, the serial link is not working properly. At startup I get a line feed but no characters visible. Input from the terminal to the box is apparently not detected at all. Seemingly a hardware problem but essential to fix before I can debug further.

The path for the user serial signal is TTL RX and TX from the Arduino out to an RS232 adapter board, which generates and accepts valid voltages (not just the 5V of TTL). A straight cable runs out of the keypunch and up to a crossover adapter. That has a USB-Serial port adapter hooked in, with the USB link hooked to a PC running a terminal program. Lots of places something could have gone wrong.

I hooked the USB link to a different PC running a different terminal program, but saw the same results. That rules out some potential causes, but it could still be the USB cable, USB-Serial adapter, crossover adapter, straight cable, RS232 adapter in the box, wiring to the Arduino, or something I did in software that somehow disabled serial port stream output.

I was seeing the startup messages on the programming link (Serial) but nothing on the serial port for users (Serial1), so I just added a short message to display how my delimiter character prints. Suddenly, nothing coming out of the programming link either. Commenting the new message out restored the output from the programming link.

This means it is some very poor behavior of the Arduino environment, where the strings used for all my diagnostic messages are exhausting the dynamic memory space causing it to lock up. It would be very helpful if the darned thing were to emit some kind of alert when this happens. I now have to move all those fixed strings over to the code memory which has plenty of room - a tedious bit of code alteration but necessary.

With the strings moved over, the program was running correctly again. I took the box out and re-installed it into the keypunch to resume my testing. Now I was back in business. When I punched a card with a simple test message, I initially thought something was wrong because I saw extra holes in the card. However, it turned out to be correct behavior.

I implemented two ascii encodings - BCD, which is the original mapping developed by Stan Paddock for the first generation of the interface, and EBCDIC. I took every printable ASCII character, found the same printable character in EBCDIC and assigned it the Hollerith code. The mapping is pretty clean, but there are a few anomalies.

There are no equivalents to the characters [ and ] in EBCDIC, The ASCII character ^ is not in EBCDIC, but IBM has a logical not character on the keypunch which I substituted. EBCDIC has a cent sign but ASCII does not, at least not in the 7 bit standard character set. I reused the [ from ascii to generate the cent sign on the punched card. This allows me to produce all 64 standard keypunch characters on the 029 with ascii that matches (other than the cent and not characters which have substitutes of ^ and [ in ascii).

EBCDIC has hollerith codes for lower case letters, even though the keypunch keys only feature upper case ones. Since ASCII has both lower case and upper case letters, I implemented the two encodings. That is what happened with my test message; I had typed it in lower case on the terminal so it used the hollerith for that. The letter T in hollerith is a 0 and 3 hole, but the letter t is 0, 1 and 3 which is what was punched.

Card starts with 'test it ' in lower case, thus not usual keypunch code

Release is still not activating - will check my wiring again - and I am fine tuning the binary punching and automatic multipunching features. More testing but everything going very well and on track to wrap up the interface code in a few days.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I added more circuits to the second board, completing it by the end of the day. After some checking, I did find two mistakes that had to be rectified, with the erroneous parts removed but the replacements not yet added.

In addition, I removed the nine pairs of resistors on the first board which I had placed incorrectly. After I open the PCB holes on the boards for replacement resistors, I can solder them in to complete the first board.

This gives me 24 receivers and 24 drivers, out of a needed 41 and 36. Technically, a few of the lines could be just terminated coming in, because I really don't care about signals that tell me to run the usage meters to bill myself. Similarly, a few of the signals from me to the 1131 can be fixed in the off or on condition as appropriate, such as signaling that my usage meter is still running.

I will do a more accurate assessment of parts supply, since I am running low on two of the resistor types which I placed in correctly in almost a dozen spots so far. To be safe, I will order a few more of each now to be sure I can wrap up the final boards.

Keypunch interface moving ahead, more SAC interface assembly and some mechanical work on the 1442 card reader/punch

1442 CARD READER/PUNCH RESTORATION

The National Museum of Computing in Milton Keynes, UK restored an 1130 system a while back. Based on the experiences they had with the 1442, I decided I too would be better off if I disassembled the card feed clutch to thoroughly clean out old lubricants. Its performance is critical to the timing of the card reading process - if it slows the card down then check conditions are forced, stopping the machine from reading the next card.

Feed clutch disassembled in center, read clutch upper left

Read clutch with belts and pulleys removed

In addition, I partly disassembled the read clutch and made sure it was moving freely. There are some cams driven by the feed clutch whose mechanisms and their pivots seem stiff. I will work on those too.

various cams on card feed shaft whose pivot arms and mechanisms need work

Part of the disassembly process had me use a pin punch to drive a pin out of the shaft;  the pin holds a pulley in place. After I had removed one pin and was carefully disassembling parts of that clutch, I heard a clunk. I couldn't find the punch anywhere in, on or under the machine. I have a feeling it shot somewhere inaccessible in the garage, but until I find it I won't be comfortably buttoning up the reader and running it.

Parts removed from 1442 in order to access the two clutches

I also heard a smaller clunk when I was hand rotating the read clutch shaft, with a small rod dropping down from somewhere. The rod has hemispherical ball ends. I am studying the parts catalog diagrams as this too much be understood before I can power up the reader. The good news is that I was able to get old gunk out of the clutches and good lubrication inside. The read clutch has a grease nipple in a location that was completely inaccessible while everything was together, but can now be used to force in new lube.

Grease nipple on card feed clutch now much more accessible

By disassembling things, I took on a set of adjustments after reassembly that wouldn't have had to be touched otherwise, but these clutches are so critical to the operation and timing of the reader that I thought it worth the cost.

Main card feed clutch latch and release

Card read clutch latch and release

I found a small roller that is frozen due to grease, part of the card feed mechanism. Most rollers I have already found and loosened up, but this one escaped my notice until now.

Little frozen roller above midpoint of picture

NEW KEYPUNCH INTERFACE DEVELOPMENT

After some investigation I did find out what was causing my flaky failure to recognize a registered card, as well as the reason that my initial testing of the ability to read cards was not giving me any valid hole values. My relay contacts were oxidized - slightly but enough to cause erratic results for the Card Lever relay which determines that a card is registered, while the Dup 3 relay that switches the sensing pins for reading during duplication were oxidized as open circuits.

I used some contact cleaner which claims to not damage anything nor to leave residue - a version of Deoxit without the lubricants or 'protectant's of the other Deoxit varieties. I got good values for both N/O and N/C contact closures on all poles, reinserted the relays and verified correct operation of the keypunch while disconnected from my box.

I then inserted my box and again verified that I could do everything with the keypunch, no odd behavior while I was connected. Finally, it was time to hook up a terminal and see how the interface works. I was able to command the unit and continue with the debugging of the interface.

I found an error in how I was error checking one command while in short verb mode, found that the release is not taking place at the end of a punch, suspect that two character encodings in my ascii table might be wrong, and am still not happy with how my binary mode logic converts four hex digits to a variable I later use for punching. I began looking at each and clearing them up.

I corrected the error checking bug, suspected that the release solenoid needs 20ms just like the space and row solenoids so adjusted it, and looked at the encoding issue. I discovered that the ascii to card code table which is a duplicate of the encoding from the original interface built for the 1401 project, is using a BCD character equivalent which prints differently on an 029; the 029 uses EBCDIC encoding of the hole patterns.

I decided that we need two standard tables for ascii translation, one to the BCD characters and one for the EBCDIC patterns matching ASCII printable characters as would be viewed on a terminal program emulating an ASCII device. ASCII itself has a separate encoding of card holes which we won't be implementing since this is not usual for the IBM computer environment and it could be handled by the USERTABLE option if needed.

I will build two tables BCDtable and EBCDICtable, adding a command for selecting which is invoked in MODE ASCII. The command is CODE BCD or CODE EBCDIC. The code is added and part of the testing underway. .

Testing continued, resolving the error checking bug and cleaning up the binary mode issue. Since the encoding is correct, but spurred a design enhancement, it is considered closed. The release is still not working and I found a couple of subtle flaws to clean up in the code. Looking at the release, I suspected the wiring but also the Release relay given the oxidation problem I had with the others.

Ran out of time tonight but making good progress on the keypunch interface. Hopefully the reading of the holes at the second station is not being blocked by oxidation on the sense pins, otherwise I will have to open up that station and clean up the contacts.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I  hooked up the TTL input and output leads to the first board. That one only needed the twisted pairs soldered onto the driver or receiver, as relevant for the direction of the signal, to make it operational.

I began a second board, but after three sets of circuits noticed I had made an assembly mistake on a number of the receiver circuits on the first board, swapping the position of a 1K and a 12K resistor. Sigh. I will have to clip them out, reopen the holes and then solder in replacements for the 9 bad circuits. I began by clipping and raising the faulty resistors.

Completed board but with misassembled resistors along bottom row clipped off and twisted up for replacement

Still battling the keypunch, stalemate tonight, plus more assembly of SAC interface boards

NEW KEYPUNCH INTERFACE DEVELOPMENT

After going over the inside of the keypunch and bending various SMS socket pins and relay panel pins to ensure there are no unintentional shorts, the keypunch appears to be working just fine by itself. I finished wiring up the new keypunch cables I began with better, more secure connectors and larger gauge (lower number) wire. I dressed it well along the panel and made the cable much more bulletproof and production level.

New reader cable DB25 plug - rugged wire bundle

Reader and Punch cable wiring dressed in place on back of wire relay gate inside keypunch

My reader (white) and punch (red) cables ready to plug into the interface box

In addition to replacing the cables and dressing them along the keypunch relay gate, I wired the power brick into the power supply so that it is switched on with the main keypunch power switch under the table. Finally, adding a DB9 extension cable to run up out of the machine, I now had the means to put the box inside the keypunch ready to close up the interface cover once debugging is complete.

Power brick cable converted to lugs to attach to the 029 power supply

Testing resumed but the keypunch is stuck in its state of refusing to recognize a card was registered. I will check over my wiring a bit but I am beginning to suspect this is just erratic operation from relay contacts that still have a bit of oxidation on them. However, I will also recheck the wiring to be sure it is correct.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I assembled more receiver and driver circuits onto the board today. I was able to finish one board and have three more to do. It is slow going to make sure I do it correctly. It has the +5V, +3V and ground power lines attached but does not yet have input or output leads.

One completed board for SAC interface, 12 drivers across top and 12 receivers across bottom

SCANNING COBOL PROGRAMMERS GUIDE MANUAL

Several manuals are not available on bitsavers or other digital archives, but should be. I slowly (and I do mean slowly) get the pages scanned in between other activities. This manual with more than 180 pages has taken three days elapsed time so far and I am still only at page 150. I don't usually comment on the scanning but realized it was completely sub rosa if I didn't.