[Simh] MSU BASIC - docs and apparent simh bug?

[J. David Bryan]

On 26 Feb 2008 at 13:57, Tim Riker wrote:

> This simple example dies:
> 
> 10 PRINT "HELLO WORLD! ";
> 20 GOTO 10
> 30 END
> 
> it ran for a while and then aborted with:
> 
> Indirect address loop, P: 37003 (STA 1,I)

To fix this, do:

 sim> deposit TTY TTIME 400

...before starting.

The issue is a general one with SIMH and old software, and I've run into it 
several times before.  The problem is that many SIMH devices are abnormally 
fast compared to the original hardware.  This is not because the hosts are 
faster, but because operation timing has been sped up intentionally.  

In the TTY case, the ASR-33 operated at 10 characters per second.  The HP 
2116 processor ran at about 600 instructions per millisecond.  Therefore, 
the TTY would interrupt approximately every 60000 CPU instructions.  But 
the default SIMH configuration is to interrupt every 100 instructions -- 
about 600x the rate of the actual Teletype.  

In most cases, such speed-ups are safe and effective.  After all, you don't 
really want your simulated TTY to work at a real 110 baud.  Even if the 
simulation ran at 30x the rate of the original machine on a a fast host, an 
equivalent of 3300 baud is still painfully slow.  So Bob has elected to set 
device timing "as low as it will go" to get contemporary responsiveness.  

But sometimes we find old software that has timing expectations built in.  
Diagnostics are one area where actual timing (in machine instructions) of 
peripherals is often checked.  That's why several of the HP devices have a 
REALTIME vs. FASTTIME option.  But other system software occasionally has 
timing dependencies.  

Generally, these are because the programmers "knew" that an interrupt 
couldn't possibly occur until a certain amount of time elapsed, and so the 
code wasn't protected.  I haven't examined MSU BASIC closely, but that 
appears to be what's happening here.  

Essentially, you're seeing a stack overflow.  For output, the program saves 
the system state, enters the TTY driver to output a character, and restores 
the system state to wait for the completion interrupt, which would occur 
100 milliseconds later on a real machine.  Under SIMH with the default 
TTIME, though, the completion interrupt occurs before the state stack is 
popped, resulting in another stack push, the next character output, etc.  
Eventually, the stack overflows, the program wanders off into the weeds, 
and the machine halts.  

You can probably trim the TTIME down by trial-and-error, or by tracing the 
code path in the program and determining the minimum number of instructions 
necessary before an interrupt can safely occur.  The former is easier, but 
the latter is more robust if more time-consuming.  

                                      -- Dave