9 track tapes and block sizes

J. David Bryan jdbryan at acm.org
Tue Oct 6 02:34:56 CDT 2020


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



More information about the cctech mailing list