2 Oct
2020
2 Oct
'20
12:33 a.m.
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