[sebhc] h17 and h8d disk images

[Dwight K. Elvey]

>From: "Dave Dunfield" <dave04a at dunfield.com>
>
>
>> There is one thing I've thought would be good to
>>add to the h8d format. I think we could add one byte
>>to the end that would be the volume number.
>>This could be optional since HDOS disk already include
>>this in the first track data. Adding one more byte
>>would cause allocation of another disk block on
>>most files systems ( like DOS or Windoze ). That
>>is a reasonable waste of space to always use.
>> This information could be determined by any program as
>>simply checking the file size. One byte longer than the
>>100K bytes and it must have a volume number attached.
>>If exactly 100K bytes, the first track information could
>>be used.
>> I believe that most current programs would just ignore
>>this last byte. I'm relatively sure my program would.
>>I currently buffer a track at a time. This should keep
>>it backwards compatible.
>> What do others think?
>
>I don't actually read the file size (I just open it), however
>I could just attempt a seek to the "extra byte" and if it fails,
>assume HDOS and use the volume id from block 9 (IIRC), otherwise
>use the volume ID in the "extra byte" (essentually a feature to
>allow for non-HDOS disks?)

Hi Dave
 That is right. This would be for non-HDOS disk. So far
I only know of the CP/M disk and my Forth disk. My Forth
disks all use volume 0 and I believe that all of the CP/M
are volume 0 as well but I thought it would be good if we
deal with this early on to avoid future issues. Backwards
compatibility is always a good idea. I don't want to break
old code if not needed.
Dwight

>
>Sounds reasonable.
>
>Regards,
>Dave
>-- 
>dave04a (at)    Dave Dunfield
>dunfield (dot)  Firmware development services & tools: www.dunfield.com
>com             Vintage computing equipment collector.
>                http://www.parse.com/~ddunfield/museum/index.html
>
>


--
Delivered by the SEBHC Mailing List