9 track tapes and block sizes

On Monday, October 5, 2020 at 8:25, Chuck Guzis via cctech wrote: 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