The goals here being to simplify calling code while getting consistent output delivered everywhere it may be useful.
Modified most places which explicitly used sim_log or merely called printf to now avoid doing that and merely call sim_printf().
Finishing the last DECtape device which was missed when this functionality was added to pdp11_dt, pdp18b_dt and pdp8_dt
in commits: 2934112a70 and c9e8121c16
Cleaned up the pdp11, pdp18b and other pdp8 implementations to make backporting cleaner.
Made sure that buffer flushing happens correctly when simulation returns to the sim> prompt.
Now all DDCMP capable devices KDP, DUP and DMC/DMR have access to packet corruption generation to simulate real world imperfect data lines for protocol testing.
Also, always process initialization commands without regard to whether the DMC/DMR line is attached and return diag error status if the line isn't attached.
The interrupt acknowledgment logic for the transmit interrupt inadvertently cleared the device interrupt pending flag even when other devices potentially had pending interrupts.
Added line specific indications in the debug output for packet trace debugging.
John Dundas said:
Bob and all,
I ran across what I believe to be a bug in the CSM code:
case 070: /* CSM */
if (CPUT (HAS_CSM) && (MMR3 & MMR3_CSM) || (cm != MD_KER)) {
According to the Architecture Handbook, CSM may be executed only if the MMR3 bit is set AND the mode is not Kernel. Changing the code to:
case 070: /* CSM */
if (CPUT (HAS_CSM) && (MMR3 & MMR3_CSM) && (cm != MD_KER)) {
also has the effect of making the ZKDKB0 diagnostic much happier.
Thanks,
John
--
John A. Dundas III
This is the results of external KDP development activities. The KDP side done by Timothe Litt and DMC and DUP by Mark Pizzolato
Additionally, other PDP10 updates from Timothe Litt
From Timothe Litt:
- Detect vector conflicts, SHOW IOSPACE
- Detect conflicting vector assignments.
- Correct show iospace display of high vector for multi-unit devices
- Display vectors in DEV_RDX in show iospace
- Ignore disabled devices when searching for conflict.
- Improve device conflict reporting, Report both devices when address conflict is detected.
From Mark Pizzolato:
- Added optional alternate radix output display for device address and vector values
displayed by SHOW DEVICE.
-H and -O switches select hex or octal output in addition to the default radix displayed
by the normal simulator.
This required a simulator specific implementation since the PDP11 PC register isn't stored in a normal memory location. It is loaded from a temporary location upon simulator instruction execution startup (and saved to that location when instuction execution stops). In order to reference the PC value while executing instructions (for debug output), this extended access model is required.
Separate boot ROMs are available for each of the DEQNA, DELQA and DELQA-T devices being simulated.
DEQNA-Lock mode has been added to the DELQA and DELQA-T simulations.
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'
