Wednesday, January 10, 2018

Diagnosing 1401 read-print issue, getting Fortran compiler running on 1401


In preparation for our session on Friday, I drove all the previously archived cartridges over to PARC and exchanged them for 25 new ones. These were the top picks from a prioritized list of the 75 remaining cartridges from their database of disks. The expectation is that we can complete a batch of 25 in a week or so, then exchange those for the next group.


Both Ken and I brought in modern scopes to help shoot the problem, but we are still not certain we know the precise failure mode, due to the complexity of the 1402 card reader logic. That logic is implemented with relays, cams and microswitches, but as IBM added new feature after new feature to the unit, they took the easy way out with schematics. 

Rather than redrawing circuits to keep it clear, IBM added many, many off-page connectors for these changes such that tracing out the real circuit is extraordinarily difficult. Thus, we have a hazy idea of how the machine is actually functioning, with more than forty cams, about fifty relays, perhaps 80 diodes, and each relay has four to six independent sets of contacts. 

By the end of the day, we had narrowed our focus down to a pair of cam switches, RC6 and RC7. These are running continuously as long as the motor of the 1402 is spinning, while other relays named RL# operate only when the clutched part of the mechanism is rotating - during the feeding of cards. 

RC6 is the main timing point determining when the request from the 1401 will activate the clutch magnet. This happens at three equidistant spans around one 360 degree rotation of the motor wheel. As RC6 allows the processor request, first the pick coil of relay 10 (Clutch Control) is activated and then after a short time delay through an RC network, it activates the clutch magnet.

The clutch engages and begins moving the feed mechanism through its rotation, moving a card from one station to another. The stations are feed hopper, read check, read and stacker. Cam RC7 is set to complete a circuit during the intervals in between the three that enable clutching. Cam RC7 sets up the error check, where relay 10 is on if the processor requested to clutch but off otherwise

The Reader Stop condition occurs because the error check time determines that the clutched mechanism did not rotate, the feed relay 6 is not activated, but relay 10 is on. Essentially it tests to see if relays 6 and 10 agree, but only during the time that RC7 allows the check. 

RC6 and RC7 have only a 5 degree separation between their active times. For example, RC6 should switch off at 102 degrees and RC7 turns on at 107 degrees. When we checked the timing of RC7, it was turning on early, at 105 degrees. Another test seemed to show that RC6 is working late, turning off at 105 degrees. 

This overlap of RC6 and RC7 sets up a race condition where it is possible to falsely detect a failure to engage the clutch when in fact the reader is working properly. We will adjust the two cams to increase the gap between their operation, in our next Wednesday session. There may be other cams involved in this failure as well. 


Marc Verdiell and Mike Albaugh have been working for a while to produce a working tape of the 1401 Fortran II compiler. It is a 63 pass compiler (!) that will work even in a small memory system. Having overcome the final barriers they were able to compile and run a few sample programs today. 

Next up for the team is to accomplish this with an enhanced Fortran II compiler, a Fortran IV compiler, a Cobol compiler and hopefully RPG if we can locate that software. We also have a card oriented FARGO program to get running. Fargo was a predecessor to RPG, both of them are meant to make it easy to replace plugboard based accounting systems. 

No comments:

Post a Comment