Path: utzoo!utgpu!water!watmath!egisin
From: egisin@watmath.waterloo.edu (Eric Gisin)
Newsgroups: comp.sys.atari.st
Subject: Re: my ideal cache program
Message-ID: <19712@watmath.waterloo.edu>
Date: 3 Jul 88 17:51:48 GMT
References: <157@cstw01.UUCP>
Organization: U of Waterloo, Ontario
Lines: 44

In article <157@cstw01.UUCP>, meulenbr@cstw01.UUCP writes:
< After seeing a number of cache programs, I decided to scribble down what
< I wanted to see in an ideal cache program.
< 
< How my ideal cache looks:
< - startable from auto folder or accessory which installs itself silently
< - settings (like size) taken from program name or data file
I don't do this in my cache and other resident programs
because I is so trivial to write a small (<1K) program
that reads a file (AUTO.BAT) containing commands of the form
	<command> <arguments>
and Pexec's the commands.  Put this program in \AUTO.
This also avoids the problem of order of execution of AUTO programs.

< - resizable when in operation
If I want to implement this by having a configuration program
(CCONFIG.TTP) pass the request to the resident cache program,
how do I get TOS to arrange that the Malloc'd block are associated
with the resident program, not the configuration program?
How do resizable ram disks do this?

< - selectable whether or not write-through
< - if not write-through:
<   - has an auto "sync" facility, which will flush all written buffers
<   - interval of above facility is user definable
A delayed write-through cache seems like the best idea,
but I don't know how to implement it. A VBL routine could check
whether it was called from user mode and flush dirty sectors then,
but you are rarely in user mode when waiting for input (shell prompt).
Anyone have any other ideas on this?

<   - has a command to flush explicitly
<   - detect media change and warn (insist?!) that the previous floppy is
<     re-inserted when unwritten buffers exist.
< - intelligent replacement algorithm (something like Least Recently Used)
< - (optionally) read ahead (cache the complete track when a sector is
<   requested)
< - perhaps (optionally) always cache FAT and root dir.
Making the FAT permanent is unneccessary with any reasonable replacement routine,
the FAT is referenced constantly by TOS.
< 
< I think this can lead to a safe write-delayed cache.
< Since a number of things can be modified during operation, the cache will
< most likely be implemented as an accessory.