[sebhc] h17 and h8d disk images

[Dwight K. Elvey]

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.
 The problem exist if one takes a disk with interleaving and
reads it as a physical image, that has interleaving, and tries
to use it using either your format or the current h8d format.
Both your and my methods read the sectors through the
information of the sector headers that exist on the disk.
These may not be in the physical order and loses any
interleaving information.
 I don't know if Dan is extracting the sector header information
and using that to determine the order of the sector blocks
or just reading the disk order. It is true that all original
HDOS distribution disk have the natural order. This may not
always be the case. Dan mentions in a previous mail that the
only staggering he knew of was skewing but it was quite common
to use a 2:1 or 3:1 interleaving on HDOS disk ( you'll note that
my transfer program even has this option for creating disk ).
This was done quite often for BASIC programs because of BASICs
slow method of accessing the disk that would cause it to skip
looking at the next sector. Interleaving made about a 8 to one
speedup in the program loading time. This isn't a big deal
for small programs but any with large DATA statements can
be painfully slow.
 The CP/M disk should be OK since CP/M had a feature of doing
interleaving within the OS to avoid having altered disk. There
is no reason to resort to physical interleaving.
 If one were to take one of the disk that was created with my
program, using the interleave option, and later read it with
Dan's system, I'd suspect it would take some time to rebuild
it, since the sectors would not be in the natural physical order.
 As for only having the one format I'd not like to to see this.
I would prefer to see a simple utility to translate your format
to the simpler h8d format and back to the h17 format than
see your format go away. I've written a simple h17 to h8d converter
program myself but it would need a little friendlier interface
before I could hand it out. Converting back to h17 from h8d would
take a little more effort since your format contains more robust
information about the disk structure as well as comments.
 I guess the question for Dan is, do you assume that the physical
sector order matches the logical sector order when creating
your image files or do you map the logical sector order into
the order used in the images?
 We should change the names that Dan has sent to keep things
consistent as soon as we can and post that so that anyone mirroring
can make the changes.
Dwight


>From: "Dave Dunfield" <dave04a at dunfield.com>
>
>>The .h17 format preceded the .h8d - these images are "verbose" hex dumps
>>of various disks using Dave Wallace's algorithm. This is also the format
>>that Eric Rothfus uses with his SVD device. 
>>
>>The .h8d format was developed by Dave Dunfield for his H8 emulator;
>>Stephen Parker transformed many .h17 disks into .h8d images by stripping
>>the track and sector info (and converting to binary?). At least for the
>>HUG material, the same disks should be available in both formats.
>>
>>Jack
>
>Hi Guys,
>
>I haven't checked into the archive in a long time - been tied up with
>other things... must do so, sounds like good things are happening.
>
>If it would be useful, I would be happy to write up a little utility
>to convert .H17 to and from .H8D (by removing or adding the track/sector
>informaion) - just point me at a good description of the .H17 format.
>Then we don't have to maintain two copies of everything.
>
>Also, I've got it in my mind to modify the emulator so that it can boot
>CP/M ... Presumably I need to add the "RAM at 0" option ... anything else
>needed?  I don't have any technical info on this - can someone give me a
>pointer?
>
>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
>


--
Delivered by the SEBHC Mailing List