[Simh] Subtle H316 TTY interrupt bug?

[Bob Supnik]

Yes, this is a bug.

OCP triggers a delay cycle of some time during which TTY interrupts are 
suppressed. This is to allow time to get the first character out. READY 
does set as a result of the OCP, so interrupt suppression happens by 
other means. Adrian Wise's simulator does this by manipulating the SMK 
mask, but the hardware doesn't works that way.

The interrupt logic is conditioned by the combination of READY and 
!BUSY. This is confirmed by schematic LBD 0.342, where a 3 input AND 
gate generates PIL00 (program interrupt) if SMK11 is set, READY is set, 
and BUSY is clear. It seems strange to have the interrupt logic 
distributed out to the individual IO interfaces, but that's the way the 
H316 worked, apparently.

So with READY and BUSY in the picture, operations are as follows:

OCP '4 - clear READY (and any interrupt), BUSY, and the data buffer; 
clear output mode
         - wait for a character
         - as the character starts to come in, set BUSY
         - when the character is complete, set READY, clear BUSY, and 
request an interrupt if enabled
INA    - read the buffer, clear READY (and any interrupt)

Note that OCP '4 goes into input mode, and clears READY, BUSY, and the 
buffer, even if input mode is already set. Also, SimH doesn't simulate 
the "busy" period on inputs; it probably should.

Output has two flow diagrams, depending on whether the OTA is issued 
before the dummy cycle expires, or after.

OCP '0 - set READY and BUSY (clear interrupt), clear the buffer, start a 
dummy output

Now, if OTA follows during the dummy character time:

OTA - clear READY, set BUSY, clear interrupt, load the buffer, start a 
real output sequence
     - output the character
     - when output completes, set READY, clear BUSY, and request an 
interrupt if enabled

If OTA does not happen soon enough, then at the end of the dummy 
character time:

     - clear BUSY, READY stays set, interrupt happens if enabled

Note that this behavior is NOT what Adrian's simulator does, from what I 
can tell, but the timing diagram shows that READY stays set after BUSY 
clears, and that will generate an interrupt according to the logic diagrams.

So the fixes for the TTY are as follows:

1. Add an explicit BUSY flop, cleared on RESET.
2. Remove the test for output -> input transition on OCP '4. This starts 
an input sequence unconditionally.
3. Modify input service processing to use two states. In the first, BUSY 
gets set. In the second, BUSY is cleared, READY is set, and an interrupt 
is generated if enabled.
4. Modify SKS processing to test the BUSY flop directly, rather than the 
state of the TTY units.
5. Modify OCP '0 to start a dummy sequence by setting READY and BUSY, 
and clearing interrupt request. This too is unconditional.
6. Modify OTA processing to cancel any dummy sequence in process before 
starting output.
7. Modify output service processing to check for dummy sequence (READY 
and BUSY both set). If they are, simply clear BUSY and update interrupt 
status.
8. Check for interactions with the ASR functionality.

And of course...

9. Make sure that interrupt requests always reflect READY & !BUSY equation.

Verifying all this will be interesting.

/Bob Supnik

On 6/19/2013 4:56 AM, simh-request at trailing-edge.com wrote:
> Message: 5
> Date: Mon, 17 Jun 2013 21:00:16 -0700
> From: "Bob Armstrong"<bob at jfcl.com>
> To:<simh at trailing-edge.com>
> Subject: [Simh] Subtle H316 TTY interrupt bug?
> Message-ID: <00bd01ce6bd8$57945550$06bcfff0$@com>
> Content-Type: text/plain; charset="us-ascii"
>
>    I need an H316 expert to confirm this for me, but I think there's a subtle
> bug in the way simh handles the TTY output mode switch (Yes, the 316 has a
> half duplex console terminal interface!) and interrupts.
>
>   
>
>   
> http://bitsavers.trailing-edge.com/pdf/honeywell/series16/h316/70130072176C_
> 316_CPU_Descr_Apr73.pdf
>
>   
>
> is a description of the H316 CPU logic and the very end, around page 2-31
> thru 37, talk about the TTY interface.  In particular, 2-37 describes the
> "dummy cycle" that's inserted when hardware is switched from input to output
> mode, and 2-38 even has a timing diagram to show how it happens.
>
>   
>
>    Consider the two instruction sequence
>
>   
>
>                 OCP       104                       / SELECT TTY OUTPUT MODE
>
>                 OTA       4                            / OUTPUT A CHARACTER
>
>   
>
> Assuming the interrupt system is enabled and that the TTY interface is
> currently idle, simh is written to interrupt immediately after the OCP 104
> and before the OTA.  That means that the code effectively gets an output
> done interrupt before the output is ever started!  Based on the description
> in the above manual, I'm pretty sure this is wrong.  The "dummy cycle"
> inserts a delay between the OCP and the flag setting, and by that time the
> OTA has been executed, the output flag is cleared, and there's never any
> interrupt asserted by the OCP.  No interrupt occurs until the character
> output is actually finished.
>
>   
>
>    So, is there an H316 expert out there that can confirm this theory for me?
>
>   
>
> Thanks
>
> Bob