Polishing up the keypunch interface software and documentation

I visited the Computer History Museum mid-day Wednesday to meet with my fellow 1401 restoration team members, on top of a full day of job-related tasks, but did find a bit of time to put into the 1130 restoration anyway.

At CHM, we finally made progress on a troubling intermittent problem with the 1402 card reader on the 'Connecticut' 1401 that intermittently throws off reader checks. While most of the work in past weeks has focused on mechanical parts and adjustments in the card reader, we traced the issue to spurious additional read pulses issued by the 1401 processor that confuse the reader which has not yet completed a read cycle from the initial pulse.

This was clearly coming from the processor, but the ultimate cause is not yet nailed down. We traced the signal problems back further and further into the machine, but had to stop work when it was time for the scheduled demonstrations of the systems at 3PM. When we next work on the machine, we can trace further back to see what is causing the problem.

We see that the processor, which should be resetting the read command trigger once the cycle begins is occasionally staying active for extra cycles, long enough for the processor logic to emit additional read pulses to the card reader.

Work was extremely heavy on Thursday - never got into the garage today.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I created a punched card as an icon and assigned that to the program. I then shot a short video of the program operating and punching cards, which I uploaded to YouTube and cited in the project on GitHub. Finally, I wrote more in the User Guide, part of the interface box protocol and some of the reference information such as encoding data that users will need.

Two cards punched by the demonstration on the YouTube video

   The video is here: New keypunch interface punching cards from a PC file

I spent the evening Thursday updating the User Guide and polishing the code. I had found a small problem with reading cards - which worked fine but the resultant file had spurious carriage returns added, thanks to Windows intervention behind the scenes. I made a tiny change to open the output file in binary mode, even though it is a text file containing only ASCII, because that disables the unwanted conversion of the end of line.

I spoke with one of my collaborators on the keypunch program, deciding whether to change the BCD encoding to include more BCD characters, such as Word Seperator. The main use of this mode will be the CHM accessing files they already built, which makes this a legacy compatibility mode. As such I won't extend BCD mode. If other characters are desired, they can be added on the fly using the _LOAD commands to the interface box before punching a deck that includes the additional characters.