Default behavior is to schedule the inter character I/O based on the
TIME (PTP, PTR) and TTIME (TTY) register variables. With default values
here I/O completes very quickly.
A user may influence I/O rate behavior to proceed at a particular character
rate per second by using:
sim> SET CPU CPS=nnn
or equivalently:
sim> SET CPS=nnn
The resulting I/O completion rate will be independent of host system
processor speed and/or any I/O throttling that may be in effect. The
above commands set the deferred I/O character completion rate for
all devices that do deferred I/O (PTP, PTR and TTY).
Each deferred I/O device can have its particular character delivery rates
specified with one of these commands:
sim> deposit PTP CPS xxx
sim> deposit PTR CPS yyy
sim> deposit TTY CPS zzz
A CPS register value of 0 indicates that the default cycle based delays
specified by TIME (PTP & PTR) and TTIME (TTY) registers will control
character completion rates.
- Default CPS is 50
- Add SET {CPU} CPS=nnn and SHOW {CPU} CPS commands.
Individual device specific rates are changeable and visible as CPS register
in each device.
With this update, the erase gap operation has been split out of
"sim_tape_wrgap" into a separate, internal "tape_erase_fwd" routine that
is called from "sim_tape_wrgap" as well as from the new "sim_tape_errecf"
routine. There's a corresponding internal "tape_erase_rev" that's called
from the new "sim_tape_errecr" routine.
I've shimmed "sim_tape_rdlntf" and "sim_tape_rdlntr" to move the tape
context and debug stuff out of the routines that I'm maintaining. This
will allow me to replace those functions in their entirety with the
corresponding functions in my development sources for future updates.
It also allows me to keep Bob's version in sync. As my routines are static
and only called once from the shims, compilers should optimize away
the function calls and instead inline the code, so there'd be no extra call
overhead.
I'd also like to keep "tape_erase_fwd" and "tape_erase_rev" untouched for
the same reason. If you wish to add debug calls to "sim_tape_errecf" and
"sim_tape_errecr", that's fine.
The major change is the implementation of deferred IO - a more
accurate implementation of the 1620's "stop in its tracks" IO model.
When a device uses deferred IO, instruction execution is suspended
until the IO completes successfully. Operator interruptions, errors,
and so on do not return to instruction execution; this only occurs if
the IO completes successfully or the command SET CPU RELEASE is given
(equivalent of pressing the RELEASE button). Otherwise, the current IO
operation continues to execute.
Only the console typewriter and paper tape reader/punch currently
implement deferred IO; there are operational issues with those devices
that require more accurate modeling. The card reader/punch, line
printer, and disk still execute IO "instantaneously". It's not all
that hard to convert an instantaneous device to deferred operation,
but there's no point in doing so (and possibly introducing new bugs)
unless there's an actual operational issue. The 1620 doesn't have
overlapped IO, so programs can't tell the difference, by and large.
A number of other issues have been addressed as well, including the
bizarre "treat RM as 0 in the Q field" required by MI-015; the
treatment of non-existent indicators as always off; and various other
tweaks.
I've run CU01 (again), which at least gives typewriter and paper-tape
IO a basic workout; and it works. I leave more detailed testing to
people who know the machine better than I do.
The documentation has been updated to include Tom's detailed breakdown
of IO handling for all IO operations on the typewriter, paper-tape
reader/punch, card reader/punch, and line printer.
It turns out that the two reversed opcodes Maurice identified were not the
only problems in opcode 12 (shifts). All of the INS/EXT pairs at function
codes .57 and above were reversed. In addition, the mnemonics in the
opcode table in alpha_sys.c are wrong as well as reversed.
- Changed to commit PC on certain stops
- Added SET CPU RELEASE command
- Undefined indicators don't throw an error (Dave Wise)
- Added Model I mode to allow record marks in adds (Dave Wise)
- Allowed undocumented indicator 8 (Dave Wise)
- Added option for Model I diagnostic mode (Dave Wise)
# Conflicts:
# I1620/i1620_cpu.c
