re: RamFAST & GS/OS cache

[fmlin@terapin.com (Frank M. Lin)]

>Drew's position on this is that the method the RamFast currently uses
>is faster than it would be if he supported GS/OS caching. This is
>because the GS/OS cache has to (a) find the block by searching a list,
>and (b) manually move the block to the caller. So for data blocks the
>GS/OS cache is generally going to be slower than the RamFast unless
>you have a very fast Zip.

Hmm, I don't know if I get that.  GS/OS cache in already in memory, I don't see
how reading data from the SCSI device, then copy RF's cache to GS memory will
be faster then just reading/moving the GS/OS cache already in memory.  Besides,
I have a quick TWGS ( 15 ) here :)

>But for directory blocks, the GS/OS cache makes a lot of sense _IF_
>the FST's are smart enough to directly search for them in the cache
>rather than calling the driver and forcing a manual copy into the
>FST's own memory (which is also usually going to be slower than just
>blasting the block in from the RamFast).

This make sense, maybe the Apple II CEG should add this to the 6.0.1
enhancement list.  Since this feauture will improve GS/OS cache is self, and
not just help RF.

Still, I see no reason why Drew shouldn't add GS/OS cache support; unless his
time is needed on other R&D work.

frank m. lin
fmlin@terapin.com