5 Oct
2020
5 Oct
'20
8:25 a.m.
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:
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
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).