[sebhc] H8D files and labels

[Dave Dunfield]

> Instead of creating a new format, why don't we leverage an existing
> format such as .zip files? I know these disk image files are already
> small so compression isn't needed, but zip files also provide CRC
> check (CRC32) per file

Which means the simulator would have to regenerate the CRC over the
entire file when performing a write - either after every series of write
operations (which would be very slow), or at the end of the session
which runs the risk of trashing the image if the disk does not get
"closed" properly.


>there is open/free code from infozip (http://www.info-zip.org/) to handle
>zip files

Which is bigger than my entire simulator source code.


> An additional advantage is that people using
> older software which does not support .zip can use any of the
> unzipper's (including Windows XP built-in support) to extract the .h8d
> file and use ithat file, the additional information can be read/used
> by the user.

Yup - using XP's built in ZIP makes a lot of sense, nobody needs a
special tool (except to view whatever files you've buried in the image).
But wait.... Doesn't XP also have built in support for the TYPE command
I suggested would be usable with the simple comment format ... and
that might even be supported for "people using older software" in a
few systems that came before XP.

Also, encouraging people to use "normal ZIPs" will result in compressed
images - requiring that the simulators implement compression and
decompression in order to use them - Slow and code-bloat.

Under my suggested comment enhancement If for some reason you
want to run an older version of the simulator which does not understand
the comment, all you need to do is to strip everything up to the 0x1A (^Z)
- the remainder of the image would be the same.


>it supports comments,
> but we can also provide special files inside the zip file for
> description, images, etc.

> Alsoe, once the format is defined, programs using it should ignore any
> files it does not know about and be tolerate if any of the expected
> support files are missing (short of the actual disk image of course).
> This will allow us to update the format, if needed, and still be
> backward and forward compatible between the files and any programs
> that would use them.

To me this seems like very much overkill and "complexity for the sake
of complexity" (windows philosophy), since the problem at hand is simply
to be able to record the diskette label along with the file. Do we really need
a bunch of additional "files" to implement this?

Unless I've missed your point and all you are suggesting is that we package
the existing .H8D into a ZIP file with other descriptive information - to be
manually unpacked before it's used. This is basically what we are doing now,
but has the disadvantage it has to be unpacked to be used, which means that
the image and description are no longer physically joined.

Regards,

--
dave06a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Collector of vintage computing equipment:
                http://www.parse.com/~ddunfield/museum/index.html

--
Delivered by the SEBHC Mailing List