2 Oct
2020
2 Oct
'20
12:26 p.m.
On 10/2/20 11:51 AM, Paul Koning wrote:
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
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:
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. 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.