Also changed how interrupts are generated. When a line changes state
and interrupt should be generated. Once this is read no further
notification should be posted. If no characters are written in a
record the DTC should transition to IDLE state.
These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
The processing of initialization commands improperly attempted to initialize
all controllers AND these attempts (for controllers beyond 0) referenced
beyond the bounds of the unit array. This problem was reported in issue #309
The SHOW FEATURES will enumerate all devices in a simulator and for each of
them display the device specific description if one is available.
This change allows the description to be optionally visible for a single device
displayed with SHOW DEVICE.
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.
Users wanting to build simulators with locally build dependent packages or
packages provided by an unsupported package management system can
override where this procedure looks for include files and/or libraries.
Overrides can be specified by define exported environment variables or
GNU make command line arguments which specify INCLUDES and/or LIBRARIES.
Each of these, if specified, must be the complete list include directories
or library directories that should be used with each element separated by
colons. (i.e. INCLUDES=/usr/include/:/usr/local/include/:...)
Binaries built with unsupported library components will have a 'unsupported' tag
in the output of the SHOW VERSION command.
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.
The previous change in handling or SCPE_EXPECT transformed it to SCPE_OK
to avoid unexpected exiting or condition trapping. This didn't allow the
SCPE_EXPECT reason to be display if verbose mode was on.
- 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.
When a new connection arrives it will be bound to the first line found
which has DTR enabled (considering the line order rules). If none is
available, then all currently unconnected lines will have the RING signal
enabled. If no such lines exist, the incoming connection is rejected with
"All connections busy". If a currently disconnected line (with RING
enabled) raises DTR within 3 seconds, then that line gets the pending
connection and all other lines with RING enabled have RING disabled.
If 3 seconds pass without DTR coming up on any line with RING enabled
coming on, all lines with RING enabled will have RING disabled and the
incoming connection will be rejected with "No answer on any connection"
Full modem lines depend on the simulated OS to fully configure the line
parameters (speed, parity, etc.), so setting line speed during a normal
attach violates that behavior. However, when a RESTORE operation is
being performed, we are obliged to restore the OS set line parameters
which we know were already set by the simulated OS.
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.
Also make all scheduled timing behaviors consistent and not performed by
the input polling unit which may have different scheduling characteristics
to reflect input speed rate limiting.
