SimH IBM1130 GUI appears "fixed"

[JAMES FEHLINGER]

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
from "1132PRINTER" to "1403PRINTER", it appears that the main program is only
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.