Some diagnostic runs - successes and minor setbacks

CPU DIAGNOSTIC RUN COMPLETED

The code exercised every variant of every instruction and all the corner cases. When it was complete, we can be certain that the processor is working perfectly. 

KEYBOARD AND 1053 PRINTER DIAGOSTIC RUN STILL NOT COMPLETE

I continue to have difficulties getting a version of the diagnostic in core that will continue and operate on the real machine. The challenge is due to shortcomings in the 1130 simulators that I have been using to set up programs before saving the memory image. 

The IBM 1130 has a switch on the console which is a lever that can be flipped to either Keyboard or Console setting. This drives one bit in the device status word for the printer/keyboard (area code 1), with a 1 in bit 5 if the switch is set to Console otherwise 0 for Keyboard. It does nothing at all other than reflect its setting in the DSW. 

The 16 console entry switches are a unique area code - 7 - and can always be ready by an XIO. The purpose of the switch, therefore is advisory to the program. There are programs that either expect the operator to type in values on the keyboard or enter values on the console entry switches based on how this switch was set. 

Programs can make use of this switch to select between different modes of operation or parts of a program. The diagnostic monitor program that hosts many of the more sophisticated diagnostics, including the keyboard/printer one, watches for the switch and informs the test programs of its setting any time the switch is changed. 

With the switch flipped to keyboard, the diagnostic will select the keyboard and echo every character pressed on the 1053 typewriter. The switch when flipped to Console causes the diagnostic to run a number of tests for the 1053 correct operation. 

The IBM 1130 simulator written by Brian Knittel and shared on his ibm1130.org website does not implement the switch. It is a labeled graphic on his GUI of the console but it doesn't switch nor drive the DSW bit 5. The result is that the switch always appears to be in the Keyboard setting, thus the diagnostic won't test the 1053 other than by an echo of keys but only as fast as you can type them. 

A much more accurate and complete simulator is being developed by a professor from a university in Brazil and I have been using an early, pre-publication copy to run things that fail on the original 1130 simulator. Unfortunately, at this time while the simulator has a switch that you can set to either position, its state is not reflected in the DSW. Once again, the default appears to be a setting of Keyboard so the diagnostic won't run on the new simulator either. 

I did some hacking to get it to run once or twice a few days ago, but I struggled through much of today without having a memory image that will start up on the real 1130 and run the printer side of the diagnostic.

HANDLOOP TESTING OF KEYBOARD AND 1053

I set up some simple hand loops in the machine to check out the keyboard and the console printer. The program for the keyboard would display in the 1130 accumulator the resulting code for any key pressed. I could check these against the Hollerith code assigned to each character and found them all to produce the proper bits. I did discover that the Space bar was wedged kind of low and not very reliable. 

The hand loop for the 1053 would read the console entry switches as a pair of typewriter codes and issue them. It runs rapidly. Sometimes I single-stepped the routine to watch the results and to verify that the machine correctly selected every character. Other times I let it run continuously. 

I was able to verify that the controller logic did detect the end of line and inserted an automatic carrier return and line feed as needed. I did sot some anomalies, in fact it appeared that the feedback switches I so carefully set to the manual specifications made some behaviors worse. A string of characters that are in the same case produced a string of J on the paper with some crowding. If I continuously issued pairs of a CR and a printed character, the typed character was not always in column 1. This may be a result of a very short 2 column return but it may be an adjustment issue. 

WORK NEEDED TO CORRECT THE ISSUES I SPOTTED

There is a mechanical issue in the keyboard which makes the Space bar stiff, both hard to depress and hard to restore. I may have to partially disassemble the keyboard to find and correct the issue. 

I plan to put my oscilloscope on the machine to monitor the feedback lines while I perform the hand loop on some of the problem situations. I will check the duration of the single shot timers in the controller electronics as well as time my response signals. 

As for the erroneous J output, I know I can correct this by extending the duration of the print cycle feedback switch. The worst that can happen if it is too long is that the typewriter never hits its max 15.5 cps pace, which is better than trying to fire solenoids while we are still in the midst of printing. 

Finally, I will continue to work on ways of getting a valid memory image of the diagnostic such that I can fire it up in Console mode and test everything fully.