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

[pausch@saafNOSPAM.se (Paul Schlyter)]

In article <39ACC9B8.A40A132D@swbell.net>,
Rubywand  <rubywand@swbell.net> wrote:
 
> 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.
 
I don't know about that -- after all a .nib format image is nothing
but a raw dump of the bytes as they actually appear in the diskette.
What's lacking is software to transfer a diskette directly to a .nib
image, and the other way around.
 
>> 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.
 
Not really -- a .nib format file = bytes as they actually are stored
on a diskette.  To get at the bytes in the file, some conversions must
be done.
 
> (Except, naturally, for 36-tracks there would need to be an additional
> 4096 bytes in the file.)
 
...not to mention 40-tracks, or 80-tracks...   it would be quite easy to
extend a .dsk image for any number of tracks though.
 
> 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.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch