9 track tapes and block sizes

[Chuck Guzis]

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.

--Chuck