Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!kuhub.cc.ukans.edu!markv From: markv@kuhub.cc.ukans.edu Newsgroups: comp.sys.amiga.programmer Subject: Re: ramdrive repacking Message-ID: <29016.27db65c2@kuhub.cc.ukans.edu> Date: 11 Mar 91 17:10:58 GMT References: <88002@tut.cis.ohio-state.edu> <19286@cbmvax.commodore.com> <88966@tut.cis.ohio-state.edu> Organization: University of Kansas Academic Computing Services Lines: 54 In article <88966@tut.cis.ohio-state.edu>, meranda@frankenstein.cis.ohio-state.edu (deron meranda) writes: > In article <19286@cbmvax.commodore.com> > darren@cbmvax.commodore.com (Darren Greenwald) writes: >>In article <88002@tut.cis.ohio-state.edu> > writes: >>>... > Now, that one block used by the ramdrive is cutting that big free > memory block in half! And YES -- This does happen often to me. Yes, this is a common problem. One way I've found that works is (if you have the RAM), copy the RAM disk into its own sub-dir, delete the old files and rename the files back to the root. This works to an extent assuming you have to big RAM. It should be noted that the 2.0 RAM: "packs" small files by putting multiple files smaller than 512 bytes into one block, so that really small files (like ENV: files) dont gobble up lots of RAM. > What I would like, is upon recognizing that condition, is to execute > (perhaps manually) a program which attempts to move that lone block > into some smaller free memory chunk. It would be perfectly acceptable > to sacrifice system performance while that moving is being done. > Note, that the ramdrive is still technically just as fragmented - > but the "free memory" is not as fragmented. I'm working on a replacement AllocMem() that can be configured to behave differently depending on the task that calls it. My original goal was to have RAM-Handler and RAMB0 allocations come out of the slowest non-CHIP memory (such as 16 bit Fast memory on a mixed RAM 2000 that has 32 bit memory), but I could exetend it to "secretly" allocate bigger chunks of RAM an parcel those as as needed (kind of like malloc()) to a particular task. > Does this clear up what I meant? I seems to me that this should be > very possible without too many difficulties -- if one has some > insights into the ramdrive formats itself. Can anyone help or > comment on this idea? Most of this stuff is internal to the RAM-Handler. There is no documentation to its internals. All it has to do is respond properly to DOS packets send to its process. > Thanks in advance. > > Deron E. Meranda ( meranda@cis.ohio-state.edu ) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~