[Coco] Copy a file from a DW4 virtual disk to a windows directory

[Aaron Wolfe]

I think these issues are explained by the differences and limited
compatibility between the raw or "DSK" format and "JVC" format, both
of which typically end in the .dsk file extension.

The JVC format uses an *optional header*.  The header is not defined
as 2 bytes, it is between 0 and potentially 255 bytes, although only
the first 5 bytes have defined meanings to my knowledge.   The header
can be any size that includes all the fields that are not set to their
default values, including the most common size of 0 bytes, i.e. no
header at all.  The size of the header is determined by the size of
file modulo 256.

The DSK/raw format doesn't have a header, period.  It is simply sector
data.  Unlike JVC, there is no concept of sectors per track, sides,
variable sector sizes, sector attributes, etc.  There is only sector
data, absolutely nothing else.  This format is common both in the coco
world and in other retro computing platforms.. after all, it's dead
simple.

The JVC default values specify a standard single sided CoCo disk.
Thus, all "JVC" disks that represent a standard single sided coco disk
have no need for any header, and if you look at the vast majority of
the .dsk files that can be found online, this is exactly how they are
done.

Because these .dsk files have no header, they are valid in *both* formats.

>From the files themselves, there is no way to know the intent of the
user or system that created these disks as to whether they wanted a
fixed size, JVC floppy disk image or a dynamically sized DSK image, or
whether they had any idea there is a difference.

I don't know the history, but I suspect the raw/dsk format existed
prior to the JVC format, and that is why JVC is designed to be
compatible with them.. in JVC's most common use, it has no header and
is indistinguishable from a DSK.  Since nearly every .dsk file you can
find only has no JVC header but it also a standard single sided disk
(requiring no header to still be JVC compatible), who knows.

Whatever the case, JVC headers are quite rare in the wild.  Since most
disk images are single sided they wouldn't have a header anyway, but
there are also plenty of double sided or other sizes of .dsk files
around with no JVC header.

I believe all of the current emulators do understand the JVC header if
present, but they also know how to load non standard sized .dsk files
without any header in some cases.  For instance, I just glanced at the
excellent XRoar source code to verify this, and XRoar will use the
file size to determine what kind of disk the .dsk represents when no
JVC header (or other known image format marker) is present.  I believe
this is also true of the other emulators.  Using the file size makes
sense for an emulator because it is emulating a floppy drive and there
are only a few possible sizes.

As for JVC and DriveWire... until DriveWire 4, DW just didn't do JVC
at all.  I was not involved in the beginning of DriveWire, but I think
I understand why.

Basically, DW was never intended to emulate a floppy disk drive.
DriveWire works like a hard drive controller, including using HDBDOS
and hard drive-ish drivers in OS9.  Each DW "drive" acts like an
HDBDOS hard drive (or partition), not like a floppy drive.  This is
why the default behavior (DW3 style behavior) in HDBDOS is that Drive
0 through 255 in BASIC are fixed, standard single sided disk sized
regions of the single file inserted in "Drive 0" of the DriveWire
software.  That's exactly how HDBDOS works when used with a physical
hard drive controller, such as the SuperIDE.

Since the JVC format is tied directly to floppy disk images and the
fields in a JVC header have no meaning to a DriveWire device, it is
not surprising that they were not used.  DriveWire wasn't trying to be
a floppy device or to use floppy images, so it didn't use any floppy
disk image format.

I noticed in my own usage and in comments from others that it's really
handy to load individual disk images (typically floppy disk images)
into individual drives as seen by the coco.  A few times a year we
would get a list post from a confused new user wondering why "DIR 1"
on the coco was trying to access the file mounted in drive 0 on the
server... I found it strange myself until I learned all the
background.  It's trying to read the slot for disk 1 in an HDBDOS
partition of 256 disk images, just like HDBDOS on a physical hard
drive.

At some point I added "HDBDOS mode" to DW4 to make this easier, but
this is sort of abusing the design.  I fear maybe it's lead to
DriveWire being seen as a floppy disk device, which it is not.   To
make things worse, I added code to read lots of different floppy disk
image formats, including JVC.  Again, I did this just to make my own
life easier (I actually wanted to use some DMK disk images with
DriveWire, and figured if I was going to do one format might as well
do them all) but I might have lead us into a confusing place.

So... DriveWire reads, write, and creates raw or "DSK" format disk
images, not JVC images.  They are not "DriveWire" images or limited to
compatibility with DriveWire, as you suggested.  In fact, they work
with anything that understands the raw sector format, a very common
thing and found across many systems.  Remember that DW4 supports
systems other than the CoCo... You can use DW with Gary's Apple II
drive card, with an Atari and Boisy's Liber809 card, etc.   You can
even use the files DW reads and writes with tools like 'dd' and most
modern disk imaging tools.  If you're familiar with the ".img" file
extension used to create modern bootable USB keys or to image a hard
drive, it's the same "format" (i.e. no format at all).   If it were
not for the history in using .dsk for floppy images and with DW, I'd
have used .img for DriveWire to be honest.

To the extent that an image in raw/dsk/img format is the same thing as
a JVC formatted image (single sided coco disks, or use with emulators
that understand special file sizes) they are interchangeable.

For instance, create a new disk with DriveWire 4, then immediately
eject it and insert that file (zero bytes in size) into VCC.  VCC will
insert the image perfectly.  You can then DSKINI and use as normal.
Why?  Because its file size is zero bytes.  0 mod 256 is 0, so Vcc
considers it a single sided coco disk.

You can also create a new disk with DriveWire 4, then use DSKINI on it
while still inserted in DriveWire, then eject.  It will again load
perfectly in Vcc and be ready to use.  Why?  Because HDBDOS considers
all disks to be single sided standard coco disks, and the file size
mod 256 is 0, so vcc considers it a single sided coco disk.

So.. for the case of single sided disks everybody agrees and life is
good.  This is however just a happy coincidence, not because DriveWire
was *intended* to use the JVC format, or any floppy disk format.
DriveWire doesn't write JVC files, and JVC header parameters don't
make any sense in DriveWire.  It just works out anyway.

For any size *other* than bog standard, single sided disks, you
probably cannot use DriveWire images in the floppy disk drive of an
emulator.  Remember that DriveWire isn't emulating a floppy drive in
the first place, so this makes sense.  However, standard sized images
should work fine, and they definitely do work fine in Vcc.   I haven't
found any problem creating disks in DW4 and then using them as
standard single sided floppy images in DW or Vcc interchangeably.

You mentioned that "making and formatting a floppy disk in Nitros9 in
a dw4 slot is an absolute disaster."  Well... of course.  DriveWire
doesn't do floppy disks, and the descriptors that come with the stock
NitrOS9 disk aren't meant to be used as floppy disks.  There is really
no concept of a "floppy disk image" in DriveWire, only a way to make
.dsk files.  To the extent that the JVC format is compatible with
certain .dsk files, they can used in an emulator's floppy drive, but
that is limited as described above.

As you noted, the OS9 descriptors don't match floppy disk parameters.
Again, this is because DriveWire doesn't do floppies :)   And again,
if you set the parameters to coincide with compatible values, you can
use the results in an emulator's floppy drive, but that wasn't an
intended thing as far as I can tell.

(Note: I have no idea what those weird parameters used in the the
descriptors *are* supposed to mean, i think they are just placeholders
or something, happened before my time.  Definitely not intended as
floppies though!)

You cannot create a VHD file with DriveWire because yet again we only
write raw/dsk/img type files.  I'm not familiar with the VHD format
but there is a good chance we could read them.  I'm not sure if my
adding the capability to read various formats is helping or hurting in
the long run, though.

Well.... that was a long story.  Summary: If you want standard single
sided disks, everything just works.  If you want anything else,
probably not, and that's probably as intended.



On Wed, Jul 9, 2014 at 4:36 PM, Bill Pierce via Coco
<coco at maltedmedia.com> wrote:
>
> Aaron, first, DW4 creates an "expandable" disk image. This is not supported by anything other than drivewire. It cannot be formatted or expanded by Mess, Vcc, or XRoar. Formats and copies beyond the "actual" disk size will fail in Vcc or Mess's onboard floppy or HD drives. Second, most of the emulators expect the 2 byte JVC header (sectors per track, number of sides). Third, making and formatting a floppy disk in Nitros9 in a dw4 slot is an absolute disaster. The Nitros9 /x0-/x3 descriptors are set for some off-the-wall HD setting I've never seen and will format a Vcc VHD incorrectly and a VHD created with dw4 will not format in Vcc correctly.
> I corrected this in my local copy of Nitros9 by making the /x0-/x3 dscriptors match the Vcc emudsk descriptors. Now they fomat correctly by both methods and can be interchanged on all systems.
> Also, I tried making descriptors for /x4-/x7 match /d0-/d3 but dw4 will not write JVC disk images and the ones dw4 creates are not JVC compatable (above) therefore not compatable with the emulators.
>
>
> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Webmaster of The TRS-80 Color Computer Archive
> http://www.colorcomputerarchive.com/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com
>
>
>
>
> -----Original Message-----
> From: Aaron Wolfe <aawolfe at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Wed, Jul 9, 2014 1:30 pm
> Subject: Re: [Coco] Copy a file from a DW4 virtual disk to a windows directory
>
>
> On Wed, Jul 9, 2014 at 9:26 AM, Bill Pierce via Coco
> <coco at maltedmedia.com> wrote:
>
>> As a note, create all your disk images in Vcc. I don't know if anything else
> creates them properly. I know dw4 does not.
>
> can you elaborate?  dw just creates a zero byte file.  anything in the
> file comes from the coco.  i'm not sure how a program (vcc, dw, etc)
> could do it "wrong" or "right", the entire content of any dsk file
> should be data from the coco itself as far as i know.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco