MY HAND CODE TO TEST THE DSW AND SAVE IT WAS DEFECTIVE
The error messages from the diagnostic were described as indicating the failure of the typewriter to appear busy during an output operation. The hand code was intended to save the Device Status Word (DSW) immediately after a character was output, with the result saved matching the character code of the letter I typed rather than a valid status.
Based on that I was down a rabbit hole trying to imagine a failure scenario that would place the character code in the accumulator register (ACC) after a sense DSW. It was quite unlikely which meant that I didn't have a good starting point to test signals to eventually locate a fault.
Imagine my embarrassment when I began to execute the code in single cycle mode to see exactly how the XIO Sense Device was working. I noticed that I was saving the ACC at the wrong time, just after I typed the letter with XIO Write, not after the XIO Sense Device. Thus the value I saved was in fact reasonable and consistent. Unfortunately, it was not an indication of what might be wrong in the diagnostic!
ACTUAL ERROR DISCOVERED BY LOOKING AT DIAGNOSTIC MEMORY LOCATIONS
I pulled out the listing of the diagnostic program and found the point where it was writing the error message. The code showed me a location where the DSW had been saved before it was checked doing an exclusive OR with the value x0C00 and requiring the result to be all zeroes. Those two bits in the DSW are busy and not ready, respectively.
The busy bit was on, as it should. The not ready bit was not set. My DSW was x0800 but had to match x0C00 for the test to pass.
NOT READY SHOULD GO ON AT THE SAME TIME AS BUSY
The architecture of the IBM 1130 specifies that the not ready bit is turned on by multiple things, one of which is a busy condition. It is also set when the typewriter is out of paper (Forms Check lamp is lit on the 1130 console). In the past this had worked properly, so the diagnostic error was new, popping up sometime while I was doing the last round of typewriter adjustments.
Since it had occurred immediately after I changed things on the typewriter device, the likely cause was something wrong in the typewriter itself. Once I watched the typewriter perform properly I turned my attention to the typewriter controller logic inside the IBM 1130. Sadly I read the error as indicating that the busy bit was not turning on. This bit turns off once the operation is complete and the controller logic requests an interrupt from the processor.
I then set up a defective program to look at the DSW to check for busy right after the XIO Write but before the interrupt was requested. Based on a flawed test, I was chasing a false error scenario in the controller logic. Armed with the actual situation that triggers the error message in the diagnostic, I can start testing the portion of the 1130 that is involved.
NOT READY STATUS LOGIC
There is a small amount of logic and connections involved in turning on not ready while the typewriter is busy. This all begins when the typewriter turns on its busy flipflop, during the XIO Write instruction, step E1, at clock time T6. That signal stays on until the rising edge of the -Twr CB Response signal from the typewriter.
At this time, the busy flipflop is turned off and the operation complete flipflop is turned on. The request for an interrupt on level 4 is raised whenever operation complete is set. A subsequent XIO Sense Device with bit 15 set will clear the operation complete flipflop, stopping the request for an interrupt. This normally is issued within the interrupt request handler code so that when the interrupt handler exits, we don't immediately jump back in due to the active request.
-Twr CB Response is created by a chain of microswitches in the typewriter, all of which are normally closed. When one or more of them opens, indicating that a mechanical operation is in a sensitive portion of its cycle, the signal drops to logic 0. Once that protected portion of a cycle is finished the switch closes again, creating the rising edge back to logic 1 state.
Since we are receiving the interrupt request we know that the rising edge is detected. We know from looking at the DSW after the interrupt that the busy bit is not on. I know from the stored DSW in the diagnostic that the busy bit was set while the typewriter was outputting the chosen character.
The signal -Twr Not Ready is generated by the logic below:
As you can see, it is very simple. On the left, the End of Forms microswitch is debounced and is an inverted logic signal -Twr End of Forms. The -Twr Busy signal is also inverted.
If both of them are logic high, thus we are not busy and we don't have an end of forms, then the signal +Twr Not Ready is generated as logic low due to the rules of a NAND gate. If either condition is true (logic low) then we raise the +Twr Not Ready signal that goes over to produce the DSW bit 4.
Also, if we have a logic high on this generated +Twr Not Ready signal and at the same time we are not busy (logic high on -Twr Busy) then we drive the -Twr Forms Check Lamp line low to light the bulb. This means that the lamp doesn't actually go on while we are performing a typewriter mechanical operation, waiting until the completion.
For example, if the carrier is near the right margin and a carrier return is requested, when the platen rolls up one line, we might have the paper end leave the End of Forms microswitch. The lamp doesn't turn on until the carrier has finished its move to the left margin. Presumably an eagle eye could spot that sequence of operations, but it seems to be a unnecessarily sophisticated implementation of a warning lamp.
Finally the signal -Twr Busy that we are combining to produce the -Twr Not Ready condition comes from this logic:
The Twr Cycle flipflop is turned on by the combination of XIO Write, Area 1 (typewriter address) and time T6, as long as the typewriter is not busy. The busy signal arms the edge detector which fires off a set pulse when we exit T6 in an XIO Write to the typewriter. The flipflop is turned off when the signal +Twr Interlock Latch drops as long as we are not in a shift cycle, since shift cycle conditions the edge trigger.
When the typewriter needs to shift between the upper case and lower case hemispheres of the typeball, it converts the request into a sequence of two typewriter actions. First, a shift is fired off. When that is complete, we then fire off the character type command.
The interlock latch is on while mechanical action is underway and will turn off after the shift and again after the typing of a character. We don't want to turn off the print cycle after the shift, only when the actual typing is done.
Our busy condition is formed with a NAND gate, turning on if any of three signals are true:
- Twr cycle flipflop is set
- We detected the end of line microswitch on the typewriter
- The interlock latch is on due to mechanical motion
Since this output is an inverted logic signal, -Twr Busy, it is logic low when on. That feeds directly to the logic producing the +Twr Not Ready signal (see diagram).
Now that we see how the two signals, -Twr Busy and +Twr Not Ready, are produced, we look at the logic which presents +Twr Not Ready as bit 5 of the DSW.
When we have an XIO Sense Device for Area 1 and the +Twr Not Ready signal all at logic high, we set DSW bit 5 low (which produces a 1 in the DSW).
All of the logic involved is on gate A, compartment C1 of the 1130, which eliminates any compartment to compartment cables from suspicion. We have just a few gates that might be malfunctioning. The only other possibility is a broken trace on the backplane of compartment C1, which is very unlikely.
Potential bad gates include:
- A C1 C2 D07 output producing the -DSW Bit 5
- A C1 E5 D04 producing +Twr Not Ready
The correct operation of the logic producing the interrupt request and good status for busy eliminates any other gates in the machine from consideration.
OSCILLOSCOPE PROBE OF HAND CODE TO WATCH NOT READY SIGNAL
This is a very simple test - trigger the scope when the busy condition is produced at A C1 D4 D04, on the falling edge. Watch the two signals above to see if they are generated appropriately. Based on that, test the gate in question, find the bad component and then fix it.