[sebhc] H8D files and labels

[Dave Dunfield]

> > It would be a very simple matter to write a listing utility 
> > which would display the .H8D files (like a DIR), except that 
> > it would verify the file comment/size, and would display the comment.
> > 
> > Something like:
> > 
> > DISK1    H8D    102400 05-21-04   8:30a OK (No comment)
> > DISK2    H8D    102427 05-21-04   8:30a OK Sample one-line comment
> > DISK3    H8D    102473 05-21-04   8:31a OK
> >   This is a sample multi-line comment that
> >   could be contained in a disk image.
> > 
> 
> That's exactly what I had in mind for the "listing utility" - and I
> agree that the elegance of being able to TYPE out a file for further
> info is pretty sweet. Obviously none of these file level suggestions
> would prevent packaging the image + additional info in a .zip file.

I'm thinking of a single "H8D" utility which would:

- Add a comment to an image - either from a text file or
  by interactive entry.
- Strip the comment from an image (to produce an old-format
  file).
- Replace/Edit the comment in an image.
- Do the verified listng as described above.


I looked into my simulator and discovered/recalled that the sim
actually accepts an image which is any integral number of
tracks (ie: any multiple of 2560).

So the simple size > or == test isn't suitable.

The scheme would still work, as long as your comment field
is not exactly 2560 bytes in size (which is a pretty big comment).
I could have the H8D command automatically pad with an extra
space if the supplied data is exactly this size.

Or we could differentiate the files with the extension:

H8D - Old format H8 Hard-Sectored disk image with no comment
H8H - New format H8 Hard-Sectored disk image with comment
H8S - H8 Soft-Sectored disk image to be defined
H8T - H8 Tape image

Using the extension would have the advantage than when converting
between old (non-comment) and new (comment) formats, we don't
have filename conflicts (I can see comments getting stripped to
accomodate the existing simulators and the new format files simply
getting overwritten if the extensions remain the same).

Regards,
Dave



--
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