home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / apple2 / 24328 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  1.4 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!toddpw
  2. From: toddpw@cco.caltech.edu (Todd P. Whitesel)
  3. Newsgroups: comp.sys.apple2
  4. Subject: Re: RamFAST & GS/OS cache
  5. Date: 22 Nov 1992 00:55:13 GMT
  6. Organization: California Institute of Technology, Pasadena
  7. Lines: 19
  8. Message-ID: <1emlphINNrg8@gap.caltech.edu>
  9. References: <fmlin.2ami@terapin.com> <By39x5.7Jv@news.iastate.edu>
  10. NNTP-Posting-Host: punisher.caltech.edu
  11.  
  12. hal@budapest.math.macalstr.edu (Harold Byron Bouma) writes:
  13.  
  14. >> I am going to bug Drew to support GS/OS cache :)
  15.  
  16. >    Good, you should. Its much better caching and the GS will improve from  
  17. >it. Even the Turbo IDE card does it as well.
  18.  
  19. Drew's position on this is that the method the RamFast currently uses is faster
  20. than it would be if he supported GS/OS caching. This is because the GS/OS cache
  21. has to (a) find the block by searching a list, and (b) manually move the block
  22. to the caller. So for data blocks the GS/OS cache is generally going to be
  23. slower than the RamFast unless you have a very fast Zip. But for directory
  24. blocks, the GS/OS cache makes a lot of sense _IF_ the FST's are smart enough
  25. to directly search for them in the cache rather than calling the driver and
  26. forcing a manual copy into the FST's own memory (which is also usually going to
  27. be slower than just blasting the block in from the RamFast).
  28.  
  29. Todd Whitesel
  30. toddpw @ cco.caltech.edu
  31.