Once the shift interlock was working properly the typewriter appeared to be ready for a successful diagnostic run. I loaded the code into core and started the test up but began to see error messages - new messages that hadn't been observed before. These indicated that immediately after issuing the XIO Write instruction to print a character, the status sensed from the device did NOT show it busy, but it should have.
When printing a character, the only status line from the typewriter that matters is the -Twr CB Response signal which is produced by a series connection of three microswitches to feed +48V into the device controller logic in the IBM 1130. The switches break the circuit during three types of operations:
- printing a character
- performing a space, backspace or starting a tab
- shifting between upper and lower case
Mostly the line is connected to +48V but drops to 0V when one of those operations above is underway. The device controller should mark the typewriter as busy as soon as it initiates those operations, then turn off the busy when the -Twr CB Response line returns to +48V when the operation is over.
CHECKING THE MICROSWITCHES IN THE TYPEWRITER
I first verified that the three microswitches for the -Twr CB Response signal were working properly by manually performing those operations while observing the state of the signal with a meter. They were working as they should.
I then checked the other feedback signal line, +Twr CRLFT Intlk, which is normally at 0V but has four microswitches in parallel that connect the signal line to +12V during Tab and Carriage Return/Line Feed operations. Those are both operations that take a long and variable amount of time to complete as it depends upon the number of columns that the carrier must move from its current position to the chosen column or left margin.
For each operation type, Tab or CR/LF, two microswitches are used. One of them is active for one half turn of the operational shaft when the operation is initiated. The other remains active until the long movement stops. The overlap of the two microswitches ensure that +Twr CRLFT Intlk is on from the initiation of the operation until it completes, whereas each one alone either ends too soon or starts after a delay.
My testing showed that all microswitches involved in feedback to the device controller logic were working properly. That left unresolved the cause of the errors I was receiving. In this case, it does not appear to be a typewriter problem, but instead an issue with the logic cards that implement the device controller.
The machine has also sporadically halted with parity errors, which appear to be caused by the injection of spurious bit values on the input bus during an IO operation. This may be from the typewriter controller logic it could come from other device controllers or unrelated areas within the machine. These may be related to defective components that are producing the error picked up by the diagnostic, so it would be good to chase this down as I troubleshoot this newest issue.
You know, this kind of hands-on experience, clearly explained and documented, ought to be preserved. Yes, it is available via this blog, but the blog won't last any longer than you do. And, it isn't that easy to search for a particular problem. The selectric posts are scatted over 10 years. I just suddenly imagined an anthology of all the selectric posts, pulled out to a single PDF, with an index by part name, which could be preserved on, e.g. Bitsavers or TIA. Yeah, I know, who's got time to do all that?
ReplyDelete