Re: Suggested change to add volume numbering to .dsk disk image files

[Rubywand <rubywand@swbell.net>]

Thug writes ...
> 
> "Rubywand" <rubywand@swbell.net> wrote in message
> 3997E6D0.E98B760F@swbell.net">news:3997E6D0.E98B760F@swbell.net...
> >
> >      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.
> 
> This is only a problem with programs that check the volume number in the
> nibblized address field, yes? So .NIB images already get around this?

     On an emulator, yes. The file uses a lot more space and takes longer to
download; but, otherwise, .nib files work fine on most emus.

     The main problem is that, with .nib format, you do not have the image in
a form which allows easy transfer and conversion to diskette on an Apple II.


> Plus, with DOS 3.3 and compatible formats, could the emulator not pick up
> the volume number from the VTOC? (Track $11, Sector $0, Byte $6. I don't
> know if there's a similar record in ProDOS.) Protected disks or disks with
> their own custom DOS are still a problem, of course...
>

     A diskette which is INITed under DOS 3.3 will have the Volume Number
placed in the location you mention in the Volume Table of Contents sector.
Still, as Joseph observes, this does not mean that you can depend upon
finding a record of the Volume Number in the VTOC, especially on old
commercial diskettes (whether or not the diskette has been 'deprotected').

     Game, etc. disks are often copy deprotected and converted to .dsk images
without significantly changing the special DOS employed. Many of the special
DOS's do not use or care about a VTOC. More likely than not, the VTOC sector
will be used for storing program or data code.

     What this boils down to is that, for lots of old software, the byte at
T/S $11/$00 byte $06 is not a reliable indicator of Volume Number.


 ....
> 
> Really, what we ultimately need is a new more versatile image format.
> Something that can handle this situation, as well as things like disks
> with 36+ tracks, etc. A format which allows for forward and backward
> compatibility using data tags or something similiar.
 ....

     Agree. One reason for suggesting that the change be implemented via
optional file name add-ons is that the format of the file content is already
as clean and elegant as one could wish-- i.e. the file = data bytes on the
disk. (Except, naturally, for 36-tracks there would need to be an additional
4096 bytes in the file.)

     Another consideration is that changing the format of the .dsk disk image
content would introduce all sorts of compatibility problems. File name
tagging (e.g. for Volume Number and/or 36-tracks) lets emulators which
recognize the tags take advantage of them. It does not force changing any
currently working .dsk files (or their names);  and, these .dsk files will
continue to work correctly on all emulators, including those which do not
recognize name tags.



Rubywand