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.)
PDP11/pdp11_io_lib.c: In function 'show_iospace':
PDP11/pdp11_io_lib.c:363: warning: too few arguments for format
PDP10/pdp10_lp20.c: In function 'lp20_set_vfu_type':
PDP10/pdp10_lp20.c:1038: warning: implicit declaration of function
'toupper'
PDP10/pdp10_lp20.c:1121: warning: implicit declaration of function
'isspace'
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.
Show IOSPACE doesn't always get the number of devices right due to device creativity.
o The distinction between UNIT and DEVICE has blurred
o MUX devices merge several physical devices into one device/unit
o Dynamic device sizing has made things more volatile.
This edit solves the problem for SHOW IOSPACE by adding an (optional) word to the DIBs.
The word contains the amount of IO space consumed by each instance of the physical device that's being emulated.
E.G., if it's a DZ11, the device is the DZ11 module, or 8 lines, even though the MUX device may support 32.
This enables SHOW IOSPACE to determine the number of physical devices being emulated, which is what folks need when configuring software. The word may have other uses - in a generic dynamic device sizing routine - which is why the amount of IOSPACE per device was chosen rather than the 'number of physical devices.'
The edit should not make any existing device regress. If the new word (ulnt) is zero (not initialized), SHOW IOSPACE will default to the number of units in the device, or if there's no device (CPUs), 1 as before. If it is present, the number of devices is the calculated as total allocation/allocation-per-device.
The edit updates all the devices that seem to require this treatment, and all the processors that define the UNIBUS/QBUS DIBs.
Make the card reader work on TOPS-10 and TOPS-20.
Augmented Image ECO was not implemented.
Simplify UI by defining commands for the various options/models emulated based on the simulator being built.
Document, and make the help conditional on model where that reduces clutter.
Deal with <CR><LF> reading ASCII files (file is opened 'rb' in scp's attach ; it shouldn't be.
Add translation support for DEC 026/029 full 7-bit ASCII, an ANSI standard & used by TOPS-10/20.
Deliver EOF at the correct time(s).
Preliminary support for update to card image spec being negotiated with the author.
Thanks to Ian Hammond, Lou Ernst, Malcolm Macloud, and Jack Rubin,
In addition, I've added the CAPS11 bootstrap into the emulator module, so no more toggle-in required.
Lou Ernst reported that RT11 V5 does not work with the TA11, even on real hardware. The simulated TA11 does work under RT11 V4; it's included in the stock FB monitor.
One anomaly with RT11 V4 - after writing files to CT0: and then doing a DIRECTORY, all the files lengths are 0. The files are there. I can type them and DIFF them against their source.
It does not fix the problem that MMR1 is not used for floating point instructions.
I don't know if I will fix the FP MMR1 problem. It does not seem to impact running software. It is consistent with the architecture spec - just not with the actual J11 implementation. The J11 microcode has a variety of exception exits for FP conditions, and I have to trace which ones invoke fix-up, and which do not.
