[Coco] dw 3

[Robert Gault]

Aaron Wolfe wrote:

>
> 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?
>

Here is a suggestion that might solve most of the problems.

Make DW4 check the names of the disk images and alter behavior based on the 
found extension.
If the extension is .dw4, then the server should prevent any attempts to extend 
the image size by a request from HDBDOS to write to an LSN beyond the size of 
the disk. The disk, for convenience, could be limited to a single sided 35 track 
disk or the size could be a check option on the server gui. The server could 
automatically access a new slot but that could destroy data if the user did not 
have an image mounted or did not intend an overwrite.
If the extension is .dsk, then the server would permit the type of image 
accepted by DW3, a disk holding 256 35-track drives. The server would also know 
that there was no OS-9 partition.
If the extension was .vhd, then the server would assume the image was a MESS or 
VCC type which had an OS-9 offset. The Disk Basic offset could use the default 
value of $5A000 or the server could read the first three bytes to obtain the 
offset value.

This all assumes a default DW HDBDOS ROM which has $000000 for the OS-9 offset 
value. If a user wants to have more than one Disk Basic 256 drive partition, the 
user can POKE new values into the HDBDOS offset and the DW4 server needs do 
nothing unusual.
I don't think you need to consider more than the normal one large OS-9 partition 
on .vhd images.

There is no way to fail-safe every write operation without antagonizing users 
with constant "Are you sure?" messages. :) MESS is already jumping through hoops 
trying to accommodate all different types of disk images and has been forced to 
use .dsk, .os9, and .vhd to distinguish between some of the types.