[sebhc] fstools and other things

[Eric J. Rothfus]

Man, Steven, you're quick.  Thanks for the code snippets,
though philosophically (and I hate it when OTHER people
say that :-) getting the HDOS volume number out of the
file-system within the reading of physical image is a
no-no...particularly when dealing with CP/M images.
We still need to put it in the image format somewhere.

> It would be cool if "JV1" could be used as the format here, and then
> you could skip the conversion step.

JV1 was the first format supported in the TRS-80 world and the first
one supported in the SVD ('cause it was easy :-).  It was quickly
deprecated in favor of JV3 and DMK because it had too little
information in it.  It couldn't distinguish double density, it
couldn't deal with other WD179x markings, it couldn't deal with
interleave changes (particularly problematic in CP/M), it couldn't
deal with copy protection, it couldn't distinguish CoCo files, etc.
In essence, it's a pretty bad "format" and is the fall-back for the
SVD.

One thing I would like to do, however, is to create a "generic" image
mechanism that would allow configurable loading of generic images.
For example:

   $ fstool -g 40,10,H17 ...etc...

Where the "-g" indicates a binary image with 40 tracks, 10 sectors,
and H17-style data encoding.  There are many ways to do this...I just
haven't run into the need with the other formats.  Normally, a
distinguishable format will give you enough data to set these
parameters automagically...and that's still what we should do.

> Just don't do it again!  :-)

I've learned my lesson!

> Yea, but that's a matter of concern for emulators, but not for the
> file format.  It doesn't matter if track 40 is the first track on
> side 2, or in the middle of side 1; in either case, it will follow
> "track 39" in the image file.

Again, it's simply a "definition" issue.  A format should be well
defined.  Personally I think it should also "closely resemble" the
physical media.  In the TRS-80 world there's a rather nifty PC-card
called the Cat-weasel (nice name I know) that will dump a floppy image
verbatim into a file.  This image preserves enough data to be able to
allow even copy-protected floppy images to operate.  It makes no
attempt to "organize" the data beyond the floppy organization.  That
is, the file "looks" like a floppy.  The TRS-80 emulators simply know
the format of this file ("DMK" by-the-way) and use it as if it were a
real floppy.  I'm not saying, though, that the H8 emulators should
change to support DMK-like flexibility...I don't think it is
necessary.  Just so the format is well known.

> That's why the only significant difference between 1s80t.h8d and 2s40t.h8d 
> is the LAB.VFL byte.

Yup, the file simply contains a track by track image of the floppy.
Which just so happens to go from side to side for HDOS.
And if the emulator knows that, then we're quite cool.  Floppy image
dumpers need to know it too.

> Members of this list may also enjoy the following patch:
> ...
> +    char		*fs_type = fs_types[4];	/* Make hdos default! -sp */

OK, no religious changes allowed!  :-)

(Man, you are quick!)  Normally, I change this by re-ordering the
files in the Makefile, however.

Keep the changes coming!  :-)

Eric





--
Delivered by the SEBHC Mailing List