home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.sys.apple2      Discussion about Apple II micros      56,720 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 55,561 of 56,720   
   fadden to Kent Dickey   
   Re: RamFAST Rev C with Apple IIe   
   26 Jun 22 07:53:56   
   
   From: thefadden@gmail.com   
      
   On Saturday, June 25, 2022 at 9:13:43 PM UTC-7, Kent Dickey wrote:   
   > In my opinion, that technote is a bit unclear on how this should work.    
      
   It was written from the perspective of explaining the fields whose value   
   changed meaning.  It was not explicit about the fields that didn't change, but   
   I suppose if you're writing the technote as a sort of "diff" it might not feel   
   necessary to do so.  It    
   would have been useful for them to call this out.   
      
   ProDOS 8 documentation is generally pretty vague about the directory header   
   area, e.g. it tells you that directory headers store a redundant copy of the   
   subdirectory name, access flags, and creation date, but doesn't mention that   
   the latter two aren't    
   updated when you call SetFileInfo.  My guess is the lower-case flags would   
   fall into the same "redundant but not updated" category, and somebody figured   
   that if you weren't going to update them then you might as well not write them   
   in the first place.   
      
   > I guess you've looked at GS/OS images, and subdirectory headers should not    
   > change: $1c,$1d should be VERSION and MIN_VERSION, and there are no    
   > lower_case flags, right (they DO NOT move to $16,$17 like the volume header)?   
      
   Correct.  Also, ProDOS 8 puts various values in VERSION and leaves MIN_VERSION   
   zero.   
      
      
   On a totally unrelated note, ProDOS 8 tech note #30 reveals something   
   interesting.  It suggests the following P8 BASIC.System command for creating a   
   massively sparse file:   
      
     BSAVE SPARSE.FILE,A$300,L$1,B$FFFFFF   
      
   Of course, if you write 1 byte to $ffffff, you create a file whose EOF should   
   be $1000000, which is impossible.  However, the write succeeds and you can   
   even read it back, because it's actually storing the last byte at the end of   
   the block.  The GS/OS    
   FST doesn't seem to allow this.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca