From: gids.rs@sasktel.net   
      
   > What is your suggested algorithm for auto-detecting the sector order of    
   > .dsk images?    
      
      
   I imagined this as an auto-detector.   
      
   I like the way Sweet16 loads disk images.  It makes a best guess as to what   
   order the disk image is and if unable to decide it loads it as a RAW file.    
   And due to this RAW file format, one can load Commodore 64 disk images which   
   are 174,848 bytes    
   compared to Apple II disk image of 143,360 bytes.  Which was then easy to   
   convert C64 T/S's to DOS T/S's.   
      
   I would assume the best way to auto-detect an image is to load all disk images   
   as RAW data which can be used by an OS that reads/writes blocks.  It is just   
   simple math that converts to Track/Sectors.   
      
   A Prodos image is identified as having these standard unchanged bytes that   
   would be extremely rare to have duplicated on an image that is just data.   
      
   Block #2 - has byte #2 = $03 and byte #4 = $Fx   
   Block #3 - has byte #2 = $04   
   Block #4 - has byte #2 = $05   
      
      
   A DOS image has this:   
      
   Block #88 (which calculates to Track 17 Sector 0) - bytes #1 & #2 show the   
   Track/Sector start of the first Sector of the directory.  Normally shows $11   
   0F, but modified disks can be anything.  I have on occasion changed this to   
   $11 01 and then have Track    
   $11 Sector $01 - byte #1 changed to a $00 to indicate the end of the   
   directory.  This allows only 7 file names but frees up the other 14 sectors of   
   the directory for data on Track 17.   
      
   But technically, byte #1 of Track $11 Sector 0 should match byte #1 of the   
   directory sector it points to.  for example, if byte #1 and #2 of Track $11   
   Sector 0 is $11 0F, then byte #1 of Track $11 Sector $0F should also be $11,   
   but can also be a zero for    
   end of directory.  This is very easy to find if the first directory sector is   
   in the same track as the VTOC track number and since Sector $0F is in the   
   second half of Block #88.  From an emulators perspective should be very easy   
   to get and compare byte #   
   1 of the VTOC and byte #1 of the first sector of the directory to determine   
   the disk image is a DOS disk image.  But byte #1 of the next T/S pointer would   
   still have to be read in to determine if this disk is DOS order or Prodos   
   order.   
      
   PCDOS and HFS are also very easy to determine using this RAW block method, as   
   well as I imagine CP/M would be.  I think an emulator should read in the   
   entire track of $0-F and $11-1F into memory, then it should be able to easily   
   identify any disk image    
   that gets loaded.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)