5 Oct
2020
5 Oct
'20
2:06 p.m.
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:
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
On Sunday, October 4, 2020 at 16:00, Chuck Guzis
via cctalk wrote:
BOT
A 16MB tape block is impossibly large in any
case.
The HP 3000 mag tape diagnostic attempts to write a single record from 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.