- Correct RBUF_GETLINE & RBUF_PUTLINE: these are both sensitive to
modeling DHU vs. DHV; the correct bit mask was not generated for DHU.
- Make certain the device presents 16 lines when modeling a DHU.
- The REG definitions support having a REGister be pointing at an
element in an array of structures (or UNITs) as long as the element
is a scalar. Something that is not supported is when the element is
already an array (or buffer). The approach used in the TDC device
creates n additional registers each of which points at the individual
array element in each of the structure in the structure array.
- Fix simple REG declarations which didn't fully describe the size of the
underlying storage holding the REG contents in the TDC and VH
DEVICEs.
As reported in #1025
- Implement a per line transmit FIFO to properly reflect the DHU real hardware
- Output is rate limited based on the programmed port speeds
- Properly abort programmed output
As reported and discussed in #600 and #588
previously, programmed I/O was initiated and completed as the time it was
initiated. Now that output is rate limited to the port selected speeds the
output buffer can fill and I/O be dropped when the buffer was full. Now all
output is setup in the register write path and completed in the unit service
path. A separate transmit service unit now performs all transmit I/O
completion activity.
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.
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.
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.
Data arriving on simulated serial ports can arrive faster than the OS running
on the simulated system can deliber it to user mode programs. This happens
when chunks of data are delivered to the mux from a network connection.
This can be due to a file transfer program (kermit) running on the other end
of a network connection and the packet size being delivered exceeds the
simulated OS's type ahead buffer size OR from users who paste arbitrary
blocks of data into a telnet or console session.
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.
