[sebhc] Disk formats and emulators

[Eric J. Rothfus]

As Jack said "This is getting good!"

> Steven:
> 
>   Do have any other suggestions for this besides XML?   I do have XML 
>   experience, but I really hate using it for binary stuff.

I don't think that the file needs to be XML or even ascii
for that matter.  A binary file would be fine, but maybe it
would have a header that is somewhat identifiable.  You know,
something that uniquely says "H8/H89".

Of all of the formats that I've seen, most have uniquely identifying
characteristics or formats that a simple test would prove out.  Here
are three examples:

   - DMK - (a TRS-80 format) looking at the data (binary) in the file,
     there are well known characteristics that must be in place.  For
     example, a particular integer (encoded in a certain endian) in a
     particular location indicates the size of the file.  That needs
     to be exact.  And the odds of it "just occurring" within a binary
     file is quite low.  This is an example of a hand-crafted but
     simple algorithm.

   - SVD - the SVD internal format (not the ascii Daves' format) is
     binary, but includes a three line header with version #, sides,
     tracks, and sectors.  There is a well-known set of version #'s
     that are unlikely to occur in a random binary file.

   - JV1 - (another TRS-80 format) this one is tough.  It is an
     obsolete format that is simply a binary image of the floppy.
     It is assumed to be SD (WD-1771) format, 10 sectors, 35 tracks.
     It is HARD to determine if you have a JV1 file in front of you.
     The algorithm I use (no laughing please) is:

     - pretend it IS a JV1, and load it up
     - look at the directory track given the assumptions of tracks/sectors
     - ensure that a distribution of the data in the tracks LOOKS like
       a directory

     Yeah, I know, messy.

The important part of this discussion, IMHO, is that there be SOMETHING
that lets us know what type of image, its variable structure (like
tracks, sectors, encoding), and the version of the image file.

>> 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.
>
> Steven:
> 
> Let's call that number eight.  :-)   Good catch!  I wasn't aware of that 
> myself.  Do you know of a specific example of something done that way?

I don't know of any examples in the H8/H89 world.  I know of quite a
few in the Apple and TRS-80 world.  For the TRS-80, the Model II
always (?)  encodes its first track in SD, even if the disk is DD.
The Model I/III/IV game Zaxxon uses mixed density encoding as a copy
protection mechanism.  The Apple is even more tricky, part of their
encoding CAN be what half-track the sector is on.  Nasty, nasty.
This, too, is used in copy-protection.

I'm not sure if we really need to worry about this in the H8/H89
world.  But I haven't seen too much software.  Maybe someone out
there....

> Jack:
>
> being able to write back to the image is getting to be a high
> priority, since it allows "configuration" of the system to meet
> various hardware environments. With more real and virtual machines
> coming online, this kind of flexibility will be very useful.

I think you're quite right.  And this is probably the main reason
why most TRS-80 emulators use a binary format.  I haven't checked
the source, but it wouldn't surprise me if they didn't memory-map
the image, or chunks of it.  There's only ONE image format that
I've seen that is, in its entirety, mappable into memory: DMK.
But that is a WAY complicated format that hides the data within
floppy-controller garbage.

So it looks like we're well on our way to a new format!  But the
important question is:  "What do we call it?"  :-)

Eric

--
Delivered by the SEBHC Mailing List