- Added halfduplex mode for network connections and corrected modem signal DSR to reflect connection status (vs original attach status), and DCD follows DSR (except in halfduplex mode where it follows CTS).
- Enhance tmxr_set_get_modem_bits to also return the modem DTR and RTS state.
- Separate RTS from DTR when manipulating modem state bits
- Minor fixes to loopback functionality after direct testing with the first loopback client device (DMC11).
- Fix clearing of break input buffer now that input buffers are dynamically allocated
- Changed Modem bit logic to have CTS reflect RTS as expected by devices which may expect this.
- Changed receive buffers to be dynamically allocated and the same size as transmit buffers when transmit buffers are non-default sized.
- Added TMXR line attach in loopback mode. Fixed loopback buffer management
- Added loopback support to TMXR lines
- Added functioning connect poll capability to revised DMC
- Added connection destination display to connection status even when a connection has not yet been established.
- Added extended packet sending and receiving semantics to TMXR allowing for an optional frame byte to exist between length prefixed data packets
- Avoid assignments of void * values. Cast all memory allocation return values to appropriate types.
- Add output to sim_log where missing in various places.
- Fixed issue with lost file positions after a restore for devices which leverage the UNIT_SEQ flag.
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.
When the conversational boot is waiting for input it uses a BLBC instruction to read the DUART status register and test the RXR bit. This generates an unaligned longword read in Qbus I/O space (Yuk!). I realised that the code to read unaligned data in vax_mmu is broken. It attempts to read the aligned longwords that the data spans, but there was no code to convert the unaligned pa passed in to it's aligned form, thus the wrong bytes are returned and the BLBC never sees the RXR bit.
The vertical sync interrupt generated in vc_svc() was too slow for Ultrix. The driver enables interrupts and then calls DELAY(20000), which I guess is 20ms. This translates to about 10000 simulated instructions, but tmxr_poll works out at ~75000 instructions. I've added a new unit to simulate just the vsync interrupts activating every 8000 instructions.
This approach will completely disable the ability to idle while the QVSS device is enabled.
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.)
Fixes several bugs described several months ago on the simh list about how the hardware really works, most notably the "dummy" cycle created by an OCP '1 (switch to output mode). In addition, it fixes other problems (OCP '0 and OCP '1 are unconditional) and adds a "busy"
state on character input, like the real hardware.
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'
