Subject: Re: Suggested change to add volume numbering to .dsk disk image files Path: lobby!newstf02.news.aol.com!portc01.blue.aol.com!newsfeed.mathworks.com!cyclone.swbell.net!nnrp2.sbc.net.POSTED!not-for-mail Message-ID: <39B0948C.3CCB86C5@swbell.net> From: Rubywand X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.sys.apple2,comp.emulators.apple2 References: <3997E6D0.E98B760F@swbell.net> <39ad913f.37890116@news.wi.centurytel.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 122 Date: Sat, 02 Sep 2000 00:47:56 -0500 NNTP-Posting-Host: 216.62.143.112 X-Complaints-To: abuse@swbell.net X-Trace: nnrp2.sbc.net 967873678 216.62.143.112 (Sat, 02 Sep 2000 00:47:58 CDT) NNTP-Posting-Date: Sat, 02 Sep 2000 00:47:58 CDT Organization: SBC Internet Services Xref: lobby comp.sys.apple2:105516 comp.emulators.apple2:20985 Theusch Family writes ... > > On Mon, 14 Aug 2000 07:32:16 -0500, Rubywand > 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 :>) > >
> 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. > >
> [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. > > [XXXX] - DWORD, in bytes- Offset from beginning of disk side. .... > . > > >
> > > (Disk Data) > > > (Disk Data) > > > 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