[Coco] dw 3

[Frank Pittel]

On Tue, Nov 23, 2010 at 07:42:20PM -0500, Aaron Wolfe wrote:
> 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?

In the long run it may be easier to use indvidual files rather then single files
with large numbers of disks. I don't have my rsdos book handy but as memory
serves it's possible to "name" a floppy. Any chance of drivewire naming the .dsk
file to that label? Also, in the interests of maintainability you may want to
offer the ability to "load" a directory. That directory would have the .dsk
files to be loaded and optionally a file that contains the order. Having to
manually "load" 256 files into the drivewire server would be a major pain!

The Other Frank