Sunday, November 2, 2014

Mostly keypunch interface testing and wiring of SAC interface cards today


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.


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.


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.

No comments:

Post a Comment