[Coco] dw 3

[Aaron Wolfe]

On Tue, Nov 23, 2010 at 11:13 PM, Robert Gault <robert.gault at att.net> wrote:
> Aaron Wolfe wrote:
>><snip>
>>
>> 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.
>>
>
> That makes perfect sense but HDBDOS could cause problems. At the moment,
> after a DRIVEON (the default HDBDOS setting) drives 0-3 are "hard drives"
> not floppies. When Drivewire is in use in normal mode, these drives are all
> on the same mount/slot. If the user inadvertently saves something to drive1,
> thinking it will go to slot1, drive0 is automatically expanded to more than
> 35 tracks. Of course any drive number higher than 3 makes the selected drive
> larger still.
>
> So, without a rewrite of HDBDOS, DW4 in alternate mode must subvert HDBDOS
> so that different mounts/slots are used rather than drives within a single
> mount. It sounds like that's what you have already done.
> To prevent massive confusion on the part of the user, DW4 should clearly
> indicate which mode it is in and what the drive number means in that
> context: DIR#, DSKINI#, SAVE"filename:#", etc.
>

Agreed.  Being in the wrong mode will cause confusion and could even
lead to data loss.
I can do some things to prevent this, such as detecting an OS9 boot
when in the new mode and complaining/write protecting disks unless the
user confirms they really, really want to do this.  Also, seeing a
drive number other than 0 in a dw op when in the new mode is a clue
that the user may be in the wrong mode.  So, I think I can make the
new mode pretty safe.

The bigger danger is being in the old mode but thinking you're in the
new one.  As you mentioned, this will cause expansion of .dsk files
and writes into unexpected places.  Not the end of the world since I
think those writes won't be on top of data, but certainly confusing.
I'm not sure if there are clues I can detect for this, like there are
in the opposite situation.  I'll keep thinking about it and welcome
any thoughts on that.

I was also thinking about the issue of a split DECB/OS9 virtual hard
drive image with one (or more) DECB disk partitions.   I suppose there
could be more than one OS9 partition too.

If I were to add an offset and size to the data stored about each
drive/file in a disk set, a user could mount one section of a file in
drive 0 and another section of the same file in drive 1 (and so on).
DW could translate the sectors into their relative location in the
file on disk and prevent overwriting a 'section'.
Would this solve that problem?