From: mmphosis@macgui.com   
      
   Kent Dickey wrote:   
   > 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.   
   >   
      
   Very cool little explanation of sector ordering.   
      
   The physical disk is actually circular. Could you write a fast program to   
   draw an image of the disk using HGR graphics?   
      
   mmphosis   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)