On Monday, October 5, 2020 at 8:25, Chuck Guzis via cctech wrote:
> So increasing the mask for block length wouldn't seem to be a problem,
> assuming that SIMH could support it.
SIMH could be written to support it (I'm the maintainer-by-default of the
tape handling portion of SIMH). I don't know of any existing simulators
that depend on the length being exactly 24 bits. The tape handling library
defines an integer type to hold tape record lengths (it's a 32-bit unsigned
value), and simulators are supposed to declare tape record length variables
of this type. So extending the record length field to 28 bits shouldn't
cause problems.
The current library assumes that anything that's not one of the three
defined metadata markers (EOF, EOM, or erase gap) is a tape record length,
so there's no error recovery for undefined markers. This could be changed,
however, so that unrecognized markers would be ignored, i.e., transparently
skipped when reading or writing, as long as those markers contained the
length of the record to be skipped.
For example, if the upper four bits were dedicated to the marker type field
and the length field expanded to 28 bits, then we could have something
like:
Type Length Meaning
---- ------- ------------------------------------------------
0 0 tape mark
0 >0 "good" data record
1 >0 \
... | undefined records (reserved for SIMH)
7 >0 /
8 >0 "bad" data record
9 >0 \
... | user-defined records
D >0 /
E any user-defined single-word marker
F FFFFFFF end of medium
F FFFFFFE erase gap
F other undefined single word marker (reserved for SIMH)
The type E single-word marker and record types 9-D (that must contain
record lengths at both ends of the record) would be transparently ignored
by SIMH. These could be used for tape information or other uses devised by
the community.
-- Dave
