- Add support to query remaining usecs on pending events.
- Generalized the sim_interval adjustment in sim_idle to allow more than
a single decrement.
- More overhead reduction when idling.
- Carry usec values as double through out to fully support long wall clock
delays.
Clock devices which call sim_register_clock_unit or sim_register_clock_unit_tmr
are best behaved if they use sim_activate_after to schedule their tick events.
Asynchronous clocks are now built for all simulators which are built with
SIM_ASYNCH_IO defined. The default behavior has asynchronous clocks
disabled since this is still experimental, but it can be enabled with
SET TIMER ASYNC.
Catchup clock ticks are now available, but since they're experimental,
they aren't enabled by default. Catchup ticks are only available if the
simulators clock device calls sim_rtcn_tick_ack to acknowledge processing
of clock ticks. The VAX simulators have been modified to leverage this.
Catchup clock ticks can be enabled with SET TIMER CATCHUP
Additionally, an idle threshold is provided which can be used to
influence when clock calibration may be suppressed. The default is not
to suppress calibration activities.
The various timer behaviors are visible with the SHOW TIMER command.
The state of the operating timer facilities is visible with: SHOW CLOCK
Timer events which are queued are visible with the SHOW QUEUE command.
Reworked all priority adjustment code to leverage a new
sim_os_set_thread_priority API which is coded to use pthreads or OS
priority adjustment APIs as necessary.
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.
When a new connection arrives it will be bound to the first line found
which has DTR enabled (considering the line order rules). If none is
available, then all currently unconnected lines will have the RING signal
enabled. If no such lines exist, the incoming connection is rejected with
"All connections busy". If a currently disconnected line (with RING
enabled) raises DTR within 3 seconds, then that line gets the pending
connection and all other lines with RING enabled have RING disabled.
If 3 seconds pass without DTR coming up on any line with RING enabled
coming on, all lines with RING enabled will have RING disabled and the
incoming connection will be rejected with "No answer on any connection"
Full modem lines depend on the simulated OS to fully configure the line
parameters (speed, parity, etc.), so setting line speed during a normal
attach violates that behavior. However, when a RESTORE operation is
being performed, we are obliged to restore the OS set line parameters
which we know were already set by the simulated OS.
To promote clarity of experience, a user on a telnet connected line (which
supports modem control signaling) will receive a "Disconnected from
{simulator name}" message when a session is explicitly terminated by the
simulated system. This allows the user to differentiate that case from the
simulator merely being powered off or otherwise crashing. This behavior
mirrors the "Connected to the {simulator name}" message that is presented
when the connection is established.
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.
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".
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.
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.
