9 track tapes and block sizes

[Jeff Woolsey]

On 10/1/20 11:40 PM, Warner Losh wrote:
>
>
> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
> <cctalk at classiccmp.org <mailto: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).   :-)
>
My theory is that this was a time when the controller interface (either
to the tape unit or to the host or both) was 16 bits wide.
>
>     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?
>
>
> RMS did this too.... if nothing else, it was in the water at Digital.
> But it would have been faster to access than unaligned buffers...

Recently, Al forwarded me a tape image from Chuck Guzis.  It was claimed
to be a NOS 1.4 tape, and that's what it turned out to be.  However, it
was one of those tapes that requires new code in my tools to read
smoothly.  While I routinely see tapes with a single padding byte, this
one had many cases requiring two padding bytes, and some requiring
three!  Thus this tape image is not SIMH-compliant. Also, most NOS files
had their own ANSI labels; the files were mostly just text programs
without their own names, so the ANSI labels helped, but this is unusual
for NOS.

Summary:

73 HDR1 labels encountered. +++
73 EOF1/EOV1 labels encountered. +++
29 single-padded blocks +++.
406 double-padded blocks +++.
24 triple-padded blocks +++.

-- 
Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
Nature abhors straight antennas, clean lenses, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
Card-sorting, Joel.  -Crow on solitaire