[sebhc] h17 and h8d disk images

[Dave Dunfield]

At 10:11 01/09/2004 -0700, you wrote:
>Hi Dave & Dan
> Although I generate the h8d format ( mostly being lazy ) I think
>your h17 format is more robust and contains more information
>than the smaller format. What both formats seem to lack is
>information about interleaving. Dan Lanciani mentioned that
>it didn't make any difference for pure images. In a sense, this
>is correct but this make the two methods of handling these
>images incompatible for images with interleaving. The problem
>is that if you take an image and just create a sequential
>binary of the data like the h8d directly from the disk image,
>you'll lose the sector headers that contain the interleaving
>information.
>...

Dwight,

The H8D format is very simple/just data for a few reasons:

1) I had not-to-long ago just done the Altair simulator which has the
   NorthStar hard sectored single-density disk system in it - this system
   DOES NOT use headers, and sector numbering HAS TO BE the physical
   ordering on the disk - so I just "did the same thing" for the H8,
   having not had experience with hard-sector disk and sector headers
   before (It really just seemed like a nusiance).

2) The H8 simulator caches the disk a track at a time, so interleave
   factor makes absolutely no difference, except for the fact that I
   artifically wait for sector pulses - however due to the way it is
   designed, the virtual disk system should be able to read/write in
   sequential fashion at full speed, so interleaved disks would
   actually be slower - H8D files are by definition non-interleaved.

3) I was really only concerned about being able to access the data
   and the controller register level, not it doing a bit-by-bit detailed
   simulation right down to the sector layout level.

4) My layout simplifies the simulation, because a given sector can be
   located by simple seek within a track - otherwise I would have to
   scan each track as I cache it and build a sector map table (do you
   recall how quickly my emulator came into being ... I didn't want to
   do any work that was not necessary).

In retrospect, this format is great for preserving the data, and also
great for virtual disks in my emulator, however it cannot completely
reconstruct the original disk, which makes it less great for physically
rebuilding exact copies of archived disks.

I actually has been assuming that the .H17 format always placed the
sectors in sequential order in the file (I guess I assumed that when
transferring, he just starts with the first logical sector and keeps
reading the next one till the end of the disk - but now I realise that
he may be reading and transferring entire tracks, including the header
information, so at least he COULD be preserving the interleave).

Anyway, the way I would address this in the utility that I write (if anyone
wants me to) to translate back and forth between .H8D and .H17 would be to
allow you to specify an interleave factor (has anyone verified that a .H17
disk image with other than 1:1 interleave does work correctly). I would
package this unility with the simulator, which means that anyone who gets
my simulator will have the utility - then you can store all disks as .H17,
preserving the sector ordering, and anyone using my simulator will have
the ability to translate them into .H8D.

But... .H17 is bigger than .H8D, so if it does NOT work with other than 1:1
interleave, it would make sense to use the smaller format.

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