Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!mailrus!iuvax!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: PKZip Amiga arrives
Message-ID: <9693@cbmvax.commodore.com>
Date: 15 Feb 90 16:54:32 GMT
References: <9744@baldrick.udel.EDU>
Reply-To: daveh@cbmvax.cbm.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 30

In article <9744@baldrick.udel.EDU> C503719@umcvmb.missouri.edu (Baird McIntosh) writes:
>In article <1990Jan26.165551.7614@iesd.auc.dk>, dorf@iesd.auc.dk (Thomas Dorf
>Nielson) asks:
>>Is there anyone who knows, whether DiskSalv requires 1Meg?

>DiskSalv 1.4 (latest version I have) has a LOMEM option that minimizes
>memory used... I don't know if it works in 512k since I have a 2000
>(1 meg), but I would think it does work in LO MEMory. :-)

The latest DiskSalv (V1.42) will recover from floppy to floppy on a 512K machine,
no problem.  The program itself is written with special attention to stack
usage, so it should be happy as a clam with the default 4K of stack space.

However, the amount of memory needed by DiskSalv is far more dependent on the
disk you're recovering than on DiskSalv itself.  The LOMEM option helps to
minimize the amount of fixed overhead DiskSalv will use for any given operation.
The program needs, dynamically, 8 bytes per file and (I think) 52 bytes per
directory entry for normal operation, plus 2 bits per disk block for normal,
1 bit per disk block for LOMEM recovery.  For very full/large recoveries on
systems with only a small amount of memory, using the FILE or START/STOP 
options can limit the scanner to only a portion of the disk, allowing one to
recover that disk in pieces.

> /  Baird McIntosh (2nd yr CS/Math major, University of Missouri-Columbia)


-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough