Battling the diagnostic program until I can run it on the physical 1130

NEW SIMULATOR AUTHOR SENT ME AN UPDATE THAT FIXES THE SWITCH ISSUE

The new version of the 1130 simulator, still in development by its author, includes support for the Console/Keyboard switch on the 1130 console with proper indication in the Area Code 1 device status word, bit 5, of the position of the switch.

This would allow me to more fully test the diagnostic memory image on the simulator that I would then be loading into the physical 1130 core memory. I am hoping it arrives any time now

ISSUES SETTING UP DIAGNOSTICS ON SIMULATORS

The proper execution of the keyboard/1053 diagnostic requires a working Console/Keyboard switch on the 1130, however the simulators I had do not implement that switch and default it to the Keyboard setting which blocks the diagnostic from testing the printer. 

Loading diagnostics involves stacking multiple card decks in a card reader and booting from the card reader. The relocatable loader (program 3AA) then reads in the diagnostic monitor (program 300) and the monitor reads in various diagnostic routines. In our case, we want to read in program 304 to test our console printer. 

It may seem simple to just put the three decks sequentially in the hopper and boot the reader, but the lack of accurate emulation of the card reader introduces failures. The simulators treat the readers as simplified devices, which is convenient to shield users from the complications of real 1130 operations, but that infidelity leads to problems. 

The card readers have a hopper into which cards are stacked and a station inside from which each card is read and ejected into the stacker. Because a card has to be fed from the hopper to the internal station prior to doing a read, the operator pushes the start button and the first card is fed into the station without the CPU or program noticing. 

When the bottom card in a hopper is fed into the machine during the read of the prior card, the machine turns off the Ready state. The last card is physically sitting in the internal station but cannot be read because the machine is not ready. This behavior is intentional as in the real world, very big decks of cards are used with cannot all fit in the hopper at one time. Each time the hopper empties, the operator adds more cards from the deck and pushes Start which turns on Ready and allows the program to continue reading more cards. 

However, when the hopper empties and the card in the internal station is really the final card of a deck, the operator just pushes the Start button without adding new cards to the hopper. Pushing Start with an empty hopper turns on the Ready status but also sets an indicator when the final card is read. This bit in the device status word, Last Card, tells the program that we should not loop attempting to read more cards. 

The simulators turn on Last Card automatically as the hopper empties. In real life, I could put the 3AA relocatable loader in the hopper, push start, and then boot it. When it came to a halt with the reader not ready, I could then put the 300 program deck in the hopper and push start. The machine would read the last card of 3AA and then that program would begin reading the subsequent cards from 300. 

When the 300 deck has its last card leave the hopper, the Ready condition goes off. Still no Last Card status. We add the 304 deck into the hopper and push Start. The 3AA program reads the last card of 300 and then the 300 program begins reading cards from the 304 deck. 

When the last card leaves the hopper of 304, if I push Start without inserting a new deck, the last card of 304 is read by 300 but the logic of the program will still try reading additional diagnostic decks, ignoring the Last Card status. 

For the 300 program, one must add a blank card to the end of the last diagnostic to be read by 300. Then, when it gets the Last Card and sees a blank, it begins executing the diagnostic program(s) it loaded. 

Thus the behavior of the reader and the Last Card indicator is quite pertinent to loading the diagnostics properly. the only way I can make this work is to stack the entire set of three programs (3AA, 300 and 304) plus a blank card into the hopper and boot the CR. 

Even after solving the card reader related issues, we have to choose when and how to stop the simulated 1130 in order to dump core contents that can be restarted on the real 1130. Restart is funny with the diagnostics, as one is actually first restarting the Diagnostic Monitor (300) which then restarts 304. Very easy for things to be tripped up so that the program does not start executing properly on the physical 1130. 

GETTING A SUITABLE MEMORY IMAGE THAT WORKS ON BOTH SIMULATOR AND 1130

I did find a version that I had hacked previously so that the monitor believed the switch was set to Console and didn't flag the actual state of the bit 5 as an error. With this version, I can restart on either simulator and see the 1053 output stream. It will not allow me to switch the diagnostic into keyboard mode where it echoes every keypress to the 1053, but I know the keyboard is working. 

TESTING WITH THE CONSOLE/KEYBOARD SWITCH 

I have two routes to testing on with the console/keyboard switch to  run both modes of the diagnostic. First, I can test on the simulator after I receive the new update, letting me figure out a memory load of the diagnostic that works when restarted and uses the Console/Keyboard switch. Second, I can figure out where I hacked the current memory load and adjust it so that it works with the physical 1130 and its switch. 

I will first complete the typewriter side run of the diagnostic to complete the formality that all is done on this 1130 restoration. Later I will do this testing so that they diagnostic runs on the restored machine with both modes depending upon the key setting.