Re: RamFAST & GS/OS cache

[David.Empson@bbs.actrix.gen.nz]

In article <fmlin.2bnm@terapin.com> fmlin@terapin.com (Frank M. Lin) writes:
> Todd writes:
> >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.

Er, what?

Maintaining the cache is the device driver's responsibility, not the FST's.

If an FST wants to read a directory, it calls the device driver to
read the required blocks.  The driver checks to see if the blocks are
already in the cache, and if so, copies them out into the buffer
supplied by the FST.  If they aren't in the cache, the driver reads
them into the cache and copies them into the FST's buffer.

What are you suggesting as an enhancement?  That the in-memory copying
be avoided by having the FST refer directly to the data in the cache?


When reading data blocks, the FST asks the driver to copy data directly
to the application's buffer space.  If caching has been disabled (as
it usually is for data blocks), the driver will read directly from the
device into the application's buffer.
-- 
David Empson

Internet: David.Empson@bbs.actrix.gen.nz    EMPSON_D@kosmos.wcc.govt.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand