[Coco] dw 3
aawolfe at gmail.com
Sun Nov 21 18:41:52 EST 2010
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
> 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.
More information about the Coco