I considered posting this fact, and you are quite correct. However, I'm not sure how useful that would be, as if the app uses it's own access routines, nothing requires the volume in the sector headers (which is what they will see) to be (IIRC) the one's complement of the VTOC volume--or even for the DOS 3.3 data structures to be valid. Does anyone know if either is the case for the examples Rubywand posted? In the cause, David S. noone@nowhere.net wrote: > Rubywand wrote: > >Like emu writers don't have enough to do, here's another wish list > item: Why not add support for Volume Numbering of .dsk images? > > And don't forget as was pointed out earlier, it is embedded in the VTOC > on track 11, sector 0, Byte 6 on DOS 3.3 diskettes... No file name > convention required. (ProDOS is always the same volume number, 1, I > think.) > > Look for pattern "04 xx xx 03 xx xx ##", ignore the xx bytes and use the > ## number for the volume when reporting to DOS. > > Thankx, > Ed > > Extra info taken form the FAQ about the VTOC on a DOS 3.3 diskette... > > Track 11, Sector 0: > Byte Meaning > ---- ------- > $00 Unused (always $04 on my disks) > $01-02 Track/Sector location of first catalog sector-- the standard > location is Track $11/Sector $0F (17/15) > Note: The location of first catalog sector may be different on some > disks. DOS 3.3 can adjust; but, some utilities (e.g. Copy II Plus) > assume T/S $11/$0F and will not be able to find the catalog. > $03 DOS version number ($03 for DOS 3.3) > $04-05 Unused > $06 Volume Number-- $01-$FE (1-254) is the standard range; > $FE (254) is the standard default VN > Note: This entry merely records the VN for handy reference. > VN is set when a disk is INITed and it is embedded in the > Address header of each sector. > $07-26 Unused > -- "Good judgment comes from experience, and experience comes from bad judgment." --Barry LePatner Since the emulators don't really read the disk anyway, an emulator author could just verify a DOS 33 disk on mount (or whenever it is determining sector dsk vs PO order or whatever) and hold that info in a variable and drop it into the RWTS routine whenever a sector read is called. :) Now if the software is actually pulling nibbles off the 5.25" disk, then it is not going to work, but regular program looking for a volume number will be polling the RWTS Volume location after a read. (Which should work.) Thankx, Ed David & Barbara Schmidt wrote: > However, I'm not sure how useful that would be, as if the app uses it's > own access routines, nothing requires the volume in the sector headers > (which is what they will see) to be (IIRC) the one's complement of the On Fri, 17 Jan 2003 16:12:47 GMT, Rubywand wrote: > Like emu writers don't have enough to do, here's another wish list item: > >Why not add support for Volume Numbering of .dsk images? Take a look at the file format for 2IMG images at: http://www.a2central.com/programming/filetypes/ftne00130.html If bit 8 of the flags field is set then the low byte of the flags field holds the DOS 3.3 volume number. Why not just use a method that has been available for some time? -- Jeff Blakeney - Dean of the Apple II University in the Apple II Community on Syndicomm.com CUT the obvious from my address if you want to e-mail me