9 track tapes and block sizes

Jeff Woolsey jlw at jlw.com
Fri Oct 2 02:33:33 CDT 2020

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.


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

More information about the cctech mailing list