[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



"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?

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...

And not that your idea isn't a good one! It's just that the info is already
there, and it does stuff the 8.3 DOS naming rule, which should probably
still be avoided, even though 90% of people can use Long File Names now.
(Running ApplePC is probably the best use for a 486 running MS-DOS these
days!)

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.


Michael