Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site picuxa.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxp!picuxa!jik
From: jik@picuxa.UUCP (Jonathan Klein)
Newsgroups: net.micro.amiga
Subject: ASDG recoverable ramdisk (review of same)
Message-ID: <167@picuxa.UUCP>
Date: Thu, 11-Sep-86 15:05:48 EDT
Article-I.D.: picuxa.167
Posted: Thu Sep 11 15:05:48 1986
Date-Received: Fri, 12-Sep-86 07:34:38 EDT
Distribution: net
Organization: AT&T Information Systems, Parsippany N.J.
Lines: 72


Hi,
	This is my first posting to net.micro.amiga and would like to
say that I've gotten a lot out of the discussions here. Now I'd like
to contribute something myself.

	I've been using an ASDG Mini-Rack-B for a week now along with
their "2M", a 2 megabyte ram card. I've been really happy with it but
they just sent me something I'm REALLY happy about.

	They sent me a disk containing a thing called vdisk.device. 
They said it was an alternative to ram: that is completely compatible
with DOS whereas ram: is mostly compatible. Also, it's not destroyed
by machine reset or system crash.

	The installation guide gave me a devs/mountlist entry (I'm using
1.2) and said by changing the number of tracks (editing one line) I can
set any maximum ram disk size I want (up to 2 mega bytes). They said that
later they will come out with an Intuition utility which means I won't
have to edit devs/mountlist to change the maximum ram disk size.

	So I inserted their mountlist entry into devs/mountlist and set
it for 1.4 megabytes of ram disk. Next, they say to put:

	mount vd0:

into the s:startup-sequence as the first line. And then reboot. So I did
and...

	Info said I had an 880k df0 and df1. And a 1.4M VD0!!! 
	AND avail said I still had 2 million some odd bytes of fast
ram left!!! (from this I can tell that they fool AmigaDos into thinking
that there's an N megabyte disk out there but actually allocate the
track buffers only when needed.

	I took there suggestion of creating a script called fill-vd0.
They said that should vd0: need recreation I just execute the script
and I'm back on the air.

	They said that the ram disk will need recreation if:

	1. I power down.
	2. I change the max size of the ram disk.
	3. The ram disk is "violated" during a crash. They said they
	   keep checksums of every track and can tell if one's been
	   overwritten.

I put a "path vd0: add" into my startup-sequence and for three days and
many many reboots I haven't reloaded vd0: ONCE!

	I got curious how they did it and I wondered if there allocation
scheme (allocate on demand) would fragment ram the way the ram: device does.
I wrote a program to dump the memory lists and found ZERO fragmentation due
to vd0:!!!! NONE! - It seems to grow the disk from the top of memory downwards
so it definitely doesn't use AllocMem to get memory. I figure fragmentation
due to vd0: will NOT happen unless I completely fill up fast ram and then
allocate another track.

	These guys did a great job on their software. Period.

	Their hardware is great too. I bought the mini-rack-b (a two
slot 100 pin zorro box) for $150. And the 2M ram card for $750. And yes,
it has NO wait states.


Sincerely,

Jonathan Klein
-------------------------------

I am not associated with ASDG in anyway except I bought their stuff
and love it.