[Coco] dw 3

[Aaron Wolfe]

On Sun, Nov 21, 2010 at 5:40 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> On Sat, Nov 20, 2010 at 7:11 PM, Darren A <mechacoco at gmail.com> wrote:
>> On 11/20/10, Richard Hawk  wrote:
>>> ok i finally was able to copy to a real coco one more question i can not
>>> access drive 1,2,3 on the server side,  i type drive on and dir and the
>>> drive 0 on the server comes on what ever drive number (drive 3) the drive 0
>>> light comes on and flashes'
>>> thanks alot man confusing
>>>
>> ---
>>
>> Each drive (or slot) on the DriveWire server represents a virtual hard
>> disk that can hold up to 256 virtual floppy disks.  To select a
>> specific virtual HD, enter DRIVE #n  where n is 0 to 3 (be sure to
>> include the #).
>>
>> Once you have selected a virtual HD, you can enter DRIVE n (without
>> the #), where n specifies the virtual floppy disk number (0-255)
>> within the current virtual HD.
>>
>
> That makes sense.  I never really understood what was going on with
> HDBDOS and disks.  I see now that have done some things "wrong" in
> drivewire 4.
>
> Right now, if you use it in 'regular' mode, it works like dw3 does.
> Disk 0-255 in basic all read sectors from the file mapped into "Drive
> 0" with an offset of (disk number * 630).
>
> I added a "HDBDOSMode" which will map requests to drive 0 into drives
> 0-255 based on that same offset, so that you could load individual
> .dsk files into the drives rather than have them all in one large
> file.  This seemed easier to deal with, especially when you want to
> copy between real disks to  .dsk images.  Rather than copy a real
> floppy into an offset in a big file, you can copy it directly to it's
> own .dsk.
>
> But.. now i see that using DRIVE #, we could also see requests coming
> for drive 1-3 (or can you do all the way up to DRIVE #255?).  this
> would break my current HDBDOSMode which assumes all requests will be
> to/from drive 0 and uses the sector to determine which .dsk to talk
> to.
>
> Anyone have an opinion on what the right thing to do here is?  I could
> just say "HDBDOSMode only works with DRIVE #0, and that's that".  I
> could remove hdbdosmode and say "Drivewire 4 works exactly like
> drivewire 3, end of story" (though I think it's handy to be able to
> get to individual .dsks).  Or, I could try to do something to make
> (DRIVE #x * DISK #y) actually work, but I'm not sure how.
>

For now, I've updated dw4 to ignore the drive number sent from hdbdos
altogether when in "hdbdosmode".  This means DRIVE #x won't do
anything.  DRIVE x will point you to the .dsk file loaded into the
corresponding slot regardless of DRIVE #x.