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.
Many simulators run instructions one or more orders of magnitude faster
than the original systems did. Limiting simulated serial port input speeds
to legacy bits per second values presents the arriving data much slower
than the original systems ever saw it. Given the processing capacity of the
simulated systems and the fact that the software and device interfaces
only know how to deal with the legacy speed values there is a need to
provide a way to allow input to arrive faster. This problem is solved by
providing a speed factor as a part of a speed specification. For example
a speed can be specified as "speed*factor" or "9600*10".
OBSERVATION: Calling "sim_tape_rdrecf" to read a tape record sometimes
returns MTSE_EOM and sets the "position not updated" (PNU) flag, even when
an erase gap precedes the EOM. The correct response should be to return
MTSE_RUNAWAY to indicate that spacing over a gap did not end with a data
record or tape mark. Moreover, PNU should not be set, as the position has
been updated.
CAUSE: The routine attempts to handle this case by returning MTSE_RUNAWAY
if the EOF was detected while reading a buffer of gap markers. However, if
a buffer read ends immediately before an EOM marker or the physical EOF,
the next read attempt will return a zero buffer length. The routine
misinterprets this to mean that no gap was present and returns MTSE_EOM and
sets the PNU flag.
RESOLUTION: Modify "sim_tape_rdlntf" (sim_tape.c) to determine whether the
EOM marker or physical EOF was seen on the first or a subsequent buffer
read, and to return MTSE_EOM with PNU or MTSE_RUNAWAY without PNU,
respectively.
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.
