2 May
2002
2 May
'02
8:10 a.m.
> The emulator community is vigorously using a tape
image container
> format known as TAP for precisely this purpose.
...
Darn...sounds like a subset of what I use. I'd be
interested
in knowing more about TAP (with an eye towards adopting use of it),
and would suggest some possibly missing features might be:
- ability to flag if the current tape record had a recovered read
error (obviously, not all hardware/OS's support getting that information)
No. And I see no useful purpose in including that in the format.
If the read was recovered, you have the data; surely you would
*not* want to recreate a tape and make a previously marginal
block, marginal again on a clone?
- ability to flag if a particular tape record had a
hard error
while reading it
No (I can say this even though I'm about to ask): do you mean an
unrecoverable error, or one that was corrected by the hardware
(as opposed to being corrected by software)? Either way, if the
error was corrected, see my response above.
- ability to flag if an End-of-tape marker/indicator
was seen
while reading the the current record (again, not all
hardware/OS's support getting that information)
No, and again, I can't see how this data would be used to recreate
the tape or would be needed by an emulator. It's kind of like asking
if a particular hardware emulator also emulates memory parity errors
so that you can see memory parity errors in the logs. Why??
- overall header at start of file, recording
information about the tape
No, although I did consider suggesting some extensions like this.
One problem I have encountered with some old CDC tape formats
dealt with how blocking got handled. But my current feeling on
this is that if its blocked on taped, then the records will come
off the taoe with their proper lengths (I encountered this not
trying to read a tape, but trying to create an image of a tape
that no longer exists by a desctiption of its contents).
Anyway, I encode that kins of descriptive information (what kind
of computer, encoding, #tracks, etc) in the filename, or in the
name of the directory containing the file, or in a README.
I have a program called "tapedisk", which
reads an arbitrary tape
and "copies" it to a single disk file (or set of files, if the size of the
output file exceeds the maximum disk file size). The purpose of
tapedisk is to allow a future exact copy of the tape to be recreated
on another tape (of equal or larger size). (That future copy would be
made with the companion program, disktape.) Additionally, most of
my other tape-reading utilities know how to read a tapedisk format
disk file as though it were a tape.
This sounds familiar... is it on the web somewhere?
This is what I store on a per-tape-record basis:
...
So you really do want to recreate bad tapes as bad tapes...
Why?
This is some what I store as a "header" at
the start of the
overall output:
...
Yeah, this info is README fodder... why on earth program that?
As you can see...a lot of info, but all necessary to
faithfully
reproduce the tape later and/or to understand *why* the file might
(or can't) be used to completely reproduce the tape.
Uh, again, can't understand why you'd need to recreate bad tapes.
As to the understanding, README.DOC... etc...
This is part of a product we sell on MPE/iX systems,
but I'd be happy
to document the structures and/or work with other people on standards
in this area.
There's room for potential improvement. For example, is it worthwhile
to have a table at the front of the output file that specifies where
the first N EOFs are?
You just used that nasty, bad word "standard"... TAP is a convention,
not a standard.
;)
However, I'm not King of this Kingdom, we're a collective
(right out of Monty Python's Search for the Holy Grail).
You might try hooking up with the emulator community and
ask your questions there.
Regards,
-doug q