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
A multiplexer may have a combination of speed limited behaviors on
different lines, and there may be lines which are idle and lines which
are actively receiving input. Some of the problems described in #252
are fixed by this.
When creating a new disk image the new disk image can be populated with
unique data in each sector. The data is the logical block address of the sector
in a 4 byte little-endian value. This is enabled when the -I switch is specified
on the ATTACH command. To leverage this, a -K flag is interpreted on the
ATTACH command which will validate the entire disk contents actually
contains the expected value at attach time and also will validate that any data
written to the disk during simulator operation also contains the same logical
block address values.
Many simulators run instructions one or more orders of magnitude faster
than the original systems did. Limiting simulated serial port input speeds
to legacy bits per second values presents the arriving data much slower
than the original systems ever saw it. Given the processing capacity of the
simulated systems and the fact that the software and device interfaces
only know how to deal with the legacy speed values there is a need to
provide a way to allow input to arrive faster. This problem is solved by
providing a speed factor as a part of a speed specification. For example
a speed can be specified as "speed*factor" or "9600*10".
OBSERVATION: Calling "sim_tape_rdrecf" to read a tape record sometimes
returns MTSE_EOM and sets the "position not updated" (PNU) flag, even when
an erase gap precedes the EOM. The correct response should be to return
MTSE_RUNAWAY to indicate that spacing over a gap did not end with a data
record or tape mark. Moreover, PNU should not be set, as the position has
been updated.
CAUSE: The routine attempts to handle this case by returning MTSE_RUNAWAY
if the EOF was detected while reading a buffer of gap markers. However, if
a buffer read ends immediately before an EOM marker or the physical EOF,
the next read attempt will return a zero buffer length. The routine
misinterprets this to mean that no gap was present and returns MTSE_EOM and
sets the PNU flag.
RESOLUTION: Modify "sim_tape_rdlntf" (sim_tape.c) to determine whether the
EOM marker or physical EOF was seen on the first or a subsequent buffer
read, and to return MTSE_EOM with PNU or MTSE_RUNAWAY without PNU,
respectively.
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.
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
A SET CONSOLE SPEED=nnn, where legal values for nnn are common serial
port rates. The speed value will attempt to limit the input data rates to a
simulator to approximately the specified bits per second.
The conversion of time to instructions can overflow an int32 when the
current instructions per second is high and the delay interval is high.
We limit the instruction delay to the maximum value available in an int32,
which for essentially all cases won't matter since the resulting delay is used
for a drop dead timeout and doesn't need to be precise or it will be
canceled before it ever fires anyway.
