The commands which operate through run_cmd (GO, STEP, CONTINUE, BOOT, RUN) will all exit with a status which is NOT SCPE_OK. Most of the exit status values will be 100% normal and not indicative of a true error, so producing error message context is not necessary or desired.
The current implementation of "run_cmd" in scp.c calls "fprint_stopped_gen" (via "fprint_stopped") to print the message associated with the "sim_instr" return status. Messages associated with VM stops must be provided to the SCP via the "sim_stop_messages" array.
"fprint_stopped_gen" prints the status message in a rigid format: the message string, a comma, the program counter register name, a colon, the current PC value, and the instruction at that address in symbolic format.
For example:
HALT instruction, P: 24713 (LDA 1)
Only the message string is under the control of the VM. If additional information is needed, it can only be added before the first comma.
The HP2100 simulator does this for halt instructions, which contain device select code and flag hold/clear bit fields that, in practice, are used to communicate to the operator the significance of the particular halt encountered, rather than to affect the device interface:
HALT instruction 102077, P: 24713 (LDA 1)
To implement this, the simulator must define the message as a variable and then copy the formatted octal value into the buffer at the appropriate location before returning from "sim_instr".
However, if the VM wants to display a different register value, e.g.:
Self test #13 complete, STAT: 000020
...this cannot be done without also displaying the program counter, which may be irrelevant for the given stop condition.
001. PROBLEM: Cannot show radix, etc. for a device that has no modifiers.
OBSERVATION: The default data radix for a device may be set with the SET
<dev> OCT|DEC|HEX command. However, if the device does not have a modifier
table, SHOW <dev> RADIX is rejected with "No settable parameters".
The same problem occurs for SHOW <dev> DEBUG and SHOW <dev> NAMES. For a
device that provides debug printouts, SHOW <dev> MOD will list "DEBUG,
NODEBUG" among the modifiers, and the SHOW <dev> DEBUG command will display
the current debug status. However, if the device does not contain a
modifier table, SHOW <dev> MOD and SHOW <dev> DEBUG will report "No
settable parameters", even though SET <dev> DEBUG is accepted and works as
expected. For such a device, SHOW MOD will show "DEBUG, NODEBUG" as
acceptable modifiers.
002. PROBLEM: SET and SHOW responses for invalid entry are inconsistent.
OBSERVATION: Entering SET <dev> <mod> where <mod> is not defined in the
device's modifier table displays "Non-existent parameter." Entering SHOW
with the same parameters displays "Invalid argument."
Similarly, entering SET <dev> DEBUG for a device that does not have
debugging capability displays "Command not allowed." Entering SHOW with
the same parameters displays nothing.
In both cases, the messages displayed should be the same for the same
error.
OBSERVATION: For a simulator stop, sim_vm_fprint_addr (if defined) is
called to print the value of the program counter, regardless of whether or
not the register was defined with REG_VMAD. However, displaying the PC
value with "examine" calls sim_vm_fprint_addr only if the REG_VMAD flag is
present. The displayed value of the PC should be the same in both cases.
For a command like: SEND MUX:0 "abc"
in which a device is specified but there are no after=nn and delay=nn parameters, the code neglected to update cptr, resulting in an illegal argument error condition.
Compare operations will do a literal compare of basic string values unless the all of each string contains numeric data. If numeric data is there then a numeric comparison will be made. For example:
If "+1" == "1" echo equal
will display equal, while the simple string comparison will be not-equal.
- EXPECT will now tolerate a HALTAFTER=n parameter which delay the simulator stopping execution for n instructions. Unpredictable behavior will happen if multiple EXPECT conditions see matching data before the first actualy halt occurs.
- SEND has an AFTER=n argument which delays the initial stuffed data from being input for at least n instructions. It also has a DELAY=m argument which specifies the minimum number of instructions which must execute between stuffed input data.
- Changed run_cmd() to no longer clear pending breakpoint actions before starting instruction execution.
- Added a -Q switch to the commands which dispatch through run_cmd() (RUN, STEP, NEXT, GO, BOOT, etc.). This switch will suppress status output when execution stops. This will allow sequences of breakpoint action commands to silently execute when needed.
Ideas based on Dave Bryan's console halt efforts.
sim> SEND {<mux>:line} {DELAY=n,}"string"
Where <mux> is the name of the device pointed to by the TMXR structure. If <mux>:line isn't specified, then the console device is implicitly being referenced.
Delay is optional and once set persists for subsequent SEND operations to the same device. Delay defaults to 1000. The DELAY value is a minimum number of instructions which must execute before the next character in the provided string will be injected to the console port. The DELAY value has effect between the characters delivered as well. "string" requires quotes and within the quoted string, common C escape character syntax is available (\r\r\t, etc.).
Each device (console, and each line in each mux) has a separate value for DELAY.
An arbitrary number of 'expect' conditions can be defined. The command syntax is:
sim> EXPECT {<mux>:line} {[cnt]} "matchstring" {actioncommand {; actioncommand ...}}
Where <mux> is the name of the device pointed to by the TMXR structure. If <mux>:line isn't specified, then the console device is implicitly being referenced.
"matchstring" requires quotes and within the quoted string, common C escape character syntax is available (\r\r\t, etc.). The quotes used can be single or double quotes, but the closing quote must match the opening quote. The match string might be extended to allow the use of perl style regular expressions in the "matchstring" when a -R switch is specified on the command line.
sim> EXPECT "Enter Color: " SEND "Red\r"; g
A specific 'expect' condition can be removed with:
sim> NOEXPECT {<mux>:line} "matchstring"
All 'expect' conditions can be removed with:
sim> NOEXPECT {<mux>:line}
'expect' conditions can be examined with:
sim> SHOW EXPECT {<mux>:line}
Expect rules are one-shots (i.e. they disappear once a match has occurred) unless they are explicitly described as persistent with the -P switch.
The -C switch is available when defining expect rules. The effect of a rule defined with the -C flag is that when an expect match occurs for that rule, ALL rules are cleared for that device (console or <mux>:line).
