Both VT11 and VS60 properly autoconfigure on the PDP11.
PDP11 now runs Lunar Lander on all SDL supported platforms.
Reworked refresh logic to not require internal delays in the display library
If a driver sets up a receive buffer descriptor list as a circular ring, the
potential exists for a burst of arriving packets to wrap around the receive
buffer ring in a single round of input processing. This is avoided by
stopping list processing when a full circle has been observed.
Additionally, debug output has been added to display issues while
processing both the receive buffer descriptor list and the transmit buffer
descriptor list. The debug bit names are RBDL and XBDL respectively.
PDP11 network boot ROM of the DEQNA, DELQA, and DELQA-T along with
the MicroVAX I ROM boot each expect particular behavior from the XQ
device. Prior efforts to get the PDP11 boot working added several device
specific complications to the receive buffer processing. These are now
simplified. Meanwhile, the generic device 'work alike' boot process has
been implemented to provide an XQ (device independent) primary
loader which extracts the first 512 bytes of the device internal boot
ROM and passes control to it for a complete boot.
Dynamically configured devices simulate multiple controllers with a single DEVICE structure and can have the number of controllers being simulated set by the user. DLI, DZ, DUP, DMC, TDC, VH, DC are all dynamically configured devices.
DLI and TDC are dynamically configured devices which get static bus addresses.
When an auto configuration table entry contains multiple devices be sure
to account for earlier devices which may be disabled while allocating fixed
address and vector values. Examples: XQ, XQB, RB, RQB, RQC, RQD, RX, RY
This problem is discussed in #263
The mapping of addresses in the I/O page needs to be populated before
it can be referenced. This change allows commands at the initial sim>
prompt to touch device registers with EXAMINE and DEPOSIT as discussed
in #261
Buggy device driver code exists which enables the receiver before
properly establishing receive buffers. That code worked most of the
time on real hardware since it was hard for the device to receive a
packet and try to deliver it before the driver actually setup the receive
buffer descriptor list. Discussion in #220.
Previously, the input silo was modeled by using the pending input data in
the TMXR line buffer. This was fine when bps rate limiting wasn't happening.
In order to properly pace arriving data from multiple lines the silo is now
implemented in a way which more precisely reflects the original hardware.
The RSX-11M+ boot driver expects a slower response from the simulated
UDA50 controller. This response is only in during the MSCP initialization
sequence, so normal protocol interactions for read and write I/O are
unchanged. Updated value determined by John Forcast. Fixes#216.
Each of the speeds greater than 9600bps deliver a character in less than
1ms. Computing inter-character delays in microseconds therefore can't
be precise enough to be well behaved. Measuring the inter-character
delays in instructions (scalled by the calibrated clock) gets us the needed
precision.
Data arriving on simulated serial ports can arrive faster than the OS running
on the simulated system can deliber it to user mode programs. This happens
when chunks of data are delivered to the mux from a network connection.
This can be due to a file transfer program (kermit) running on the other end
of a network connection and the packet size being delivered exceeds the
simulated OS's type ahead buffer size OR from users who paste arbitrary
blocks of data into a telnet or console session.
This is necessary to avoid kernel type ahead buffer overruns when a user
pastes a chunk of data into a console session as described in issue #246
Other console input speeds can be set with SET CONSOLE SPEED=nnn
Vector values contained in device information blocks are the true bus relative vector values. CPU specific biased vector values are produced by the respective vector fetching logic and vector values are limited to 9 bits with <1:0> = 0 as specified in both the Unibus and Qbus documents.
Overruns can happen on simulated MUX lines using TCP since multiple characters can arrive in a single network packet. Overruns still are reported if previous input characters haven't been read within 500ms. Edmund Marr reported this problem.
