They have a small machine, 4K or 8K, with the Garnet Rose color scheme offered by IBM during the S/360 and 1130 era. The other common color was Classic Blue, but rarely you could see a color such as the Sunshine Yellow that my personal 1130 sports.
DIAGNOSING WRITE-PRINT PROBLEM WITH IBM 1401 AT CHM
The 'German' 1401 system at Computer History Museum has a problem when rapidly reading cards and printing their contents on the 1403 printer. After some number of cards, the 1402 reader will enter a Reader Stop check condition.
We have a tight hand program which is very reliable in causing the check condition - read, print, read, print, read, print, read, halt - which will fail on the last read command virtually every time. This has been helpful in scoping signals to find the cause.
After working half a day on Monday, we narrowed the problem to one part of the Reader Stop circuit - not the card jam detection or other portions, but the part that ensure that the reader responds correctly to a read command.
To verify its operation, the reader compares the state of two relays, clutch check and read cycle. If they don't agree, it would mean that the CPU requested a read but the 1402 didn't move, or that the 1402 has moved a card but the CPU did not request it.
There is a resistor-capacitor network on the line to the reader clutch magnet, which delays when the clutch activates. The same activation signal goes directly to the Clutch Check relay. This means that Clutch Check is active while the mechanism begins its 360 spin of the cycle wheel.
Once the wheel has moved a bit from the idle position, it activates the Read Cycle relay. Then, later in the rotation, microswitches on cams cause the circuitry to compare the two relays condition. If they don't agree, a Reader Stop relay is engaged and the 1402 enters the check condition.
Disconnecting parts of the Reader Stop relay pick coil circuit, we isolated the stop condition to the circuitry looking for disagreements between the Clutch Check and Read Cycle relays.
To verify this, we removed the Clutch Check relay from its socket, which not only stops it from activating but also removes contacts necessary to detect the error condition. The reader ran without any stops in this condition.
We will need to do more testing to discover which case is being detected - which is engaged and which relay is inactive - but that will wait for our Wednesday work session. There is something about the delayed request for reading from the processor that triggers our error, but we don't yet know the details.
Why is the read request delayed? It is because of the relative timing of the printer and card reader, such that the last read command in our test program is occurring while the printer is copying its line of data from core memory. Since reading cards requires access to the core memory in real time matching card movement, the reading must be delayed while the printer logic is touching memory.
The printer in our installation has a speedup feature called a print buffer. Thus, when a print request is issued, the logic first copies all 132 characters of the print line from core memory and stores them in a special dedicated but small core memory. It requires about 2ms to copy the 132 characters over, after which the core memory is free for the long additional time it takes to fire printer hammers and space the paper.
In our test program, the 2ms transfer of printer data is underway when the last read command is issued, thus the CPU will block the read request from the card reader until printer transfer is complete. Thus the start of the read request to the 1402 is delayed a bit compared to the preceding read commands.
No comments:
Post a Comment