[sebhc] H8D files and labels

[Eric J. Rothfus]

>
> ...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
priority order):

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,
	for example.

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: 

    http://www.vintage.org/content.php?id=005


Eric
--
Delivered by the SEBHC Mailing List