From: thefadden@gmail.com   
      
   On Sunday, August 13, 2023 at 8:35:57 AM UTC-7, Steven Hirsch wrote:   
   > > (1) Did the CP/M v3.1 filesystem format extensions make it to the Apple II?   
   > Depends upon the vendor's implementation. CP/M-3.x timestamping was always   
   an    
   > optional feature that required initialization of the directory for those   
   extra    
   > entries and BIOS implementation to read/write them. A system that doesn't    
   > support them simply ignores the entries since they exist in an "impossible"    
   > user area.   
      
   That's what I was hoping for.  If they had to be generated on the fly things   
   would be more complicated.   
      
   > Referring to user area locations with the N: prefix is quite standard in the    
   > enhanced CP/M world, e.g. Z-System. That's exactly how image manipulation    
   > utilities like cpmtools manage them. Only enhanced CP/M implementations    
   > support user areas > 15. Anything greater won't be damaged by file I/O, but    
   > simply won't be accessible by generic CP/M. Placing the CCP as 31:ccp.sys    
   > (lowercase) was commonplace among OEM implementations.    
      
   I found the 31:cp/m.sys and 31:cp/am.sys files on some of the disks from   
   Asimov.  They have allocation block numbers >= 128, on a disk that only has   
   128 blocks.  For reasons I can't recall, CiderPress displays them and actually   
   mods the block number, so    
   the file is readable.   
      
   What purpose does this entry serve?  That wasn't clear to me.   
      
   cpm.fsck from cpmtools flags the extent as erroneous ("bad status") and offers   
   to clear the entry.   
      
   > It would be helpful to provide a 'move' function to change user area for all    
   > extents of a given file or set of files.   
   [...]   
   > I would vote for always including the user prefix when listing a directory    
   > while inferring '0' when none is provided.   
      
   My current inclination is to go with the "it's part of the filename" approach,   
   rather than trying to create virtual directories.  However, this can't use ":"   
   as the delimiter, because that's interpreted as a directory separator by the   
   tools (thanks to    
   HFS), which is why I was contemplating ',' instead.  Assuming user 0 when none   
   is specified is part of the various plans.   
      
   The cp2 command-line tool accepts wildcards, so with the "virtual directory"   
   approach, moving files between user areas is equivalent to moving files   
   between directories.  Something similar could be done for the fi   
   ename-modification approach with a bit    
   of trickery in the command-line tool, but you couldn't drag&drop in the GUI   
   tool because there'd be nowhere to drop into.   
      
   > I'd strongly suggest taking a look at cpmtools for ideas and concepts about    
   > mapping between CP/M and current filesystems.   
      
   I have been; the documentation is a little thin (except for the CP/M   
   filesystem description in section 5, which is wonderful).   
      
   It could also use a diskdefs entry for Apple II 3.5" disks.  This worked with   
   the (one and only) disk image I found:   
      
   # Apple II CP/AM on an 800KB 3.5" disk   
   diskdef apple-800   
     seclen 512   
     tracks 100   
     sectrk 16   
     blocksize 2048   
     maxdir 256   
     boottrk 2   
     os 2.2   
   end   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)