On 10/1/20 11:40 PM, Warner Losh wrote:
>
>
> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
> <cctalk@classiccmp.org <mailto:cctalk@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
