On Mon, Oct 5, 2020 at 9:25 AM Chuck Guzis via cctech <cct...@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
