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