[sebhc] Disk formats and emulators

[Lee Hart]

Eric J. Rothfus wrote:
> 
> 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?"  :-)

It is really all that hard? The "standard" disk format for the H8 and
H89 is the hard-sector (H17) format; 10 256-bytes sectors per track, 40
tracks, single-density, single-sided. Everything is (or can be put) into
that format. To recreate a physical disk from a file, you should be able
to just load those 256 x 10 x 40 = 102,400 bytes onto a disk and it will
work.

The "standard" soft-sector format (which only came about after Heath
produced the soft-sector controllers) is essentially the same. All
that's different is the order of the sectors within each track, and that
the code in the boot tracks (if any) was to boot with a soft-sector disk
instead of a hard-sector disk.

All Heath and HUG software was distributed in these formats, as far as I
can recall. They never used double-sided or double-density or 80-track
formats for distribution disks.

So, perhaps all one needs is a clear ASCII message at the beginning of a
file that clearly identifies it as a Heath disk image, followed by the
102,400 byte binary image.
-- 
"Never doubt that a small group of committed people can change the
world. Indeed, it's the only thing that ever has!" -- Margaret Meade
--
Lee A. Hart  814 8th Ave N  Sartell MN 56377  leeahart_at_earthlink.net

--
Delivered by the SEBHC Mailing List