From: kegs@provalid.com   
      
   In article , Oliver Schmidt   wrote:   
   >Hi Michael,   
   >   
   >>> If there is any "standard" at all, then it's this:   
   >>>   
   >>> .do: DOS3.3 order   
   >>> .po: ProDOS8 order   
   >>> .dsk: Go figure   
   >   
   >> But I stand corrected, and will review my site and adopt the “standard”   
   as   
   >> I have the time.   
   >   
   >There seems to be a misunderstanding. I do NOT see an issue with .dsk files   
   >having ProDOS ordering!   
   >   
   >.do and .po both imply a statement regarding their ordering but .dsk does   
   >NOT imply any ordering - and therefore a .dsk can per definition never have   
   >a wrong ordering.   
   >   
   >At least that is my POV which I wanted to express with my last posting.   
   >   
   >Regards,   
   >Oliver   
      
   The two main problems with .dsk being "Go figure" is:   
      
   1) It makes emulators harder to write.  An Apple II emulator is pretty easy   
   to get started with, and my guess is there are at least 20 freely   
   available.  But: needing to auto-detect .dsk can be quite complex to do well,   
   and it's one of many features that emulators seem to need that raises the bar   
   to get new emulators.   
      
   2) It's actually not possible to detect PO or DO for an arbitrary .dsk   
   image.  Let me see your code you're using to auto-detect, and I can   
   create an image which it will fail on.  And many games have no OS, so there's   
   no great way to detect PO or DO of these images.   
      
   I think AppleWin's detection algorithm for .dsk is:   
      
   - Detect .DO order first.  See if the link pointers on Track $11 look   
   	like a DOS 3.3 catalog track for all sectors 0-14, looking at byte   
   	+$02 in each sector.  If it is, it's .DO.  Then look to see if   
   	blocks 2,3,4,5 on track $00 look like they have the ProDOS links   
   	in the first 4 bytes of each block look valid for DOS 3.3 order.   
   	If so, it's .DO.  Otherwise, it's MAYBE .DO, which will be the   
   	choice if nothing else matches.   
      
   - Detect .PO order next.  Checks DOS 3.3 catalog track first, but only checks   
   	some of the sectors (I'm not sure why, probably a trick of sector   
   	numbers).  If it looks valid, it's .PO.  Then check blocks   
   	2,3,4,5 for the ProDOS links in the first 4 bytes.  If it   
   	matches, it's PO order.   
      
   - Anything not detected defaults to .DO order   
      
   Note, this can be confused by a file on a ProDOS image in ProDOS order   
   that is on track $11 (blocks 136-151) and matches the DOS 3.3 pattern it's   
   looking for.  It would be better if AppleWin checked ProDOS directory patterns   
   first when considering ProDOS order, to help avoid this confusion.  And I'm   
   not picking on AppleWin, it just is the easiest source for me to look at.   
      
   Kent   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)