17
2.4 The Simulation Console and the System Console
When the simulator is started, the SCP command prompt appears at the
simulation console.
For windowed host
operating systems, this is typically the same window from which the simulator was started. Once an execution
command is entered at the simulation console, the standalone diagnostics and the operating systems begin their
user interactions at the
system console
. The TTY device is typically used as the system console.
For convenience and by default, the system console is connected to the simulation console, so that SCP and
operating system commands may be entered from the same window. Additional “user” terminals may be
connected via Telnet or serial ports to the BACI, MPX, or MUX devices as described later.
The system console may be separated from the simulation console by using the
SET CONSOLE TELNET=<port>
or
SET CONSOLE SERIAL=<port>
command. This leaves the simulation console at the initiating window and
moves the system console to a Telnet or serial port, allowing the use of an HP terminal or terminal emulator.
Entering the
SET CONSOLE NOTELNET
or
SET CONSOLE NOSERIAL
command will rejoin the consoles
2.5 Tracing Simulator Operations
The simulator provides options for extensive tracing of the internal operations of selected devices. This is useful as
an aid to hardware and software debugging as well as to gain an understanding of the internal operations of the
simulated devices. Devices offer multiple trace reporting levels, from command overviews to detailed backplane
signal assertions. Tracing for each device and its separate reporting levels may be enabled independently.
To obtain a trace, two SCP commands must be given. First, a
debug log
must be established with the
SET
DEBUG <target>
command. This command is described in detail in the “Controlling Debugging” section of the
SIMH Users' Guide
manual. Typically, the target is a text file, so that the trace may be reviewed after capture.
Second, tracing must be enabled for the desired devices with
SET <device> DEBUG=<option>
commands.
These are documented below in the sections that refer to the simulated devices. The formats of the trace output
are specific to the devices being traced. Examples are provided in each device description section below.
The reporting level options table given for each device is arranged in order of increasing detail. The first option
listed provides the broadest overview with the least specific detail and generates the smallest number of trace lines,
thereby slowing program execution the least. Subsequent options provide increasing detail at the expense of larger
debug log files. Enabling all trace options with a
SET <device> DEBUG
command provides the fullest picture of
device operation but may generate very large log files.
Some options enable tracing of periodic events, e.g., a clock tick or a device poll. Use caution when specifying
these options, as the trace log may fill rapidly. Options that trace periodic behavior are noted in the option
descriptions.
Tracing does impose some overhead on the simulator, with more detailed tracing slowing the simulator more than
higher-level tracing. No overhead is incurred when tracing is suspended with the
SET NODEBUG
command, even
if individual device tracing options remain in effect.
