[Simh] Subtle H316 TTY interrupt bug?

[Bob Supnik]

Yes, I got out the schematics. Fortunately the interrupt logic was well 
isolated and relatively easy to read. Because the H16's used 3 input AND 
gates for almost everything, trying to figure out what's going on in 
complex logic is a nightmare. I had to do that to figure out how the 
generic instructions really worked, and I never want to do it again.

Your hack is fine for now, but who knows if there's some other program 
that actually depends on a 2- or 3- or longer instruction window? I find 
it's always best to reproduce the hardware, hack for hack. (See my paper 
on PDP11 interrupts, 
http://simh.trailing-edge.com/docs/pdp11interrupts.pdf.)

/Bob

On 6/20/2013 12:01 AM, Bob Armstrong wrote:
> Bob -
>
>    Thanks for checking this out.  Did you actually pull out the H316
> schematics and work it out?  I'm impressed - I was too lazy to do that!
>
>    FWIW, I've "fixed" my copy of simh by the simple expedient of using
> INT_NODIS to disable interrupts for one instruction after any OCP 4 that
> switches to output mode.  (This is the same interrupt flag the ENB
> instruction uses to defer interrupts for one instruction.)  It's a fairly
> trivial mod to the code - in file stddev.c, routine ttyio(), modify the code
> like this -
>
>          if (fnc && (tty_mode == 0)) {                   /* input to output?
> */
>              if (!sim_is_active (&tty_unit[TTO])) {      /* set ready */
>                  SET_INT (0,INT_TTY);
> 		    // [RLA] Fix the "dummy cycle" problem (see above!)...
> 		    CLR_INT (0,INT_NODEF);  // [RLA]
> 	    }
>              tty_mode = 1;                               /* mode is output */
>
>
> Admittedly this is not exactly what the real hardware does, but it's a close
> enough approximation to solve the immediate problem and it's easy to
> implement.  I don't believe it has any bad side effects.
>
>    FWIW, I'm trying to resurrect some real H316 software that uses exactly
> the OCP 104/ OTA 4 sequence described, so it's not entirely an academic
> concern.
>
>    Thanks again for double checking this.
>
> Bob Armstrong
>
>