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.
The RSX-11M+ boot driver expects a slower response from the simulated
UDA50 controller. This response is only in during the MSCP initialization
sequence, so normal protocol interactions for read and write I/O are
unchanged. Updated value determined by John Forcast. Fixes#216.
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
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.
Overruns can happen on simulated MUX lines using TCP since multiple characters can arrive in a single network packet. Overruns still are reported if previous input characters haven't been read within 500ms. Edmund Marr reported this problem.
Cleanup/Simplification by:
1) removing irrelevant master flag variable from sim_close_sock and thus sim_err_sock
2) change previous boolean feature arguments (datagram, nodelay, reuseaddr) to flag bits in a single option argument. This allows for features to be added by new flag bits which don't change the calling signatures.
3) changed all status returns to be int (vs t_stat) with success being 0 and error being -1
4) removed unneeded simh specific type references to allow sim_sock to be used by n
Extended API by providing flags to influence socket setup/behavior:
SIM_SOCK_OPT_REUSEADDR Retains prior behavior when sim_switches had -U set
SIM_SOCK_OPT_DATAGRAM UDP socket setup provided for when prior datagram argument was specified
SIM_SOCK_OPT_NODELAY TCP Nagle disable provided for when prior nodelay argument was specified
SIM_SOCK_OPT_BLOCKING Blocking socket mode (detault is non blocking)
Make sure to properly support multiple receive buffers by correctly setting the data length read and the appropriate buffer descriptor status bits for each buffer descriptor that is used to hold a packet.
This capability will allow a GDB RSB stub to be created to support dynamic debugging of code running in a simulator.
This capability will also allow a complete front panel emulation system to operate a simulator.
This capability is engaged in a simulator by:
sim> set remote telnet=remoteconsoleport#
sim> set console telnet=consoleport#
sim> set remote master
Master mode will provide a TCP session which accepts SCP commands that allow full control of the simulator.
