Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!unf7!tlvx!sysop From: sysop@tlvx.UUCP (SysOp) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Summary: "virtual" memory? Weeeel, how about this idea.... Message-ID: <409@tlvx.UUCP> Date: 3 Oct 90 04:04:12 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <1088@ucsvc.ucs.unimelb.edu.au> Organization: Temporal Vortex BBS of Jacksonville, Florida Lines: 102 In article <1088@ucsvc.ucs.unimelb.edu.au>, U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes: > G'day, .... > > you couldn't have that on every Amiga. It should be possible to write a > > swapping library that any application could easily use to swap data between > > a disk file and a memory buffer. It would be silly to have to create such a > > mechanism more than once on the Amiga. > > Yes all MMU Amiga users want true virtual memory :-) and I was hoping that some > one would suggest that the effort of writing a swapping system (library) should > be done once only (thanks Dave). > > Non MMU Amiga owners of which there are a few :-) may not see the benefits of a > virtual memory system in any future OS upgrades. Amiga owners who are limited Ok, here's an idea for those of us without an MMU. OK, some of you might call it a kludge, but basically, it's not my idea, so I won't take blame for it. ;-) There's a library of routines for use on the clones that will allocate memory from EMS, Extended, or disk, depending on what's available. It will copy data in from the storage into a buffer. Your routines must go through the library functions, which determine where the data is stored, and then load it into a buffer. Your routines get a pointer to this temporary buffer. This pointer is basically invalid upon subsequent calls. On the Amiga, this type of system could be used, but you would only allocate from real memory, or if memory was low, from disk. It really isn't that hard. It's sort of annoying having to do a double-dereference, but if you know pointers anyway, it's not hard either. The advantage is that you don't need anything fancy, it'll work on anything. (You could even swap to floppy.) And, it's very easy to write such a library. You would think it'd be slow, but using a particular library in my experience, it worked quite well. It does the job when "real" VM isn't possible. .... > Those multitasking fans of us out there {:-)} that have come too close too GURU > time because a download used up too much memory while we were editing a file at > the same time as ... {familiar problem anyone :-)}. I sorta wonder, how would you know at what point to start swapping? I guess you could leave it a user-defined option (like, 50K, or 100K). My guess is you don't really know how low you can go, and you don't want to take it all, or horrible nasty things happen. (I hate filling up a RAM disk, and then trying to delete things, but not having enough RAM to run the particular delete program I'm using... :-) Luckily, this has only happened to me once.) .... > My stock A1000 with 414K usable { ugh, WB 1.3.2, Shell, Pop-some-thing-or-other > is necessary, make that 300K usable :-) } helps me to appreciate these things. > > :-) Yeah, people say I'm crazy, but I bought a 2 meg expansion for my A1000, and to this day, still haven't gotten a 2nd floppy drive. Hey, it works for me. :-) I can always use the memory as a disk substitute, but can I use the disk as memory? Not really. (I could still use a hard drive, VM or no. :-) > .... > PS: perhaps the question of technical merit is whether there are any other ways > for Amiga 500 & 2000 owners of the future that will not have MMUs & virtual > memory capability to process data when allocatable memory is too low ? (This prompted me to reply....) > As Dave points out the work should only be done once ... But actually, I'm talking about something different (although in a way, it may appear to be the same to the user), but this is "a way... to process data when allocatable memory is too low." This could be a library that gets linked in, easily enough, but that would end up as a copy bound into each executable. However, the code to do this sort of thing would not amount to much. It's not "real" VM, but it can solve some basic problems. It cannot be used for code, only data, and only groups of data, no larger than your temporary "swap" space. This idea can't really be applied to just any program (such as by some how placing routines inbetween the application and the OS), since you're working out of a limited buffer, and the application's programmer must realize that the pointer will be invalidated once other memory areas are overlayed. So, you can't use this method with your favorite program, unless you have the source for it, and are able to modify it. .... > yours truly, > Lou Cavallo. (You know, this strikes me as similar to my previous post about using the 24 bit standard file to transfer between programs and display cards... but that's another story, but I still don't see why not, in the absence of a proper standard..... :-) So, I'm bracing myself for comments about this not being a good idea.. :-) I'm not suggesting this method as a replacement for VM, but as one alternative that could be useful for some people who need this capability. (Hopefully someone will find something of interest here.... :-) -- Gary Wolfe, SYSOP of the Temporal Vortex BBS // Amiga! ..uflorida!unf7!tlvx!sysop, ..unf7!tlvx!sysop@bikini.cis.ufl.edu \X/ Yeah!