9 track tapes and block sizes

Chuck Guzis cclist at sydex.com
Fri Oct 2 14:26:54 CDT 2020


On 10/2/20 11:51 AM, Paul Koning wrote:
> 
> 
>> On Oct 2, 2020, at 1:46 PM, Chuck Guzis via cctalk <cctalk at classiccmp.org> wrote:
>>
>> On 10/1/20 11:40 PM, Warner Losh via cctalk wrote:
>>> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk <cctalk at classiccmp.org>
>>> wrote:
>>>
>>>> I have never figured out why Bob Supnik defined the magnetic tape
>>>> containers (TAP files) with the one byte padding for odd length records.
>>>> This seems very odd (pun intended).   :-)
>>>> Even on a machine which couldn't write 32 bit numbers (the record lenght)
>>>> on odd boundaries you could write the 32 bit number as 4 individual bytes.
>>>> Does anyone know the reason?
>>
>> On the .TAP files that I provide to customers, I ignore the 16-bit
>> granularity and supply odd-length records as appropriate. 
> 
> You can certainly create tape container files like that, but those are not TAP format.  Instead, they are E11 format.  You should call them by their proper name.

Actually, they're neither.  I append the metadata after the EOI marker
on mine.   Doesn't seem to bother the emulators.

This is basically the problem with all of the container file formats
that I've seen.  They seem to think that the data alone is sufficient to
describe an object.   Quite often, a simple paper label is more
informative than a bunch of bits--indeed, it may represent the Rosetta
Stone when it comes down to figuring out what's what.

Even the diagnostic options are very weak.   For example, on many
platforms, it's possible to identify which (vertical) frames contain
parity or other errors.  There's no option for reporting this level of
detail in any of the container files that I've seen.  I append a log of
the reading process as part of the metadata.   Similarly, I've handled
tapes where the density changes between files.  Where to report this?

Most container files don't even make a provision for reporting parity
(NRZI tapes).  On 7 track, the encoding schemes between even and odd
parity can be quite different.

--Chuck



More information about the cctalk mailing list