[fa.info-cpm] M-drive etc.

ARPAVAX:C70:info-cpm (10/14/82)

>From POURNE@Mit-Mc Thu Oct 14 01:40:03 1982
There are at least two "pseudodisk" systems.  Both work.
Semi-disk works with any s-100 system (and also with trash-80
mod 3 and IBM pc) and any controller (using cpm-2.x).  The
Godbout M-drive or Warp Drive works only if you have a DMA disc
controller, preferably Godbout CompuPro Disk One, AND the
CompuPro 8085/8088 dual processor board.

The Semi-disk is dedicated memory; it is ONLY the "N=Drive"
(ours is tagged as drive 'N').  The Compupro Warp Drive (we have
named it Drive 'M' in our system) consists of ordinary memory
addressed properly plus a program to let you access it in the
right way.  It costs more than semi-disk but you can use the
momory when you use the 8088 (or go to an 8086 or whatever) as
ordinary memory; something you can't do with the N-drive
semi-disk.  Semi-disk is cheaper, and you can get more of it--up
to a megabyte.  We have 500K N-drive and about 256K M drive and
we like both.  They're fast and if you do  much assembly or
compiling you'll LOVE them...

See my BYTE peices for more details.

ARPAVAX:C70:info-cpm (10/15/82)

>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