[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