THE CHALLENGE FOR 1130 SYSTEMS WITHOUT FULL PERIPHERAL COMPLEMENTS
The 1130 system software DMS (Disk Monitor System) V2 R12/R13 is designed for batch processing which was the predominant paradigm for mainframes at the time the system was offered. One would punch up decks of cards on a keypunch, stack them in the reader before and after other decks for other jobs, and the system would produce the output on a line printer. DMS ran from a disk drive inside the 1130.
While the machine comes with a console printer (1053 typewriter) and keyboard, they were not the main interface between a user and DMS. While it is possible to print the DMS messages on the typewriter after reading in a // CPRNT card and one could even read in a // TYP card that would look to the keyboard as the source for the next 'card' records, it isn't practical. DMS and the languages had fixed formats for input which are pretty strict, so that typing in a program via the keyboard is unlikely to work out well.
The compilers are not interactive and one cannot simply correct one statement and try again. If using the keyboard, one typo would mean you would have to type in the entire program once again.
Most software, however, would not redirect output to the console printer from the line printer, it was only the DMS messages themselves that were rerouted by // CPRNT. Thus without a working line printer you would get nowhere even if you tried to laboriously type in each program and control card.
Finally there is no way to start up DMS by booting the disk and have it begin reading from the keyboard as it would if // TYP had been read during a session. It always starts out attempting to print the DMS messages for the dummy JOB that runs as you boot the system. That requires a working line printer. If it had for some reason printed on the console typewriter, the next action of DMS is to read from the principle input device, a card reader and not the console.
Most programs run on the 1130 read cards and printed lines, but a few would interact by typing on the console and reading the keyboard or console entry switches or both. To start them, however, you need a reader and a line printer for DMS to start up and read the // XEQ command card.
SOLUTION - START A PROGRAM ON A SIMULATOR, FREEZE IT AND DUMP THE MEMORY
If we assume that we have demonstration programs whose operation does not require card readers and line printers, then we can use an IBM 1130 simulator to boot up DMS and start that program. If we freeze the running of the program at a suitable point, dumping the memory to a file, then when the file is loaded into memory at some future point, the program will resume where it had stopped.
The 1130 systems I restore have a console loader built in, which will take a file in the format dumped by the 1130 simulators and load the real 1130 core memory with those contents. Thus, I can take the dump that was saved in the paragraph above, load it into a physical 1130 system, and it will resume operation just fine.
As long as that program only uses the console printer, keyboard and console entry switches, and it does not request DMS to fetch any functions from disk to support its operation, it will run just fine. If the program ends and exits to the monitor, however, it will stop with a 'disk not ready' error as it tries to load another part of DMS to run the next job.
MODIFYING DEMO PROGRAMS FOR A GOOD FREEZE POINT AND PERPETUAL RUNNING
I took several candidate programs that could run on an 1130 system without external peripherals and made a couple of modifications to each. First, I blocked the programs from ending, as that would go back to the monitor and stop the machine dead in its tracks trying to run DMS. Next, I set up a good freeze point that would ensure a good restart each time it was loaded into core and begun.
DISCOVERING A FLAW IN THE IBM 1130 SIMULATOR
My method requires that I dump all of core memory. My restarted programs weren't working well if I cleared memory before loading them, and after some detailed debugging I realized that the 1130 simulator was not dumping all of memory to the file. In fact, it dumped only half the memory.
The flaw was in the code to do the dump, which set up a loop from address zero to a stopping point. The calculation for the stopping point took the memory configuration of the 1130, which in this case was 8K words, and divided it by two.
I can see how this defect came about, because an IBM 1130 word is 16 bits, thus 8K words is 16K bytes. If the memory size had been recorded in bytes, e.g. a 16K machine would store its size as 32K bytes, then the logic made sense. However, the loop was reading entire 1130 words, not bytes, so it was stopping at the midway point in core.
I am helping as a beta (or alpha) tester for someone who is building a really top notch IBM 1130 simulator. It does implement a dump of the full memory size, so I could use that simulator to accomplish my task.
FIRST FEW DEMO PROGRAMS COMPLETED AND SENT TO MUSEUMS
The three programs which were original games from 1130 installations were NIM, Craps and Tic-Tac-Toe. I did the small modifications to each, ran them on the simulator and created my memory dump file. The museum can load core with one of those three files and when they press Prog Start, the program begins its perpetual execution.
Loading core on an 8K machine can take close to an hour, so it is not practical to rapidly change demonstrations. However, a museum could change the program on a daily basis, for example, to give repeat visitors something new to experience.
WORKING ON A MUSIC DEMO
There were programs developed on mainframes of the 1950s and 1960s which would produce music on a radio held near the core memory of a computer. These typically read in a short deck of notes and durations from a card reader, or from a disk file. Neither of those are available for the purpose of a standalone demonstration, but I am going to modify the program to run entirely from memory.
Due to the limited core memory size of the museum 1130 systems - typically just 8K words - I have to select only a few of the dozen or so songs that were transcribed to drive the music application. I can allow the museum visitor to choose from three or four such songs and then hear the music playing with a handheld transistor radio.
No comments:
Post a Comment