[sebhc] h17 and h8d disk images

[Dan Lanciani]

"Dwight K. Elvey" <dwight.elvey at amd.com> wrote:

|>|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 ).
|>
|>Which H17 driver supported creating interleaved formats?
|
| I use many of the calls from the H17. I have lifted the format
|code from the H17 code and patched in the interleaving. Once
|the disk is formatted, the H17 doesn't care if it is interleaved
|or not since it only looks at the headers to find sectors.
|You can see my code in the H89LDR9.ZIP file, source
|file H89LDR2.ASM. The idea of interleaving was done by many
|others before me. I just added it to my code for those that
|want it. As long as I'm reading and writing through H17
|routines, it makes no difference other than time.

I know what interleaving is.  I'm asking which real-world H17 driver
supported the creation of interleaved disks.  At the time I was really
into this (I had my own heavily modified SY: driver) and I had never
come across such a thing.

|HDOS it
|self has an OS level interleaving like CP/M but it is not easily
|modified at the OS level as CP/M is.

Not really.  HDOS interleaved the directory sectors, but not with a fixed
mapping, i.e., it didn't care if they weren't set up that way.  CP/M BIOS-
based interleaving was typically a direct mapping done "transparently" on
each track.

| It sounds like we are still in good shape. You'll just
|have to watch out for any disk created with my transfer
|code that someone chose to take advantage of the interleaving
|option. It sounds like your code will bomb out on them.

"fail gracefully"

			Dan Lanciani
			ddl at danlan.*com
--
Delivered by the SEBHC Mailing List