[Simh] PDP11 init behavior

[Bob Supnik]

Here's a PDP11 SIMH bug as old as the simulator itself: the reset_cpu 
routine sets the PS to 340 (interrupts disabled). This causes some 
versions of Lunar Lander not to work. In fact, the initial state of the 
PS is not architecturally standardized:

      04: cleared (from schematics)
      05: cleared (from manual)
      20: cleared (from schematics)
      34: cleared (from schematics), set to 340 on boot?
      40: cleared (from schematics)
      44: cleared on init, set to 340 on boot (from schematics, manual)
      45: cleared (from schematics)
      60: cleared (from schematics)
      70: cleared (from schematics)
      T11: set to 340 (from spec)
      LSI11, F11: 4 mode behavior (from memory on power recovery, 
cleared on GO, 340 on boot, mode 3 undefined)
      J11: 4 mode behavior (from memory on power recovery, cleared on 
GO, 340 on boot, 340 on jump to  custom PROM)

The story seems to be this. All non-VLSI PDP11s used TTL chips to 
implement the PS, either discrete flip-flops, or 4b registers, or both. 
Starting with the first system, the 11/20, they were wired clear on the 
processor INIT signal (power-up or front panel START switch), so that 
all internal state started as 0. This worked fine, because START also 
reset the Unibus and cleared all interrupt enables. So even though the 
processor was as IPL = 0, no interrupts were possible. Then along came 
the LSI11...

The LSI11 implemented a line-time clock with NO INTERRUPT DISABLE. Thus, 
if IPL was left at 0 and a bootstrap routine from a slow device was 
started (e.g., a floppy drive), the clock would tick, and an interrupt 
would occur, before the bootstrap routine finished. Because no vectors 
were set up, the processor would crash. So the LSI11 started the 
practice, carried over to all later PDP11 VLSI chips, of setting the PS 
to 340 before jumping to a boot ROM.

The T11 did this in all modes of startup, because its only startup 
behavior was to jump to a "boot" routine. It did not have a console of 
any kind.

Accordingly, it appears that the cpu_reset routine needs to set the PS 
based on the processor model. Further, all boot routines need to set the 
PS to 0 or 340 based on the processor model. (It's probably safe for 
boot routines just to set the PS to 340, but it's not technically 
accurate.) These are a rather intrusive set of changes, so before I 
implement them, I wanted some comments from the community.

/Bob