I worked on the program to drive the keypunch interface - it is written in Python (because I like the language) and will serve as a reference for using the interface if other users want to write their own code to accomplish specific tasks with a keypunch.
This program will open text files on the PC and punch their contents using the keypunch. It offers some rudimentary error checking of the files and the ability to restart from a specific card image after jams or other problems arise. In addition, the program will read cards from the keypunch into a text file until the user tells the program that the last card has been read.
I am documenting it sufficiently that someone who doesn't know Python can still understand the flow and how you would use the keypunch interface box, although they would then have to code it up in their choice of language without a template like mine to copy.
I built the overall program structure, but not the file read/write functions or the protocol with the interface box. It was time to finish for the evening so I put it aside for another day. The code is in Python, using pySerial to control the serial stream and likely will make use of wxPython to give it a modern GUI.
DATACENTER SHED CONSTRUCTION
The seller of my shed is redeemed, now that I have figured out the touch and snapped in 40% of the walls in just a few minutes. The final floor tile piece is still too stubborn to interlock, but I will have some help tomorrow and get it sorted out. I had to stop with the walls when I reached the missing floor tile, otherwise I would have had all the walls installed in short order.
CHM 1401 RESTORATION WORK
I went to the Computer History Museum in the late morning to help out with some of the recalcitrant machinery. We were working on a pesky problem where the 1402 Card Reader/Punch would sporadically signal read checks on column 49, although the data entered into memory and the card itself were fine. Further, the brushes and everything else we could find seemed to be working properly.
A few of the team members hooked in a temporary fixture to the 1401 which would reverse the read and check brush inputs. The reader has two sets of brushes, each of which sends it character to the reserved memory location (the reader uses locations 1 to 80 in core, specifically location 49 for the failing column). If the two don't compare equal, a reader check is raised. The error could be on either set of brushes, the check is just to ensure they match.
However, the machine didn't work when they powered it up. It was displaying storage errors even through we saw valid data coming out of memory. We began working through the logic diagrams and putting various signals on the oscilloscope to determine where the problem was originating.
At some point as we opened logic gates, inserted probes and checked signals, we opened a logic gate and as one of the members was pushing on the probe, we spotted that a number of the backplane pins, where the wirewrap connections are made, were bent over with a couple shorting to each other.
After powering down and straightening out the pins, we brought the machine up to find our storage problem gone. A power cable for a cooling fan was curving into the space where our logic gate fits when closed and the cable was what snagged and bent all the pins in an arc at the corner which struck the cable. The cable was moved out of the way and secured with a cable tie, to ensure this didn't happen again.
We ran some code and tests successfully , then shut it down in order to go up to a conference room for the group lunch. After a quick meal and some conversation, we went down to the machine. The jumper fixture to reverse the check and read brushes was reinstalled by another member and when we powered back up, we had a new storage problem. Nothing was going into or out of the first 4K characters of memory. A quick look reassured us that the pins were okay.
We began tracing logic and checking signals for this new storage issue, which after an exhaustive verification showed us that the control, data and timing signals were operating correctly. To test further, we had to verify that the cores were actually being driven to flip state, the central process behind core memory. However, these lines were current driven, thus no voltage swing was there to monitor with the scope. We would need to begin sensing with a current probe.
Not having one handy, we began to clean up and leave the machine for the next day when team members would be in to service it. The special fixture was removed that swapped read and check brushes, when someone decided to power it up one last time. It worked again! We have a definite problem in the fixture, which is an approved service tool that has been used by IBM engineers for decades to debug 1401 systems.
Something is definitely wrong with the fixture - we will sort that out next time, when we also try to dig into the read checks on column 49. I will be away on a trip next week but there are quite a few other team members who will be in and working on this. Sometimes the problem is not the machine, it is the tool! Good to remember.
Meanwhile, the card punch on the other 1401 system had been getting punch checks due to skewed cards entering the machinery, but someone spotted a missing screw on the throat bracket that allows just one card to enter per cycle. Replacing that resolved our checks, giving us a 1402 that read and punched just fine.
No comments:
Post a Comment