256. ENHANCEMENT: Add tape runaway support to the simulator tape library.
OBSERVATION: The ANSI specifications for NRZI, PE, and GCR tape recording
mandate a maximum length of 25 feet for erase gaps. Currently, an erase
gap of any length is ignored when reading or spacing. To allow detection
of non-compliant tape images, the simulator tape library is enhanced to
halt positioning and return tape runaway status if a gap of 25 feet or more
is encountered.
Runaway detection is enabled by calling the tape library to set the tape
density in bits per inch. If this call is not made, erase gaps present in
a tape image are effectively ignored. Also, with the addition of a
separate "set density" call, it is no longer necessary to supply the
density when writing erase gaps.
RESOLUTION: Modify "sim_tape_rdlntf" and "sim_tape_rdlntr" (sim_tape.c) to
detect tape runaway, and add a new MTSE_RUNAWAY status to sim_tape.h. Add
new "sim_tape_set_dens" and "sim_tape_show_dens" functions to set and show
the bits per inch for a unit, respectively, and eliminate the "bpi"
parameter to "sim_tape_wrgap" in preference to using the density
established by a previous "sim_tape_set_dens" call. Add named constants
to "sim_tape.h" that specify the density.
257. ENHANCEMENT: Improve performance when reading or spacing over erase gaps.
OBSERVATION: Performance when reading or spacing over erase gaps is poor,
especially in the reverse direction. Currently, each 4-byte gap marker is
read individually, and in the reverse direction, each read is preceded by a
seek to move the file pointer backward. This combination causes stream
cache invalidation and a physical disc access for each gap marker. As a
single gap consists of over 1000 markers, performance is far worse than if
a gap was read as a block.
RESOLUTION: Modify "sim_tape_rdlntf" and "sim_tape_rdlntr" (sim_tape.c) to
buffer reads of gap markers. Using a 128-element buffer, performance
improves about thirty-fold.
258. PROBLEM: Writing an end-of-medium positions the tape image after the mark.
OBSERVATION: The "sim_tape_wreom" simulator tape library function writes
an end-of-medium marker on the tape image. The intent is to erase the
remainder of the tape. The "SIMH Magtape Representation and Handling"
document states that the tape position is not updated by this function.
However, the function leaves the tape positioned after the marker.
A subsequent read would stop at the EOM marker. However, writing a new
marker over that one would then allow reading of the data following the EOM
that supposedly had been erased by the original "sim_tape_wreom" call.
CAUSE: The tape position is updated by the internal "sim_tape_wrdata" call
that is used to write the EOM marker, but it is not reset afterward by the
function.
RESOLUTION: Modify "sim_tape_wreom" (sim_tape.c) to reset the tape
position to point at the EOM marker before returning. This prevents
reading past an EOM marker, and a subsequent write will overwrite the
marker rather than embed it between data records.
259. PROBLEM: Reading through an erase gap in reverse may return EOM status.
OBSERVATION: A reverse read or spacing operation through an erase gap may
return end-of-medium status. Reading or spacing forward through the same
gap works properly.
CAUSE: Writing an erase gap over existing records may produce a gap that
is longer than requested. This occurs when truncating the last record to
be overlaid by the gap would leave a record that is shorter than the
minimum size allowed (eight bytes for the length words plus two bytes for
the data). In this case, the gap is lengthened to overlay the entire
record. If the new gap size is not evenly divisible by four, a half-gap is
metadata marker of value 0xFFFF added to the beginning of the gap.
If a gap that begins with a half-gap marker is written immediately after
a previous gap, the "seam" between gaps will contain the bytes FE FF FF FF
( FF FF ) FE FF FF FF.... Reading forward across this seam will yield a
metadata value of 0xFFFEFFFF, which is recognized and handled by seeking
two bytes back to resynchronize reading. However, reading in reverse will
yield the value 0xFFFFFFFF, which is interpreted as end-of-medium.
RESOLUTION: Modify "sim_tape_rdlntr" (sim_tape.c) to recognize 0xFFFFFFFF
as a half-gap marker and resynchronize in response. End of medium cannot
occur when reading in reverse, as it is impossible to position the tape
image beyond an EOM marker. Therefore, any 0xFFFFFFFF value encountered
must be a half-gap "seam" originating as above.
260. PROBLEM: sim_tape_wrgap fails when format is changed from SIMH format.
OBSERVATION: The HP 2100 magnetic tape simulator supports erase gaps and
calls sim_tape_wrgap when commanded to write a gap. However, if a tape
format other than SIMH format is selected, the call fails with MTSE_FMT.
CAUSE: Erase gaps are not supported in formats other than SIMH, but the
call should not fail. Instead, the call should be a "no-operation" if the
underlying format does not support gaps.
RESOLUTION: Modify "sim_tape_wrgap" (sim_tape.c) to return MTSE_OK with no
action performed if a tape format other than SIMH is selected.
261. PROBLEM: The magnetic tape format of an attached unit may be changed.
OBSERVATION: The magnetic tape library supports several tape image
formats. The format to use may be specified either by an "ATTACH -F"
command or by a "SET <unit> FORMAT" command. The latter calls the
"sim_tape_set_fmt" function, which allows the format of a file currently
attached to be changed. However, the format is an intrinsic property of
the tape image file, so changing it once the file has been attached makes
no sense.
CAUSE: Oversight.
RESOLUTION: Modify "sim_tape_set_fmt" (sim_tape.c) to return an error
(SCPE_ALATT, "Unit already attached") if the unit is attached.
- 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).
Finishing the last DECtape device which was missed when this functionality was added to pdp11_dt, pdp18b_dt and pdp8_dt
in commits: 2934112a70 and c9e8121c16
Cleaned up the pdp11, pdp18b and other pdp8 implementations to make backporting cleaner.
Made sure that buffer flushing happens correctly when simulation returns to the sim> prompt.
ISO 8601 support without requiring C99 strftime functionality.
%DATE% yyyy-mm-dd
%TIME% hh:mm:ss
%DATETIME% yyyy-mm-ddThh:mm:ss
%LDATE% mm/dd/yy (Locale Formatted)
%LTIME% hh:mm:ss am/pm (Locale Formatted)
%CTIME% Www Mmm dd hh:mm:ss yyyy (Locale Formatted)
%DATE_YYYY% yyyy (0000-9999)
%DATE_YY% yy (00-99)
%DATE_MM% mm (01-12)
%DATE_DD% dd (01-31)
%DATE_WW% ww (01-53) ISO 8601 week number
%DATE_WYYYY% yyyy (0000-9999) ISO 8601 week year number
%DATE_D% d (1-7) ISO 8601 day of week
%DATE_JJJ% jjj (001-366) day of year
%TIME_HH% hh (00-23)
%TIME_MM% mm (00-59)
%TIME_SS% ss (00-59)
- Avoid assignments of void * values. Cast all memory allocation return values to appropriate types.
- Add output to sim_log where missing in various places.
- Fixed issue with lost file positions after a restore for devices which leverage the UNIT_SEQ flag.
In 32-bit mode, the compiler truncates constants to 32-bit.
We need LL suffix to avoid the truncation.
This behavior is contrary to the C 99 standard which defines
that constants that do not fit into long and unsigned long shall
have long long type.
