[sebhc] H8D files and labels
Eric J. Rothfus
eric at rothfus.com
Tue Mar 28 17:08:57 CST 2006
> ...discussion of file formats including H8D...
Sorry to weigh in late...I'm too busy playing with my new Altair :-).
I'm moderately against creating a new image storage format. It seems
that each vintage group eventually starts to re-invent image formats.
And each crosses over the other inventing formats that are "exactly
the same but different."
In my work with the SVD, I find myself in the position to deal with
many different formats and creating software that works with each. As
such, I've developed rather rabid opinions about floppy image formats,
with the basic guiding principal that the formats need to be useful
for generations to come. I mean, if we're going to the trouble of
"saving" the software/info that resides on our dying floppy disks, we
should save it in a format that anticipates future needs.
My credo for archival of floppy formats is pretty simple (and in
Completeness - a floppy storage format for a particular target
system/OS should completely describe all of the data required
for that target. For example, a good floppy format for H8/9
should include the volume number of the disk. As another
example, often in the TRS-80 world copy-protected disks
included weird sector/track numbers; a good floppy format
should include that information.
As a counter example, the H8D format is simply a dump of the
sectors of a floppy. It is assumed that they are dumped in
order, and that the sector/track/volume numbers for the image
are easily discernable. Although this works mostly, it forces
us to look into the data on the image to discover important
information like the volume number. The H8D format is bad for
CP/M images because the volume number can't be easily found.
If you take a look at the "other" H8/9 format with the
extension of .h17 (hereby called the H17 format) you'll see a
more "complete" format. It describes the volume number as
well as sector and track numbers. It includes, as well, a
"Description" field which is equivalent to the comment field
people have been asking for.
Granted, you can go overboard. There is really no reason to
capture the individual flux transitions of a floppy image,
Self-Descriptive - an issue that I have smashed into over and over in
in working with the SVD, is that many file formats cannot be
identified uniquely regarding the system they target. That
is, I can't necessarily tell the difference between an H8D and
the TRS-80 format JV1. Fortunately, the files themselves are
often named to identify them, like the file "HDOS.h17".
Though you can't count on that. Many groups like to name
their floppy images "blah.dsk" - which makes it often
impossible to figure out the target system for a floppy image.
This issue is closely linked to the "completeness" issue
above. In almost all cases, you can't be fully "complete" and
you need some target information in order to "fill in the
gaps" when using an image. For example, even with the H17
format the file doesn't describe that the original media was
hard-sectored. So if you wanted to faithfully reproduce the
"HDOS.h17" disk, you have to KNOW that it was on hard-sectored
media using the H8/9 sector format.
Size - many people get rather religious about the size of image file,
and that difference can be rather big. For example, an image
in H8D may be 100k bytes while the same H17 image may be over
400k. Although this is indeed an issue, it is an issue that
continues to get less important as storage becomes cheaper and
cheaper and speeds faster and faster. I will always prefer an
image format that is more complete or descriptive than one
that is smaller.
The above list was in priority order for me. So I could really care
less about size...or maybe more accurately, it can be dealt with in
other ways than to trade off completeness for size (for example).
So to bring this back to the topic at hand. Personally, I'd be for
reverting the SEBHC collection back to H17 format as opposed to
expanding the H8D format. Or maybe a common format could be used.
For size concerns, while they still exist at this level, "zipping"
of the files would be easy.
We're not the only ones concerned with floppy image formats. Sellam
has written his essay on the matter too:
Delivered by the SEBHC Mailing List
More information about the Sebhc