Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!mit-eddie!ll-xn!ames!ptsfa!well!perry
From: perry@well.UUCP (Perry S. Kivolowitz)
Newsgroups: comp.sys.amiga
Subject: Re: Disk cache
Message-ID: <3199@well.UUCP>
Date: Mon, 1-Jun-87 12:46:30 EDT
Article-I.D.: well.3199
Posted: Mon Jun  1 12:46:30 1987
Date-Received: Wed, 3-Jun-87 02:03:47 EDT
References: <333@rocky.STANFORD.EDU>
Lines: 37

In article <333@rocky.STANFORD.EDU>, rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes:
> Now that my hard disk is gone and I'm back to floppies, I've decided
> I need a disk cache.  A good one.  One with the following features:
> 
> 	- Uses *available memory* exclusively, from the end of the
> 		free list to the front
> 	- Intercepts AllocMem to invalidate some cache buffers
> 	- Is public domain
> 	- Is *fast*
> 	- Is write through
> 	- Works with multiple drives; invalidate on eject
> 
> Perhaps I am wrong, but I estimate a few days should be all it takes.
> I can handle everything off the top of my head but the intercept of
> the trackdisk.device calls, which I've never done before.  Perhaps
> someone would like to help me with this?
> 
> I know about Perry's facc, but does that use free memory, or is it
> like vd0: in requiring a certain amount of memory be put aside?
> 

Tomas,
	Facc does fit your requirements and is available. Forty dealers
picked it up at Comdex, and several distributors as well. 

Here's some interesting news: Diskperf shows df1: (with Facc) to be
the fastest drive available anywhere - at 137,000 bytes per second.

I've made a list of things I want to add to facc and will do so. Anyone
owning Facc simply send inthe original disk with a stamped self addressed
envelope and get the lastest version (for ever).

Oh, you should definitely NOT patch allocmem to discard buffers during tight
times. There are plenty of other ways that are more compatible and more
portable.

Perry