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.
simh debug integration is only done during simh builds, the original QEMU debug functionality is preserved. The slirp debug flags can be set by the environment variable SLIRP_DEBUG. Mask values 1 - CALL, 2 - MISC, 3 - ERROR.
This should work on all byte addressable host systems using GCC/clang to build.
The QEMU slirp code has been pried out of QEMU and stubs have been created to solve where the current slirp is entangled with the QEMU code. Ths slirp/simh directory contains all the necessary include and glue files to make this useful. Everything in the slirp directory is unmodified QEMU code.
This version of slirp is a fork from QEMU Version 2.4.0.1 slirp implementation
Taken from commit id of 474590efc51f262fb5d81ca417d510cb7fb7a914
in the qemu repository git://repo.or.cz/qemu/ar7.git
Thanks to Fabrice Bellard.
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.
