Verification of 1053 Console Printer - final testing

CHECKING OUT THE SENSE BITS

Area code 1 (the device address) is shared between the keyboard and the 1053 typewriter, since one is input-only and the other is output-only, so the correct subunit is inferred from the type of IO request. Because they are shared, the device status word contains bits for both subunits. We are concerned only with the bits associated with the typewriter:

• Bit 0 - The typewriter has responded/completed a request
• Bit 2 - The device(s) that responded raised a request for interrupt on level 4
• Bit 4 - Printer busy - has received a request but not yet responded with completion
• Bit 5 - The printer does not have paper forms in it or is busy

I can test out these with some hand code to issue a command that is long, such as carrier return, and then immediately check status. I should see bit 4 on because it is in the midst of the operation, but no other bit at this time since we didn't wait for the typewriter to finish.

Putting the machine in Single Instruction mode while doing the above will let me check the DSW after the carrier return has completed but before the computer accepts the interrupt request from the device. I should see bits 0 and 2 turned on, the rest off. 

When I step through the interrupt handler and reset the device during the Sense DSW, all bits should be off. 

Finally, I can take the paper out, issue a sense DSW, and see that bits 4 and 5 are turned on. 

Using the above procedure I tested the controller logic and am satisfied that the DSW is being handled properly. 

USING THE IBM DIAGNOSTICS TO SHAKE OUT THE TYPEWRITER

Once it appeared that the 1053 responded properly to space, backspace, CR/LF, LF, tab and character typing, including shifting between cases and shifting ribbon colors, I could move on to the next phase. That phase used my console loader feature to load core memory with the 1053 diagnostic program, then test the printer with that diagnostic suite. 

I used an IBM 1130 simulator to load the card decks that start the console/keyboard diagnostic program, then when it paused waiting for operator action, I dumped the virtual memory to a text file. I only had to add the activation and deactivation commands to the front and back of the file to have it ready to load into the physical 1130.

My console loader issues a prompt (> character) when it is ready for the next command, thus I needed a program to upload the text files of loader commands with pacing. I remember terminal programs in the past that had a standard capability for text file transmission where I could specify a prompt that the program waits for. However, none of the programs I have or found have this as a menu choice - Putty, Teraterm, and Hyperterminal are among the serial terminal emulators that I tried. 

Fortunately, Teraterm has a scripting language that has features such as wait ">" that I used to pop up a file open dialog and transmit the file line by line waiting for the prompt. It worked great. 

A terminal program uploaded the file to set the memory contents so that we ended up with the 1130 having the paused diagnostic in memory and the IAR set to the point where it would resume execution. 

DIAGNOSTIC PROGRAM RESULTS - IS EVERYTHING WORKING?

The diagnostic program has two major modes - keyboard echo and 1053 testing. The echo function prints whatever character is typed on the keyboard, allowing a test of both the KB and the typewriter. I used this to work through all the characters on both sides of the typeball. The 1053 testing has a number of subtests, such as tab and CR tests, upper case letter tests, ribbon color shifts and other ways of validating that the typewriter is performing properly.

The diagnostic program proved out all the functions of the 1053, and suggested only a few minor adjustments to make to the typewriter, thus cementing my belief that the 1053 is complete and the 1130 system can be prepared for its move back to its home at the System Source Museum. 

There is a air cylinder to stop the carrier at the left margin which needs a slight tweak. The last three test routines are called, rock, roll and twist and they subject the typeball to extreme rotations or tilts between adjacent characters as a way of spotting any subtle issues. I can see that the feedback circuit timing in the typewriter needs a bit of adjustment.

The 1053 has seven microswitches, three of which are activated by cams and the others by levers. They pace the controller from firing solenoids to trigger the next function. There are points in each cycle or function where they should block the controller logic because the mechanism is in the midst of some movement which is incompatible with printing or other functions until it complete. It won't take long to set these all to their optimum points. The result is already extremely good.

The line of heavy asterisks is a function that types a + in one color, backspaces to type a 0 around it, then spaces over three spots. It does this across the line, the returns the carrier and does the same offset by one column. A third time results in the line being filled in. Any mispositioning of spacing, backspacing or print escapement will be very obvious to the eye. It was pleasingly accurate. 

METHOD TO TEST ELECTRONICS WITHOUT TYPEWRITER - AN ASIDE

I had designed and built a 1053 Emulator box which will plug into the SMS card sockets in the 1130 and respond just as the physical 1053 would. It provides for all the features and functions of the typewriter, tracking the current column that the carrier would have reached. The current column is displayed on three 7-segment displays. It offers the same three buttons on the front (Carrier Return, Space and Tab) plus Tab Set and Tab Clear. 

Each of the character selection codes that have solenoids fired by the 1130's controller logic, T1, T2, R1, R2, R2A, R5 and AUX, are detected and trigger the activation of feedback microswitch circuits to indicate the progress of the mechanical movement. As well, we determine which character on the typeball was selected and print that over the serial connection to the terminal program on a PC. These match exactly the glyphs on the typeball including the two characters that must be represented in Unicode as they are not in ASCII (¬ and ¢). 

The solenoids for motion are implemented by appropriate numbers of spaces, backspaces and CR/LF on the terminal. Thus, when activating TAB we look up the next location where the tab stop was set by the Tab Set button, then space until the cursor is at that column. Spacing simply emits a single space character. CR/LF and LF solenoids inject the ASCII control codes for these actions. Backspacing involves its own control codes to move the cursor back to the prior column. As well, it uses the ASCII color sequences with the terminal to show the characters in either black or red depending on how the ribbon color solenoids were activated.