[Coco] dw 3

[Aaron Wolfe]

On Tue, Nov 23, 2010 at 7:07 PM, Robert Gault <robert.gault at att.net> wrote:
> 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.
>


Ok.  I think what we are looking at is a system that works very well
for real hard drives (or CF cards, etc.. any large storage directly
attached to a CoCo) but does not work well for a PC tethered solution.

With "real" storage, it makes perfect sense to store multiple disk
images in a partition.  However, this strategy seems inconvenient when
used with DriveWire.   Doing a literal translation of the "partition
full of disks" to a "file full of disks" just makes it more difficult
to do things with those disks in the DriveWire scenario, and doesn't
provide any benefit that I can see.   If I'm missing something please
let me know.

I would propose that going forward, we load individual disks rather
than files containing 256 disks.  This allows easier management of
files and makes it easy to get disks in and out of the CoCo system.

If that is agreeable, then the remaining issues would be to continue
support for those who prefer the 256 disk files (already done) and to
provide a mechanism for those who wish to transition to individual
.dsk files to do so.

This is what the utility I mentioned before would do.  It would take
as input a large file containing 256 disks and create as output (up
to) 256 individual .dsk files, each containing one disk image.  At the
same time, it would create a disk set definition for these new files
so that they can all be loaded with a single operation, effectively
the same as mounting the original file is a single operation.

It seems that supporting the .vhd files is again an example of using
DriveWire in a less than convenient way but if someone is operating
from such a file, I'd like to be able to support that.
I suspect that this is not common.  How about just letting the user
specify the offset to be used rather than trying to determine it
automatically?

Does any or all of this sound workable?
-Aaron