From: utzoo!decvax!ucbvax!ARPAVAX:C70:info-cpm
Newsgroups: fa.info-cpm
Title: Re: M-drive etc.
Article-I.D.: ucb.2147
Posted: Thu Oct 14 23:19:51 1982
Received: Sun Oct 24 00:39:03 1982

>From mwm@Okc-Unix Thu Oct 14 23:19:39 1982
I'd like to make a comment on the general topic of disks that live in memory.
I think there is a better alternative: caching.

Instead of using that 256K for a disk, fix the bios to do track read/writes
into it, and then go there when you need something from that track. This
will give you about 40 tracks (15 512 byte sectors) resident in memory (at
least the version I run does) at any one time. You get the following
advantages:

	1) not having to shuffle the files to/from memory to get the speed.
	2) the things you use, as opposed to the things you think you'll use,
		wind up in memory.
	3) it's MUCH easier to get the stuff out to disk (I just ^C).

For example, with my system (320K cache, 4 Mhz z80), the result are nice. On
my current project (~750 lines of BDS C), the system only goes to the disk
for tools: mince and it's swap file, the compiler, and the linker. Other than
that, everything is resident in the cache.  This results in better performance
than a hard disk, even though I have the thing configured to verify after
every read/write, and to flush all the dirty buffers to disk on warm boot.
If I were really worried about speed, instead of reliability, I'd turn all
that off, and pick up 3 times the speed in I/O, plus an extra track buffer,
plus NO (well, most of the time) I/O on warm boot.

Of course, it's not all great - it isn't as fast as a memory disk, and
you don't get the extra 256K of online storage. But I like the increase
in safety.

As for getting it up - I've never looked at FAST (for obvious reasons), but
I seem to remember that it does the same kind of trick in the first bank.
If so, this could be modified (fairly easily, I hope) to cache to an extra
memory board (or two...)

	mike