Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!hao!gatech!ulysses!hector!eric
From: eric@hector.UUCP (Eric Lavitsky)
Newsgroups: comp.sys.amiga
Subject: Re: VDK:
Message-ID: <10125@ulysses.homer.nj.att.com>
Date: 2 Mar 88 18:11:45 GMT
References: <8802262108.AA01299@jade.berkeley.edu>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: eric@hector (Eric Lavitsky)
Organization: AT&T Bell Labs, Murray Hill
Lines: 62

In article <8802262108.AA01299@jade.berkeley.edu> CRONEJP@UREGINA1.BITNET.UUCP writes:
>Where do i get it.....
>
>give me a phone number of a BBS that has it , or send me
> uuencoded ARC of it....
>I have VD0: but i've heard that VDK: is better, still shareware,
>and grows and contracts as files go into it....
>
>am i correct???

Better is a relative term...

VD0: grows and shrinks as you use it - it's memory management scheme looks
like this:

	Mount VD0: (say make it 2Meg)
		- Ok - the device set's up it's magic at the top end of
		memory. It allocates a small portion of memory up there,
		sort of it's root block and a little more. The size
		specified in the Mountlist simply determines what the
		*maximum* size of this VD0: can be. It does not allocate
		everything at once.
	Copy something into VD0:
		- Ok - the device will start allocating memory for the
		file blocks from the top end of memory down. Remember,
		any memory not being used by VD0: can be used for other
		applications. VD0: does everything possible to maintain
		it's memory allocation in a contiguous fashion from the
		top down. If some other application resides at the bottom
		of the current VD0: position, and VD0: needs more memory, 
		it will allocate around that application. Note, however,
		that every so often, VD0: will check to see if that memory
		space has been freed and if so, will relocate it's data
		so as to keep itself contiguous. If there is no more free
		memory available, VD0: will return a read/write error.
	Delete something from VD0:
		- Ok, the device marks these blocks as deleted. Now, every
		200 or so accesses to VD0:, the device will free up the
		memory used by deleted blocks to the rest of the system.
		If you want to force this action, Perry provides the
		utility "CleanRamDisk" to do it (every 200 accesses really
		means every 200 references to data in VD0:, which is not
		too difficult to achieve in a short period of time).

Now, VDK: works much like the original RAM: disk - and is a handler much
like the original RAM: disk. It does not do any sophisticated memory
management, and will fragment memory to it's hearts content. It is much
faster than VD0:, because that is the nature of a handler over a device.
I believe VDK: is a commercial product available for $10 from Pacific
Peripherals.

Now, you make the decision which tradeoff you would rather have ...

>Jonathan P. Crone
>Vice President, AURA,  (Amiga Users of Regina Associated.)
>(Regina, Sask. Canada )    (eh???)

Eric

ARPA:	eric@topaz.rutgers.edu		 "Lithium is no longer available
UUCP:	...{wherever!}ulysses!eric	  on credit..."
	...{wherever!}rutgers!topaz!eric		- from Buckaroo Banzai
SNAIL:	34 Maplehurst Ln, Piscataway, NJ 08854