🚀 go-pugleaf

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!