A similar problem exists in the PDP8, PDP18B, and potentially the VAX.
The problem is a side effect of an attempted optimization around
idling. Idling will sleep the CPU only if the queue of IO events has no
IO events scheduled for a period of time at least as long as the minimum
sleep interval (typically 1msec these days). This sleep interval has to
be calibrated against real-world time; otherwise, the real-time clock
will get out of sync with wall time.
As hosts have become faster, the keyboard activity probe (which was set
at 5000 cycles back in the 90s) has become too short, and as a result,
the CPU would never choose to idle. The idle probe interval could be
set to a larger value, but a "better" solution is to calibrate it to the
real-time clock, and probe when the clock ticks (typically, 50 to 100
times per second). If the terminal multiplexor probes are also
synchronized, then the simulator will handle all these events at the
same time, and the event queue will tend to have more "sleepable" intervals.
While the keyboard probe is scheduled from simulator start, in some
systems the clock and the terminal multiplexor probes can get turned on
or off by software. Accordingly, the keyboard probe was scheduled with
sim_activate_abs, which sets the probe time to an absolute time in the
future. The default, sim_activate, will not change the scheduled time
if the event is already scheduled.
So the short-term answer is to revert all the keyboard scheduling from
sim_activate_abs to sim_activate, recognizing that these
clock-calibrated events can drift out of sync and thus reduce the
efficiency of idling, or even make it not work altogether.
Long-term, it might make sense to segregate events that are scheduled
off the instruction counter from events that are scheduled against
real-time, either inside a simulator or at the SCP level. But that's a
discussion for another day.
The failing sequences are:
PDP8, PDP18B:
CAF
JMP *-1
VAX:
10$: MTPR R0,#IORESET
BR 10$
PDP11:
10$: RESET
BR 10$
For the VAX, there's an open question whether MTPR IORESET, which is
supposed to reset the Qbus devices, also resets internal devices like
the console terminal.
/Bob
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
