Add optional enabling of broadcast address to hash based filter model.
LANCE based devices which use its AUTODIN II based hash generally
match the broadcast address independent of the contents of the
multicast hash.
This change to XQ mostly undoes the prior change to pdp11_xq and
brings the functionality into sim_ether so that it is generally available
for future ethernet devices.
Array REGister definitions have been made consistent by passing the
name of the array object. This allows proper sizing assessment
to occur in the register validation logic.
Some previously described array REGister initializers were not really
arrays. Some were structures and others were merely pointers to
someplace in memory that it was desirable to view as a scalar array.
Structures or other blob data should now use SAVEDATA. Virtual
arrays intended to be interpret some part of memory as scalar data
now use VBRDATA initializers.
Some devices have dedicated units that perform various independent
functions (often timing) that are independent of the primary device unit
which is ATTACHed. This services to help interpret debug information
that may be produced.
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
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.
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
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.
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.
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.
CPU Idle detection for this OS is now supported and the combination of SET CPU IDLE=ULTRIX-1.X and explicitly using a DEQNA device (SET XQ TYPE=DEQNA) will enable the automatic enabling of device interrupt generation.
Migrated the XQ help to the hierarchical help model. This is a work in progress which will eventually merge much from 0readme_ethernet.txt into the device help.
The goals here being to simplify calling code while getting consistent output delivered everywhere it may be useful.
Modified most places which explicitly used sim_log or merely called printf to now avoid doing that and merely call sim_printf().
Separate boot ROMs are available for each of the DEQNA, DELQA and DELQA-T devices being simulated.
DEQNA-Lock mode has been added to the DELQA and DELQA-T simulations.
Show IOSPACE doesn't always get the number of devices right due to device creativity.
o The distinction between UNIT and DEVICE has blurred
o MUX devices merge several physical devices into one device/unit
o Dynamic device sizing has made things more volatile.
This edit solves the problem for SHOW IOSPACE by adding an (optional) word to the DIBs.
The word contains the amount of IO space consumed by each instance of the physical device that's being emulated.
E.G., if it's a DZ11, the device is the DZ11 module, or 8 lines, even though the MUX device may support 32.
This enables SHOW IOSPACE to determine the number of physical devices being emulated, which is what folks need when configuring software. The word may have other uses - in a generic dynamic device sizing routine - which is why the amount of IOSPACE per device was chosen rather than the 'number of physical devices.'
The edit should not make any existing device regress. If the new word (ulnt) is zero (not initialized), SHOW IOSPACE will default to the number of units in the device, or if there's no device (CPUs), 1 as before. If it is present, the number of devices is the calculated as total allocation/allocation-per-device.
The edit updates all the devices that seem to require this treatment, and all the processors that define the UNIBUS/QBUS DIBs.
The problem is that Map_ReadW reads 16-bit words from guest's memory and stores them in host-endian-byte-order in xq_turbo_init_block. Most entries in xq_turbo_init_block are 16-bit words (thus it is ok that they are stored in host-endian-byte-order), but there are three fields in this data structure which are referenced as byte oriented fields. (phys, hash_filter and bootpassword). These fields need to be handled in byte order to be properly interpreted.
