When a mix of Massbus devices are configured with some enabled and
others disabled, the MBA's need to be allocated and properly configured
in the desired preferred order (RP, TU, RS). On the PDP11, this interacts
with auto-configure since the RH devices are visible in the Unibus I/O
page. On the PDP11 the second Massbus device can only be configured
if the TM device is disabled since the auto-configure assigned vectors
overlap for RHB and TM.
Problem originally reported in #301.
Observations made about NVR behavior on real hardware:
1) Aligned writes only affect a single RAM location
without regard to the size of write, so no double
pumping on writes.
2) Unaligned (offset 3) writes do nothing without regard to size of the write
3) Unaligned (offset 1) write 0 to the next higher NVR RAM location.
4) Longword aligned and Unaligned (offset 3) reads return the same NVR RAM
value in the the upper and lower words of the result.
5) Unaligned (offset 1) reads reference the next higher NVR RAM cell for
word and longword reads.
- Fix write behavior to match hardware.
- Fix read behavior to double pump word values for all unaligned word and longword
reads.
- In VMS mode, the day and month have to behave correctly to map the
current day of year to the equivalent day of year in 1982
- The month maintained and returned by the watch chip has January as 1
while the tm_mon field in the 'struct tm' has 0 for January.
A user could change the contents of the PSL via a DEPOSIT command.
If the resulting PSL indicates Interrupt Stack and IPL is 0, then this is
equivalent to MTPR #0,#IPL which is explicitly described as "undefined"
When a MTPR #0,#IPL is performed, the VAX chip microcode doesn't check,
neither does the 780 microcode. Nothing bad will happen immediately,
however when an interrupt occurs, the saved PSL will now contain IPL 0
and Interrupt Stack. This combination will cause the REI dismissing the
taken interrupt to fail. To avoid a user manually creating this via
a DEPOSIT command or to potentially detect this condition while stepping
through instructions this check refuses to execute when the PSL is
invalid. This change merely provides an explanation.
On page 5-37 of the VAX SRM (DEC standard 32), the REI pseudo-code defines
exactly what a legal PSL looks like. The check at the beginning of
sim_instr is a direct implementation of that check, intended to prevent
the user from creating an inconsistent PSL through the simulator console.
In a VAX chip, the console code would exit by a genuine REI, and any
illegal value created by the user would cause a system stop (return to the
console).
On page 5-43, the revision history notes that in rev 8 of chapter 5,
MTPR #0,#IPL was made undefined. Because MXPR is privileged, and the
general assumption was that VMS knew what it was doing, no one realized
the potential inconsistency that MTPR #IPL could create until it was
too late. "Undefined" allows any behavior, up to and including blowing up
the system.
This is invoked with STEP -R nnn, or CONT -R. Execution will continue
across any new subroutines which are called and stop after the current
routine executes a RET or RSB instruction.
SET CPU IDLE={OS{:n}} where n is the idle stability delay
which is also the clock calibration delay.
A -D switch on a SHOW -D CPU IDLE command will
display the stability delay as will a SHOW CLOCK command.
simulator time allows instruction history to be precisely correlated with
debug output. It also provides a way to reproduce and review simulation
activities by stopping at predetermined time values (via STEP) to
examine details of simulator state.
disk logging can be useful to compare activities performed in separate
simulator runs.
This can't currently happen since the rtVAX1000 doesn't include the
QVSS video device. It probably should contain this device since VAXELN
was recently recovered and one of the features VAXELN provided was
a way for 'old' VAXStation hardware to be repurposed into X-Window
terminals.
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.
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
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.
Prior logic attempted to load the desired file from the current default directory and if that failed wrote the in memory boot code image to the desired file and then retried the desired load..
A user can still explicitly load a ROM image with a "LOAD -R romfile.bin" command prior to a BOOT attempt if they want to test or otherwise run with a different ROM.
Problem was the console storage output buffer was masked with a WMASK instead of a BMASK (it is only a 8 bit register).
Also, the input interrupt processing cleared the output interrupt state instead of the input interrupt state. This would only be a problem when interrupts are actually used instead of polled I/O.
