SimH IBM1130 GUI appears "fixed"

Thu May 4 22:05:59 CDT 2017

I decided to take a look at the code.

The github history shows that there were no changes
to any 1130-specific files between
April 3, 2015 "All: Convert from C runtime library perror()
to sim_perror(). . ." and
May 15,2016 "All: Massive 'const' cleanup"
whereas the change in behavior of the Win32 Development binary
of ibm1132.exe occurred sometime between
simh-4.0-Beta--2016-01-07-e8ea427d and
simh-4.0-Beta--2016-01-29-b8049645 .
This suggests that something changed **around** the
1130 code, in the SimH infrastructure itself.

I didn't bother to look for code commits in SimH framework
files between Jan. 7 and Jan. 29 2016; instead, I
took a look at the 1130-specific files for anything having to do with
the handling of "wait states", and there was one pretty
obvious place in ibm1130_cpu.c (particularly lines 586-606):

-------------------------
532  while (reason == 0)  {

     . . .

586    if (wait_state) {                /* waiting? */
         sim_interval = 0;              /* run the clock out */

         if (sim_qcount() <= (cgi ? 0 : 1)) {    /* one routine queued? we're waiting for keyboard only */
           if (keyboard_is_busy()) {            /* we are actually waiting for a keystroke */
             if ((status = sim_process_event()) != SCPE_OK)    /* get it with wait_state still set */
               reason = simh_status_to_stopcode(status);
           }
           else {              /* CPU is not expecting a keystroke (keyboard interrupt) */
             if (wait_state == WAIT_OP)
               reason = STOP_WAIT;      /* end the simulation */
             else
               reason = STOP_INVALID_INSTR;
           }
         }

         if (gdu_active())              /* but don't stop simulator if 2250 GDU is running */
           reason = 0;

         continue;
606    }

     . . .

1170 }
-------------------------

I stuck some print statements in there, and sure enough,
if the simulator isn't dropping back into a command prompt
after DMS boots or after a job finishes, it's because this
loop never exits.

The sim_qcount() call looked interesting -- it seems
to be examining a SimH "event queue".  Not being familiar with
SimH internals, I have no clear idea what this queue contains,
but the 1130 code seems to be making an assumption about the
number of items that should be there, an assumption which
is apparently no longer correct (and was always incorrect
when throttling is on).

This has nothing to do with the GUI, actually -- the behavior is
the same with "set gui off" in the initial command file, and I
did my initial poking around with a quick-and-dirty Cygwin-built
executable with no SDL support anyway.  (I've now switched to
the latest MinGW with gcc 5.3.0 and SDL graphics.)

Again, I have no idea what the SimH infrastructure is putting
on this event queue that wasn't there before -- it may
have something to do with changes to the SCP.

I also don't know what "CGI mode" is -- that's something specific
to the 1130 simulator, apparently -- it's mentioned in the
"Reference Guide", but it isn't defined.  But apparently there's
an on-line version of the simulator at ibm1130.org that protects
its disk image from permanent changes, and this operates in
"CGI mode", whatever the letter stand for.  I presume I'm
not operating in "CGI mode".

Anyway, this is the horrific kludge I put in ibm1130_cpu.c to make
the GUI (or more exactly, wait states leading to dropping back
to the SimH prompt) work as expected, with or without throttling,
and with the latest github download of simh-master source.
(Even the 2250 GDU demo works.)  It's entirely empirical, without
any deep understanding of what's going on, and
may well break down the road.

-------------------------
337  static int s_qcount_initial = 0;  /* saves first-ever event queue count, immediately after DMS boot */
338  static int s_qcount_onetime_decrement = 1;

   . . .

536  while (reason == 0)  {

     . . .

590    if (wait_state) {                /* waiting? */
         sim_interval = 0;              /* run the clock out */

   #if 0
         if (sim_qcount() <= (cgi ? 0 : 1)) {    /* one routine queued? we're waiting for keyboard only */
   #else
         int s_qcount = sim_qcount();
         if (s_qcount_initial == 0)
         {
           s_qcount_initial = s_qcount;
         }

         if (s_qcount <= s_qcount_initial-s_qcount_onetime_decrement) {  /* one routine queued? we're waiting for keyboard only */
           s_qcount_onetime_decrement = 0;
   #endif
           if (keyboard_is_busy()) {            /* we are actually waiting for a keystroke */
             if ((status = sim_process_event()) != SCPE_OK)    /* get it with wait_state still set */
               reason = simh_status_to_stopcode(status);
           }
           else {              /* CPU is not expecting a keystroke (keyboard interrupt) */
             if (wait_state == WAIT_OP)
               reason = STOP_WAIT;      /* end the simulation */
             else
               reason = STOP_INVALID_INSTR;
           }
         }

         if (gdu_active())              /* but don't stop simulator if 2250 GDU is running */
           reason = 0;

         continue;
621    }

     . . .

1185   }
-------------------------

There was one other bug I found, that was preventing the printer.txt
file from getting reattached properly when the GUI is being used
and the printer paper is "torn off" and viewed.  That required
a change to ibm1130_gui.c (line 1483) -- removal of quotes:

sprintf(cmd, "attach prt \"%s\"", filename);     /* reattach */
to
sprintf(cmd, "attach prt %s", filename);     /* reattach */

That's also presumably related to a change in the SCP.  This latter,
trivial change is not a kludge -- it'll probably end up in the codebase
someday.

The CPU change I've only tested with the relatively limited set of sample
programs from the ibm1130.org software kit.

Lunar Lander still doesn't work.