I wrote, last night: No, it doesn't after all. By the time I got dms32k25011403.dsk working, I'd managed to confuse myself about which SimH executable I was running. The new DMS disk makes no difference as far as the GUI problem is concerned -- the GUI only works as expected (and as described in the Reference Guide from ibm1130.org) for simh-4.0-Beta--2016-01-07-e8ea427d (and prior) Windows builds (and with no throttling, in all cases). Sorry for the confusion.

This is an update on my attempt to run, on the SimH 1130, the "Lunar Landing" program featured in one of Carl Claunch's YouTube videos of his real 1131 CPU (connected to his PC-simulated 2310 disk drive, PC-simulated 1442 reader/punch, and a real 1132 printer): https://www.youtube.com/watch?v=JduYwduvGbo Claunch doesn't go through the complete game-play cycle in this video, he only shows the computer reading the card deck (lunarlanding.bin) and flashing its lights during the (two) compiles and (three) binary loads to disk -- first a short subroutine (a stub, actually - LTPLT) compiled and loaded to disk, then a subroutine object binary (ORBIT) loaded to disk, then the main program (LUNAR) compiled, loaded to disk, and executed. The video ends when the 1131 console Selectric starts printing out the initial text. You can't really see that text in the video, but here it is: THIS GAME SIMULATES THE BEHAVIOR OF A SPACESHIP AS IT IS FIRED OUT OF A 100.0 MILE HIGH PARKING ORBIT ON A TRAJECTORY TOWARD THE MOON. AT MISSION CONTROL YOU MUST CHOOSE THE INSERTION ANGLE AND VELOCITY TO LEAVE EARTH ORBIT. THE ANGLE IS MEASURED COUNTER-CLOCKWISE FROM THE LINE BETWEEN EARTH AND THE MOON. THE VELOCITY IS IN MILES PER HOUR. DATA SWITCHES 1-6 SERVE THE FOLLOWING PURPOSES-- 1 = TRACE EVERY TENTH ITERATION. 2 = ENTER MID-COURSE VELOCITY CORRECTION. 3 = ABORT FLIGHT. READ NEW PARAMETERS. 4 = SKIP TO PLOT OPTION. 5 = REJECT PLOT. 6 = EXIT. THE PROGRAM WILL PAUSE WITH 2222 DISPLAYED WHEN THE 'X' COMPONENT OF VELOCITY APPROACHES ZERO. MID-COURSE VELOCITY CORRECTIONS MAY BE DESIRED AT THESE POINTS. USE 8 LINES PER INCH PAGE SPACING AND AN 88 LINE CARRIAGE CONTROL TAPE. ENTER ANGLE (For what it's worth, he seems to have console switch 13 in the "up" position in the video; this would seem to correspond to a value of 4 in the above list -- at any rate, a "deposit ces 4" command to SimH flips up switch 13 in the simulator GUI. But none of these switches actually seemed to change anything about the execution of the program, as far as I could tell.) So Claunch, in a message on the IBM1130 Google forum: https://groups.google.com/forum/#!original/ibm1130/BYDqS8bQkTs/q2E3epE4xzoJ gave a link to download the deck he's using in the video, which is still valid: https://dl.dropboxusercontent.com/u/88601644/lunarlanding.bin He mentions that the deck is in 1130-simulator binary format. I was able to use the "viewdeck.exe" utility from ibm1130.org to see the parts of this deck that originated in human-readable 029 format, and since the file is 160-character fixed-length records, it's possible to use (Cygwin) 'dd' to split lunarlanding.bin into three files. The first and last can be turned into ASCII with viewdeck.exe while the the middle one must remain binary. Each one loads its contents to disk, so once the whole suite has run once in order, you can run the jobs separately or in any sequence (if you want to recompile and/or reload one or more pieces), or you can run the program, without any recompilation, from disk using a single card: // XEQ LUNAR [Note: If you split up lunarlanding.bin like this, the binary job that does the replacement of ORBIT needs an extra (binary) //DUP directive inserted as its first record in order to be completely standalone. This can also be accomplished with 'dd' and 'cat'.] The expected cycle of game play seems to be that when you get the above introductory message on the Selectric console, you type a number in response to "ENTER ANGLE" (following by a return) at which point the program responds with a second prompt "ENTER VELOCITY". You type another number and return, at which point the response is: PLOT DIAGRAM IS READY. At this point, the 1130 goes into a Wait, and SimH drops you back into the command prompt. This "plot diagram" referred to is on the line printer, so you tear off the printer paper and you see, (following the boot message from DMS and any other messages from compilation and/or loading of the program pieces, and a few skipped lines after the final echoed "// XEQ LUNAR", the heading: HOUR MIN 'X' COoRD. 'Y' COORD. 'X' VELOC. 'Y' VELOC. ABS VELOC. DIST TO E. DIST TO M. In the normal case there would presumably also be actual numbers on the next line. Going back to the console and typing "cont" or "go" (or pressing the Program Start button on the GUI or on a real 1130), the program continues (don't forget to reattach the printer if you're operating the simulator manually) with another succession of prompts on the console: ENTER ANGLE (you enter a number, <return>) followed by ENTER VELOCITY (you enter a second number, <return>). Again, PLOT DIAGRAM IS READY. following by a Wait. If you examine the lineprinter output, this time you see a graphic, with representations for the earth and the moon, together with the trajectory of the spacecraft travelling from the former to the latter. This is preceded by the text: TRANSLUNAR TRAJECTORY == INCREMENTAL VELOCITY=<number>. INJECTION ANGLE=<number> SCALE = 10,000 MILES/INCH, THE SCALE IS BROKEN AT 60,000 MILES AND RESUMES AT 221,000 MILES Again, this is followed by numerical data labelled with the headings "HOUR MIN 'X' COORD. ..." etc. Then it's back to the console, and the cycle repeats. Presumably this back-and-forth goes on until you reach the moon (or crash into it or miss it). So here's what I've discovered so far about running this program under SimH: 1. You **must** use an 1132-configured DMS disk. While it's possible to edit the human-readable portion to change the IOCS directive ahead of the main program doing the console I/O. All of the lineprinter output seems to come from the ORBIT subprogram, which is only available as object code, and is presumably using 1132-specific logical unit numbers. In any case, if you try using a 1403-configured DMS boot disk, after its first attempt to write to the lineprinter the program goes haywire and becomes unresponsive. 2. You'd probably also better use the latest DMS disk from ibm1130.org, which seems to be dated 11/26/2012. The "Reference Guide" says that up until 10/24/2012, Fortran extended-precision SQRT was defective because of a bug in the cross-assembler used to build DMS. The ORBIT program uses extended-precision arithmetic. 3. Nevertheless, despite using the latest DMS from ibm1130.org (built for the 1132 printer and with the fixed SQRT), I can't get sensible output from ORBIT. I suppose it's possible that I'm not using numbers in the expected range for the program (but I've used lots of angles from 0 through 270, and velocities between 5000 and 100000 mph). In all cases, there are never any numbers shown underneath the "HOUR MIN 'X' COORD. 'Y' COORD. ..." heading on the lineprinter output; the heading of the trajectory graphic always looks something like TRANSLUNAR TRAJECTORY -- INCREMENTAL VELOCITY=100000000. INJECTION ANGLE=*********** and the graphic itself, instead of showing a path from the earth to the moon, shows a vertical column of forward slashes (it's always vertical) much longer than the indicated distance between the graphics of the earth and moon (but the column of slashes is indeed broken at one point). This is, of course, a heavy-duty numerical program, and I fear this output means that there are still other bugs in the 1130 simulator's extended-precision arithmetic (or indeed, in the cross-assembled versions of one or more of the other Fortran extended-precision system subroutines). 4. Finally, something that was driving me crazy until I saw the pattern. There's an interaction between the GUI and getting console input (such as when you provide the numbers you're prompted for in the Lunar program). This has nothing to do with Lunar Landing itself; I was able to reproduce the problem with a simple Fortran program: // JOB // FOR *ONE WORD INTEGERS *LIST ALL *IOCS(KEYBOARD,TYPEWRITER) **WRITE TO AND READ FROM THE 1131 CONSOLE C C THIS IS A TEST OF CONSOLE I/O VIA A FORTRAN PROGRAM. C --------------------------------------------------------------------- C INTEGER LINE(40) WRITE(1,5) 5 FORMAT('SAY SOMETHING FUNNY') READ(6,6) (LINE(I),I=1,40) 6 FORMAT(40A2) WRITE(1,9) WRITE(1,7) (LINE(I),I=1,40) 7 FORMAT(11HYOU SAID - ,40A2) WRITE(1,8) 8 FORMAT('THAT WAS FUNNY') WRITE(1,9) 9 FORMAT('') CALL EXIT END // XEQ What happens is (and this **only** happens when the GUI is on, if you "set gui off" in the initial SimH command file and operate the simulator manually, the problem goes away), when you answer a prompt on the console by typing characters, nothing is seen by the program until you **first** hit a carriage return. Then the 1130 starts seeing what you're typing. And interestingly, any keystrokes you typed before that first carriage return are saved somewhere until control is returned to the SimH command processor (when the 1130 enters a Wait), and then they're seen by SimH itself, which responds "Unknown command". I might poke around some more to see if I can guess what might be causing the problem with console I/O when the GUI is on, but I've pretty much given up at this point being able to do anything useful with Lunar Landing. Oh, well.

I've made little more progress in deciphering the operation of Carl Claunch's "Lunar Landing" program, as featured in one of his 1130 YouTube videos. (I'm guessing he's the actual author of the program -- he mentions on one of his blogs that he was interested in space before he became interested in computers.) Recent (official) bug fixes to SimH have made it much easier to input data to the 1130 console when the GUI is active (you no longer need to type Return first, to unlock the console keyboard). I finally realized that responses to the console's "ENTER ANGLE" and "ENTER VELOCITY" prompts can be left-justified numbers, as long as they're followed by a decimal point. If you make a typing mistake, it would seem that Backspace, <ctrl>H and <ctrl>U all do the same thing -- erase the entire field. The characters already typed don't disappear, the cursor just goes to the beginning of the next line. The data switches mentioned in the introductory console message are switch positions (on the GUI) counting (starting with 0) from the left, not binary numbers. "4 = SKIP TO PLOT OPTION" means "flip up switch #4" -- not, in SimH terms, "deposit ces 4" which would turn on switch #13. If switch #4 is turned on, "examine ces" gives (hex) 800. The switches apparently really do what they're indicated as doing in the introductory console message. E.g., if you turn on switch #1 (TRACE EVERY TENTH ITERATION), then columns of numbers will appear on the lineprinter underneath the headings HOUR MIN 'X' COORD. 'Y' COORD. etc. These seem to show the progress of the flight, about every (virtual) 18 minutes. The ANGLE and VELOCITY values prompted for appear to be **initial conditions** of a flight, so the reappearance of these prompts on the console means that your trip has ended and a new one is beginning (unless switch #6 is turned on, in which case the program exits when the current flight terminates). This only slowly dawned on me -- at first I figured the re-entered values were a means of steering the spaceship, or something. Fine-tuning a flight is apparently done by turning on switch #2 (ENTER MID-COURSE VELOCITY CORRECTION). If this switch is turned on, you get a new prompt on the console, something like VELOCITY IS 27485. MPH, DIST. TO EARTH, 4058. MILES, AND 239034. MILES TO THE MOON ENTER VELOCITY CORRECTION and you type in something like, I don't know, 1000. and the prompt is repeated with the new velocity and recomputed distances. And again, and so forth. You only seem to get a graphical plot of your trajectory when the flight has terminated. Then you see PLOT DIAGRAM IS READY. and the 1130 goes into a wait state. When you continue from there, you get the ENTER ANGLE prompt, etc. The trajectory plot for a given flight doesn't seem to appear on the lineprinter until the **succeeding** flight has terminated. The visible trajectory plot always seems to be one flight behind the one just terminated. I don't know what that's about. Also, the angle measurement described in the console instructions -- "ANGLE IS MEASURED COUNTER-CLOCKWISE FROM THE LINE BETWEEN THE EARTH AND THE MOON" -- doesn't seem to match my trial and error. If I give an angle of 0. and a very large value velocity (say, 100000.) then the trajectory plot goes vertically straight up the page, perpendicular to the line between the earth and the moon. If I enter an angle of -90. and a similarly high speed, then the trajectory goes straight toward the moon. So I don't know if the instruction message is 90 degrees off or if I'm missing something. At least the "counterclockwise" part seems to be right. I don't yet know what causes a flight to terminate, well before it gets anywhere near the moon. Maybe the idea is to try to get a hole-in-one by picking perfect initial conditions. Maybe the flight automatically terminates when the ship is so off course that the program decides the flight has failed. I don't know what's supposed to happen if you actually manage to get near the moon -- whether there's some sort of braking and landing procedure in the program. I am able to run the program using the DMS disk from bitsavers configured for 32kw of memory, the 2501 card reader, and the 1403 printer. (I had to use the "viewdeck" utility from ibm1130.org and some other things, like Cygwin 'dd', to split up the original binary deck into two human-readable pieces and one other component [the "ORBIT" subroutine] that has to stay binary. The main program can be made human-readable, and that's where the Fortran logical unit number for the printer is defined, and can be changed.) I may finally give up and attempt to contact Claunch for hints about how to use his (I presume it's his) program. But I'm reluctant to do so, partly because it's fun to try to figure it out myself, and partly because I don't want to bother or embarrass him. I know he's posted here in the past, though, so he may see this anyway.

I wrote, above: This turns out to be a subtle operational difference between using the SimH 1130 and a real machine. When the flight terminates, the console displays PLOT DIAGRAM IS READY. and the 1130 goes into a wait state (or SimH drops back to its command prompt), in response to a Fortran PAUSE statement in the main program. If you were using a real machine, this would be a chance to alter the data switches -- including, e.g., 5 = REJECT PLOT. in which case, when you continue, the plot data is **not** dumped to the lineprinter (though the headings for "TRACE EVERY TENTH ITERATION" are still printed, along with the trace data if switch #1 is on). But if switch #5 is off and you press PROGRAM START at that point, by the time ENTER ANGLE shows up on the console in preparation for the next flight, the plot diagram for the last flight is already coming out on the lineprinter. Which you can just walk over and see. But if you're using SimH, then this PAUSE (while also giving you a chance to alter data switches) is the **only** opportunity you'll get to view the lineprinter output (either by clicking the lineprinter icon in the GUI or by typing detach prt, view "printer.txt", !del printer.txt, attach prt printer.txt on the command line) without forcibly stopping the program (by clicking IMM STOP or by typing ^E in the console) after it has cycled around to display the next ENTER ANGLE prompt on the console. The location of the PAUSE statement in the main program comes immediately after "PLOT DIAGRAM IS READY." message is printed on the console, but **before** the plot data is actually written to the lineprinter. So if you do click the lineprinter icon in SimH when the program pauses after the message, you won't see the plot diagram for the flight that just ended, because it hasn't yet been sent to the lineprinter. And if you click the lineprinter icon after you've continued through the next flight and the program has once again paused after "PLOT DIAGRAM IS READY.", then you'll only see the plot diagram for the **previous** flight. I "fixed" this, just to make things more convenient for SimH, by commenting out the PAUSE statement on card LUNAR052 in the main program, and inserting a new PAUSE statement just after card LUNAR084 (immediately after the "DO 42" loop that writes the plot data out to the lineprinter). Of course, on a **real** 1130, this "fix" would make it impossible to avoid wasting time and paper if you decided you didn't need the plot for the just-completed flight. You can't have it both ways! BTW, if you enter angle "-135." and velocity increment "5000." the plot diagram shows that your ship loops once around the earth before heading off into space. It's also the case here that the program pauses twice **before** pausing for "PLOT DIAGRAM IS READY.". I was confused by this, but the instructions reveal what's going on: "THE PROGRAM WILL PAUSE WITH 2222 DISPLAYED WHEN THE 'X' COMPONENT OF VELOCITY APPROACHES ZERO..." That happens at the right and left extremities of the orbital loop. If you turn on tracing (switch #1), you can see the 'X' VELOC. changing sign and going through zero twice. And sure enough, when the program pauses, the Accumulator (in the GUI) shows __ __ _2 __ __ __ _6 __ __ __ 10 __ __ __ 14 __ 0 1 2 3 4 5 6 7 8 9 10 11 12 14 14 15 i.e., 0010 0010 0010 0010 2 2 2 2