2 Oct
2020
2 Oct
'20
1:42 p.m.
On Fri, Oct 2, 2020 at 1:27 PM Chuck Guzis via cctalk <cctalk at classiccmp.org>
wrote:
Actually, they're neither. I append the metadata
after the EOI marker
on mine. Doesn't seem to bother the emulators.
Some programs (but probably very few) that use various so-called .tap files
assume that they can seek to the EOF (of the container file) and read
records backwards (supported by lengths being at both ends of blocks in the
container). Tacking metadata on the end breaks that. I'm not criticizing,
mind you. It's just something that people may need to be aware of.
The .tap file formats are horrible. Originally there was at least the
virtue of simplicity, but because they've diverged we don't even have that.
Al wrote:
Bordynuik's at least had some provisions for
reporting a bad block,
as I'm sure yours does.
Aeons ago when I was doing stuff with tape images, I made a proposal for
representing bad blocks of either known or unknown length. I don't know
whether anything other than some of my own unpublished code adopted that
particular proposal. IIRC, I proposed using a record length of 0xffffffff
to designate any kind of "metadata" record, with the real length of the
metadata record in the next word in on both ends (to still support
backwards reading), and the third word at the beginning only being a tag of
what kind of metadata it was, etc.
Of course, that scheme breaks programs that use tape images but don't
expect enormous or "negative" record lengths.
I contributed to the morass by still calling my files .tap files.