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
If a TPC format tape image has garbage at the end of the image, but the
image contains multiple successive tape marks, then assume that logical
End Of Tape is immediately after the last successive tape marks.
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.
The first disk controller made by North Star was a single density
controller (MDSA). This was followed by the double density controller
(MDSAD) that is already supported in SIMH. This update adds support for
the single density controller as device MDSA. Since the controllers are
not software compatible, this update allows running of older software
designed for the MDSA controller.
The MicroVAX II boot ROM has code uses one of these instructions with the
data being referenced somewhere in Qbus space. This is not supposed to be
done according to the architecture specifications, but it must have worked on
real hardware. In any case, as a consequence of this reference to I/O space,
these otherwise non-data modifying instructions can have side effects or
reference data which may change even in an instruction looping on itself.
Given that potential, such use isn't an infinite loop which would otherwise
inspire a drop back to scp.
The original implementation coupled the elapsed time measurement
to the 100Hz internal calibration clock. This worked well enough for very
long intervals but not well at all for any intervals less than 50ms. The net
result is that it couldn't usefully be used to produce the 60Hz clock ticks
which Unix 32V used it for. It now leverages the microsecond timing
provided by sim_activate_after(). This problem is reported in #253
This allows pending I/O (console, or otherwise) to complete before dropping
back to the sim> prompt. This better simulates the model where scp is analogous
to the console processor on the older VAX simulators. This better addresses the
incomplete I/O problems discussed in #208
A multiplexer may have a combination of speed limited behaviors on
different lines, and there may be lines which are idle and lines which
are actively receiving input. Some of the problems described in #252
are fixed by this.
When creating a new disk image the new disk image can be populated with
unique data in each sector. The data is the logical block address of the sector
in a 4 byte little-endian value. This is enabled when the -I switch is specified
on the ATTACH command. To leverage this, a -K flag is interpreted on the
ATTACH command which will validate the entire disk contents actually
contains the expected value at attach time and also will validate that any data
written to the disk during simulator operation also contains the same logical
block address values.
