Bill.Frandsen@samba.acs.unc.edu (BBS Account) (07/03/90)
I remember that a few months ago, someone posted a problem with DiskSalv1.42 using it on a 1Meg (Super) Agnes chip machine. I too, am having simialar problems. When I ran version 1.42 on my 512K chip/512k fast(semi-fast) A500, I did not run into any errors. However, in March, when I upgraded to my new A2000, I cannot run DiskSalv without running into an "Out Of Memory" error. Even if the disks have deleted files, the system usually runs out of memory while reading the disk structure. This is even with the LOMEM option on! And when it is run on a disk which contains a hard-sector error, each time it grinds to read the sector, it eats gobs of memory away! (I.e. at least 16K!) Although I am getting my Supra RAM 2000/2M board this week, I would like to know what am I doing wrong, or is there really a bug in this version of the program? Any ideas, Dave? Other than that, I do LOVE the program, and hope that the "teaser.pic" you included with the archive is now a reality in Workbench 2.0! --Thanks Dave! If anyone has ways around this problem, I would like to hear them. My e-mail address: "Bill.Frandsen@bbs.acs.unc.edu" ^^^ its a new one, hope it works! :)
daveh@cbmvax.commodore.com (Dave Haynie) (07/04/90)
In article <476@beguine.UUCP> Bill.Frandsen@samba.acs.unc.edu (BBS Account) writes: >I too, am having simialar problems. When I ran version 1.42 on my 512K >chip/512k fast(semi-fast) A500, I did not run into any errors. However, >in March, when I upgraded to my new A2000, I cannot run DiskSalv without >running into an "Out Of Memory" error. I don't know of any real run-time problem for V1.42. The V1.40 version of DiskSalv had a memory allocation bug which would occasionally have it claiming to be out of memory when it actually wasn't. DiskSalv V1.42 has a bug in the cleanup routine that will sometimes force an endless "out of memory" display loop. Basically, the error routine wants to allocate memory that's not available, thus calling the error routine, which wants memory, etc. This is annoying, but you would expect the program to fail anyway, this just make it an ugly failure. >Even if the disks have deleted files, the system usually runs out of memory >while reading the disk structure. This is even with the LOMEM option on! Where's your output disk? On a 1 Meg machine, it's just about impossible to recover any reasonably fully floppy to RAM:, but I've never had a problem going from floppy to floppy on a bare-bones system (my usual "bare bones" system is a 1 meg A1000). >And when it is run on a disk which contains a hard-sector error, each time it >grinds to read the sector, it eats gobs of memory away! (I.e. at least 16K!) I'll check that one. It does, indeed, grab a big chunk of memory, since DiskSalv reads in the raw track information in this case, to do it's own decoding of the Amiga's MFM format. If multiple 16K chunks are being allocated, that's certainly a bug. You can switch off the low-level trackdisk processing with the NOTD flag. >Although I am getting my Supra RAM 2000/2M board this week, I would like >to know what am I doing wrong, or is there really a bug in this version >of the program? Any ideas, Dave? I'll check into the freeing of the track buffer when I get a chance. While I've been too busy to get much further with DS 2.0, I'm certainly going to fix any major bugs I find in 1.42 before 2.0 is released. >Other than that, I do LOVE the program, and hope that the "teaser.pic" you >included with the archive is now a reality in Workbench 2.0! I started on that graphic design after learning a little about Intuition and playing with the NeXT machine. It was nice for Commodore to do the same in 2.0, it should make writing DiskSalv 3.0 much easier... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM