sim> SET XQ MAC=aa:bb:cc:dd:ee:ff{/bits}{>filespec}
where:
- all of the aa:bb:cc:dd:ee:ff values must be hex digits
- bits is the number of bits which are to be taken from the supplied
MAC aa:bb:cc:dd:ee:ff with legal values from 16 to 48 and a default
of 48 bits.
- filespec specifies a file which contains the MAC address to be used
and if it doesn't exist an appropriate generated address will be stored
in this file and a subsequent SET MAC invocation specifying the same
file will use the value stored in the file rather than generating a new
MAC.
As discussed in #317
Multiple devices sharing the same pool of fixed and/or vector addresses
need to properly account for earlier devices that may have already consumed
available fixed addresses or vectors.
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
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.
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.
The problem has to do with the difference in how the PSW is stored when
the simulator is running (it's all in pieces) or stopped (it's collected in PSW).
cpu_ex is a console routine and expects the PSW to be stored in PSW, but
when history is collected, it's not. In particular, cm (current mode) is in local
variable cm.
cpu_ex with /v calls relocC, which derives the current mode from the
switches:
- if /ksup, use kernel/supervisor/user/previous mode (from PSW); otherwise,
use current mode from PSW
- if /d, use data space; otherwise, use instruction space
relocC is doing current mode i-space, which is what's wanted... except that
it's deriving current mode from PSW, rather than cm, which is where it's stored
while the simulator is running. It's fairly likely that PSW is long obsolete by the
time the history is invoked.
When packets arrive which require multiple receive buffers to deliver, the
full packet size is reported in the MLEN field of the final receive descriptor
used (the one with the ENF bit set). Previously, correct behavior only
happened when the full packet fit into a single receive buffer. This problem
was reported and the detail identified by Johnny Billquist.
Device probe logic when running VAXELN was unable to correctly initialize
the XQ device when it was set to be a DELQA or DELQA-T, but worked when
it was a DEQNA or a DELQA/DELQA-T in DEQNALock mode. Problem
initially reported in #271
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.
