[Coco] dw 3

[Aaron Wolfe]

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

Agree the world has far too many "Are you sure?" prompts in it, I
don't want to add any more.
File extensions would work, but I worry that the various meanings are
already unclear and adding another one to the mix is increasing the
chances that someone would misname a file and defeat the protection
the correct name would provide.

I've whipped up a similar solution implemented a little differently. I
think its pretty good, flexible, and even allows some things to be
easy for a user that I hadn't thought could be made so easy.

A disk set contains parameters for each disk to be loaded (these
correspond exactly to the per drive settings available while the DW
program is running).  The most necessary is the path to the file to be
used.  Until now, the only other significant setting available was
write protect, which would simulate the WP tab being set and prevent
writes.

I've added some new parameters which I think will allow "safe" use of
the two modes and also allow more flexible use of all kinds of disk
image files.

The first is a setting which allows or disallows expansion of the disk
file.  Write errors will be sent if the CoCo attempts to seek past the
end of the file.  This lets us make sure data doesn't go somewhere
unexpected.

The second is related: a size limit in sectors.  Does what it sounds
like, write errors if the CoCo seeks past this number.  This is a
little different in practice than limiting to current file size,
especially when combined with the third setting, an offset.

The offset is applied to the sector the CoCo requests before reading
or writing it to disk (and before checking if it exceeds the sector
limit mentioned above).  When combined with the sector limit, this
allows one to create a safe "window" into a disk file.  The offset can
be specified two ways, either in sectors or as an "HDB disk number"
which is simply turned into a sector offset internally (HDB disk # *
630).

We can use the offset and limit combined with the new mode to map in
specific disks from inside existing 256disk.dsk files.  If a user
wants to copy a file from disk 30 in one 256disk.dsk file to disk 80
in another, they just mount file 1 with "hdbdos offset" 30 in any
drive, and file 2 with hdbdos offset 80 in any other drive.  Now they
can copy between there drives on the coco, effectively moving files
directly between two 256disk.dsk files.   You can also use this to
rearrange disks without actually moving them.. the user can load
hdbdos offset disk 40 into the CoCo as drive 2, 3, or 40.. doesn't
matter.

You can mount several disks inside the same 256disk.dsk file at the
same time since the offset and limit will ensure there are no
conflicts.  All writing to the actual disk from memory is done in a
single thread so no worries about locking, etc.

I think I can make the presentation of all this simple in the GUI..
its just one additional control on the screen when inserting a disk.

Finally I added the ability to associate an operating mode with a disk
set.  Whenever that set is loaded, the old or new mode can also be
set.  This should help prevent accidentally being in the wrong mode in
the first place.

It seems to be working fine now.. I'll test, clean and commit the code
and build a new server package for download over the holiday weekend.
For testing I added one more option, which allows changes to the in
ram copy of a disk but doesn't actually write them to disk.. comes in
handy when you don't trust your own code :)

-Aaron