These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
When a mix of Massbus devices are configured with some enabled and
others disabled, the MBA's need to be allocated and properly configured
in the desired preferred order (RP, TU, RS). On the PDP11, this interacts
with auto-configure since the RH devices are visible in the Unibus I/O
page. On the PDP11 the second Massbus device can only be configured
if the TM device is disabled since the auto-configure assigned vectors
overlap for RHB and TM.
Problem originally reported in #301.
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.)
Note that this is not the fully general Massbus implementation people were dreaming of. MB#1 is for RP/RM, MB#2 is for TU, and MB#3 is for RS.
I know that there were requests for four Massbus channels and multiple RP/RP subcontrollers, but if people want more disks, they can use the RQ.
