[Coco] dw 3

[Robert Gault]

Aaron Wolfe wrote:

>
> How about a tool to turn these 256drive.dsk images into a directory of
> separate .dsk files and automatically generate the dw4 disk set
> definition to load them together?  The user can then temporarily map
> in a disk from any source, including another "converted" 256drive.dsk
> and do the copy or backup directly.  The disk set definition allows
> these files to be loaded together into the 256 "drives" just like a
> 256drive.dsk.
>
> I am basing this solution on the 256drive.dsk format being used only
> with drivewire and hdbdos.. nothing else reads these, so we aren't
> losing compatibility with anything by just getting rid of them,
> correct?
>

To be frank, I'm not sure I understand what you propose. I think it may be what 
we need but without a specific example or a demonstration, I can't tell. Maybe a 
rewording of the proposal?

>
> I can add a parameter to a disk set that tells dw4 to compensate for
> this offset, and add a matching per drive setting with a 'dw' command
> to toggle it.  Similar to hosw things like write protect work.  Would
> that work, and if so, how do i compensate for the offset?
>

The Disk Basic sector offset is contained in the HDBDOS/RGBDOS ROM, bytes 
$D939-$D93A. This a 24-bit address. The value for MESS and VCC by default is 
$5A000 and very unlikely to have been changed by any user. Hardware systems are 
different given different sizes of hard drive. The offset value could be 
anything depending on the size of the drive and whether the user requires OS-9 
and/or Disk Basic.

You may find that DW4 needs to determine the offset directly from the .dsk or 
.vhd image rather than the HDBDOS ROM. That can be done but there is no 
sure-fire method for determining if the first part of the drive is an OS-9 
partition. If it were, then the first three bytes of LSN0 give the size of the 
drive in sectors and is the offset.
As it happens, there is also no distinction between backing up an OS-9 floppy to 
drive0 on a multi-drive .dsk image from a true .vhd image that is say half OS-9 
and half Disk Basic. Luckily the point is moot because the first three bytes of 
LSN0 are still valid.

I probably should throw in the following possibility. You don't need to limit 
the number of Disk Basic drives on a .vhd or true hard drive to 256. Since a 
Coco3 runs in full RAM, the bytes at $D939-$D93A may be POKEd with new values. 
That means you can have multiple Disk Basic partitions each with 256 drives if 
the hard drive or image is larg enough.