Subject: Re: Suggested change to add volume numbering to .dsk disk image files
From: Rubywand <[email-masked]>
Date: Sat, 02 Sep 2000 00:47:56 -0500
Newsgroups: comp.sys.apple2,comp.emulators.apple2

Theusch Family writes ...
> 
> On Mon, 14 Aug 2000 07:32:16 -0500, Rubywand <[email-masked]>
> wrote:
> 
> >
> >     A long-standing problem is the failure of .dsk disk image format to
> >preserve volume number for DOS 3.3 disks-- i.e. disks which run under DOS 3.3
> >or some variant. As a result, quite a few games and other pieces of software
> >which use special volume numbering for disk identification will not run
> >correctly from .dsk.
> >
> >     Instead of changing the format of .dsk file content, perhaps emu writers
> >could adopt a file naming convention which allows specifying volume number. A
> >letter-number code just before the ".dsk" suffix could specify volume number.
> >
> >     For example "VV238" in the file name NARFGAMEVV238.dsk would tell the
> >emulator that the NARFGAME disk has Volume Number 238.
> >
 ....
> 
> A good idea, albeit temporary.  What use would it be to be
> backwards-compatible with disks that won't work without volume number
> anyway?

     Not sure what you mean by the above. The backward-compatibility would be with
disk images (.dsk files) which do not _care_ about Volume Number or which have
been modified to accept the default DOS 3.3 VN (254).

     Naturally, the above includes virtually all current .dsk disk image files in
regular use on emulators like AppleWIn (since, otherwise, the .dsk disk images
will not work).

     A File Name tagging option allows use of the current large collection of
standard disk images without any modification at all. If a disk image performs
okay, neither the file content nor file name needs to change.

> Long filenames can be an issue on old MS-DOS-based machines.

     Yes; however, users of old MS-DOS-based machines should, by now, be used to
routinely changing the names of files downloaded from the net. The "8.3" file name
format leaves enough space for MS-DOS users to change file names of downloaded
files so that they are unique while still preserving name tagging.

> My point being, if emu writers change their code to support volume
> number implementation, it would be just as well to support a new,
> dsk-based file format.  How about, .aii?  It could support one or
> more sides of a 5.25" floppy, with 35-, 36-, or 40-track sides.  Or,
> it could be an image of a 3.5" floppy or hard disk.  Bad tracks or
> sectors would be copied, too, to allow full and complete
> representation of the original media.  A header might look like this:
> 
> (in html form :>)
> 
> <HEADER>
> AIID            - 4-byte string- ID tag
> [XXXX]          - DWORD, in bytes- Offset of disk data.
> [XXXX]          - DWORD, in bytes- Size of disk data (all sides).
> [XXXX]          - DWORD, in bytes- Size of per-side header data.
> [X]             - Byte, in sides- Number of sides.
> [XXXXXXXX]      - 8-byte string- Spacer for future implement.
> <PER-SIDE HEADER DATA>
> <HEADER DATA FOR SIDE 1>
> [XXXX]          - DWORD, in bytes- Size of header data for side 1.
> [XXXX]          - DWORD, in bytes- Size of disk data for side 1.
> [XXXX]          - DWORD, in bytes- Offset of disk data for side 1.
> [XXX]           - 3-byte String- Format of side- DSK, NIB, RAW, or
> -                                     whatever.
> [X]             - Byte- Volume number for side 1.
> [X]             - Byte, in tracks- Number of tracks for side 1.
> [XXXX]          - DWORD, in bytes- Size of error table data (can be 0
> -                                       if no errors).
> [XXXXXXXX]      - 8-byte string- Spacer for future implement.
> <ERROR TABLE DATA (optional)>
> [XXXX]          - DWORD, in bytes- Offset from beginning of disk side.
 ....
> .
> 
> </PER-SIDE HEADER DATA>
> </HEADER>
> 
> <DISK DATA FOR SIDE 1>
>         (Disk Data)
> </DISK DATA FOR SIDE 1>
> <DISK DATA FOR SIDE 2>
>         (Disk Data)
> </DISK DATA FOR SIDE 2>
> 
> All offsets are offset from the beginning of the file, except the
> error table data, which are offset from the beginning of that side's
> disk data.  Format can be any supported format
 ....

     Interesting approach. Thing is, it is too late to 'reinvent the wheel'. We
have a format for 5.25" Apple II disk image files which is open, easy to work
with, and well established via thousands of .dsk files maintained on numerous
sites and in many individual collections.

     Remember, the 'problem' is limited to a relatively small number of old A2
products which do not work as .dsk images. These can be handled via various levels
of cracking and end up as .nib files or, eventually, as .dsk files. The .dsk
format is preferred over .nib because .dsk files are easy to transfer to/from
Apple II's and more compact than .nib files; but, .dsk images do not preserve
Volume Number.

     There is hardly ever a simple way to allow a product which uses volume
numbers to identify its disks to work correctly without volume numbering. Cracking
the copy protection of the game, etc. is not enough-- you have to modify one or
more programs on the disk(s). 

     The rationale for using file name tagging to indicate Volume Number is that
it's an easy way to allow quite a few products-- those which are in .nib form just
to preserve Volume Number-- to work as .dsk files. An emulator which sets Volume
Number of a .dsk image to 254 could, just as easily, set it to some other number.

Rubywand