9 track tapes and block sizes

[Warner Losh]

On Mon, Oct 5, 2020 at 9:25 AM Chuck Guzis via cctech <cctech at classiccmp.org>
wrote:

> On 10/4/20 10:51 PM, J. David Bryan via cctech wrote:
> > On Sunday, October 4, 2020 at 16:00, Chuck Guzis via cctalk wrote:
> >
> >> A 16MB tape block is impossibly large in any case.
> >
> > The HP 3000 mag tape diagnostic attempts to write a single record from
> BOT
> > to EOT, which unfortunately fails under simulation due to the 16 MB
> > limitation.  In hindsight, it would have been better to accommodate
> record
> > lengths corresponding to the highest density and longest reel length,
> which
> > I think would need 28 bits.  Four bits for metadata identifier would
> still
> > have been be good enough, and one of those should have been dedicated to
> > "private data" that would appear invisible to programs running under
> > simulation (and could be used to include information about the tape
> image
> > with the tape image).
>
> That's interesting.   Looking at my own code for .TAP files, I see the
> following:
>
> #define TAP_FILEMARK    0x0             // 0 = filemark
> #define TAP_EOM         0xffffffff      // -1 = end of medium
> #define TAP_ERASE_GAP   0xfffffffe      // -2 = erase gap
> #define TAP_ERROR_FLAG  0x80000000      // error flag bit
> #define TAP_LENGTH_MASK 0x00ffffff      // mask for length
>
> So increasing the mask for block length wouldn't seem to be a problem,
> assuming that SIMH could support it.  There may be other high-order bit
> meanings assigned, but I've not run into them.
>

The other way to handle it, should we not be able to steal bits which
should be plan A, is to have a metadata type that says 'append this to the
prior record' which would remove the limit entirely.

Warner