[sebhc] Disk formats and emulators

[Eric J. Rothfus]

OK, I had three reasons, Steven had 7.  He wins!

> I like the header in the SVD format, but I'm still not sure if it's really 
> needed.  It's possible that information can be uniquely implied just by the 
> size of a binary file.

My goal is simply to make sure that the files are somewhat "self-describing."
That is, when you see one, a SIMPLE algorithm can identify them uniquely
as H8'ish things.  The size of the binary file isn't really good enough.
I've run across around a dozen different formats, and those that are
self-identifying are, in the long run, much more useful.  Franz (of Vintage
Computer Festival fame) proposes an XML storage format for floppy images.
Interesting, to be sure, but a bit overkill for my tastes...though I can't
really argue against it.

Regarding the big 7:

>  (1) It was intended to load a hardware device (like hex dumps are used to
>    load prom burners). 

Actually, I think the original idea was to make the images easily dumpable
on an ascii terminal.  The "Daves'" diskdump program dumps images to the
TT:.  The thought, too, was to make them easily mailable.  These two things
aren't bad considerations...though I'm not religious about text formats.

> (2) the text file requires conversion both before and after it's used
>      (assuming the implementation makes the disk writable).

Yup, though this format is WAY easy to convert.  Most other floppy disk
image storage formats require some conversion to retrieve and to store.
Most of the time, the conversion is necessary due to descriptive (or
maybe self-descriptive) information that is being stored with the format.
A notable binary format, DMK, includes checksum information...though it
includes a bunch of other "garbage" in it too.

Another important point about conversion is interesting for architectures
other than the H8/H89: the ability to generate interesting mixed formats.
Some software was recorded in mixed SD/DD formats (most for copy protection),
and this mixing can't be represented without cues encoded in the data file.
These cues would be decoded when being loaded into the real machine or
into an emulator.

> (3) If you don't have a hardware SVD or dont' want to hold the entire
>      image in memory while working with it, the text format would
>      significantly complicate paging.

Yup.  Not really worried about it!  :-)  As with #4, I'm a bit polluted by
the 512 Meg sitting on my desktop, and a decent swapping/paging OS.

> (4) More direct formats would require about the same space as the
>      capacity of the disk being stored.  The SVD format requires
>      3-4 times as much space, and even more with track comments.

Yup.  Another one I'm not really worried about.  I'm polluted by the
small 100G drive I have sitting on my desk.  In the grand scheme of
things, when I save a 10 line Word document in Windoze, and it explodes
to half-a-meg, I tend to get desensitized.  Not necessarily a good thing,
I know.

> (5) While the text format is "readable", I'm not sure it's 
>  particularly useful to do so.  And creating readable dumps of binary files 
>  is trivial on most platforms.

This is closely related to #1.  I, too, don't think it matters much.
Though the "diskdump" program method would NOT work with a binary dump.
If you ask Jack, though, he'll say the diskdump program doesn't work
too well anyway!  :-)  (he got a lot of NULL characters when dumping)

> (6) It's not analagous to the more direct format already being used
>  to store and emulate tape files (.PID, .tape). 

Actually, the .PID and .tape aren't analogous to the Daves' format!

> (7) There's no facility in the format to verify data integrity (as
>  there is in a real disk).

THIS is a good one!  And one that could sway me in a big way.
I imagine any simple checksum scheme would work...including the
one stored in the floppy sectors themselves (XOR, SHIFT).

SOOOOoooo, I still think that creating/propagating new formats for
floppy images is of limited value even with the reasons above (with
the notable exception of #7)...though it often happens when 
engineers get together to re-invent something!  :-)  In any case,
I'm always open for change.  We should realize, however, that 
Dave S's emulator will be broken relative to a new format.  I'm
not worried about the SVD, I can whip up new formats for that
quickly.

My $.02, (maybe more),
Eric


--
Delivered by the SEBHC Mailing List