From: kegs@provalid.com   
      
   There was a thread here about detecting the sector ordering of Apple II   
   5.25" .dsk images (unfortunately under Michael Mahon's FASTCIRC post).   
      
   I maintain that .dsk images should always be DOS 3.3 sector order, .do   
   images are always DOS3.3 sector order, and .po images are always ProDOS   
   order.  All images > 140KB are ProDOS order, as well as any unknown extension   
   (so harddrive images and 3.5" 800KB images are always ProDOS order).   
      
   The ease of creation of ProDOS images with tools like Cadius now means   
   people are creating many new images on modern computers.  If they name   
   their image files .dsk (which seems like the "right thing to do"), then   
   they've created new .dsk images in ProDOS order.   
      
   A description of sector order is at the end of this message, feel free to   
   skip it if you know this stuff, or don't care about the details.   
      
   As for detection, Applewin uses a simple easy-to-understand algorithm to   
   determine the sector order of .dsk images:   
      
   A .dsk defaults to DOS 3.3 sector order.  However, if a DOS 3.3 catalog   
   track appears to exist on track $11 by looking at the first 2 bytes of   
   each sector, when assuming the disk is in ProDOS order, then it treats the   
   .dsk image as ProDOS order.  Or, if a ProDOS volume directory appears to be   
   on blocks 2,3,4,5 on track $00 by looking at the first 4 bytes of each   
   block when treated as ProDOS order, then the .dsk is treated as ProDOS order.   
      
   I like this simple check, since it's looking for well-formed disk images   
   with normal catalog tracks.  This makes sense if a main source of the   
   images in ProDOS order is modern tools creating these images.  If an image   
   doesn't look like a normal DOS 3.3 disk or ProDOS (say, no OS at all, like   
   a game would do), then .dsk is always DOS 3.3 sector order.   
      
   But this detection seems to have a problem: if a user mounts a prodos1.dsk   
   created by Cadius in ProDOS order, it will work fine as long as the user   
   keeps using it as a normal disk.  But what if the user then, under   
   emulation, plays a game which wants to format a save disk to save   
   progress on, and picks this prodos1.dsk?  The resulting image probably   
   no longer has a valid catalog.  Applewin will read and write the   
   prodos1.dsk image in ProDOS order since that's what it knows to do for   
   as long as the user runs the game in one session.  But when stopped and   
   restarted later, the .dsk detection routine will now say the prodos1.dsk   
   image is DOS 3.3 order (since it cannot tell), and the saved game is   
   lost.   
      
   So my proposal:  Emulators should support detecting .dsk images as ProDOS,   
   but should use a very simple check like Applewin's.  And if a .dsk image   
   is determined to be ProDOS order, then the emulator should immediately   
   re-write the .dsk image file as DOS 3.3 order.  If the image is write-   
   protected or not writeable, then do nothing.  This solves the misdetection   
   problem of using .dsk images in ProDOS order--.dsk is always DOS 3.3 sector   
   order to the emulator   
      
   Kent   
      
   ----   
      
   As background, Apple II 5.25" disks generally contain 16 sectors of 256-bytes   
   each on 35 tracks.  On the physical disk, these sectors have a physical   
   sector number, counting from 0-15 in order on the disk.  DOS 3.3 knew it   
   could not read adjacent sectors that fast, so it has a table of logical   
   sectors to physical sectors, to try to give it more time to process   
   adjacent logical sectors.  All DOS 3.3 operations are on logical sectors.   
      
   Physical sector: 0 1 2 3 4 5 6 7 8 9 a b c d e f   
   Logical  sector: 0 7 e 6 d 5 c 4 b 3 a 2 9 1 8 f   
      
   This arrangement is great for booting DOS 3.3, where it reads logical sector   
   'f', then 'e', 'd', etc.  Once 'f' is found, 'e' is 3 sectors later, and   
   'd' is 2 sectors after that.  That is about as fast as the DOS 3.3 RWTS can   
   read.  It turns out, DOS 3.3's File Manager is so slow that between   
   reading sectors during LOAD or BLOAD, about half a track passes by while it   
   twiddles its thumbs between each sector.  This is why there are enhanced   
   DOS's which are more efficient.   
      
   ProDOS has a logical 512-byte block.  So it needs to map it's blocks to   
   sectors.  Here's that mapping for 5.25" disks.   
      
            ProDOS   block:   0    1    2    3    4    5    6    7   
   DOS 3.3 physical sector:  0,2  4,6  8,a  c,e  1,3  5,7  9,b  d,f   
   DOS 3.3 logical  sector:  0,e  d,c  b,a  9,8  7,6  5,4  3,2  1,f   
      
   In DOS3.3 sector order, the .do image has DOS 3.3 logical sectors 0...f   
   in ascending order.  This is what users would think is the natural order   
   for sectors since any sector editor would make the disk appear to be in   
   this order.   
      
   In ProDOS block order, a .po image has ProDOS blocks in ascending order 0...7,   
   which works out to DOS 3.3 logical sectors: 0,e,d,c,b,a,9,8,7,6,5,4,3,2,1,f.   
      
   Note the physical sector order does not matter at all for .dsk, .do, or   
   .po images.   
      
   In general, almost all "classic" .dsk images (created more than 20 years ago)   
   are in DOS 3.3 logical sector order since that's what tools of the time   
   generally did.  But now there are various ways to quickly make ProDOS images   
   on modern computers--and if users name their files .dsk, then they are   
   creating .dsk's in ProDOS order.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)