Hi,
> RAM, I was not saying that I was expecting that I would achieve more
> Graphics RAM, I was referring to the idea that, instead of everything
> being loaded into Graphics RAM, until it burst, that some could be off-
> loaded to a disk file and later accessed, as room permitted, or as parts
> of the file were needed, somewhat like layering.
Hm, ok. In principle, what you are talking about *is* virtual ram, as
I'm sure you realise by asking the question. :) Unfortunately, the
chip ram is accessed by DMA hardware as well as the cpu. In order for
VM to work, the cpu has an MMU which effectively "knows" the ram image
is on disk, enabling you to load it before you need it. The DMA
hardware has no such facility so the info has to be there all along.:(
However, for moderate resolution and colour depth, 2 megs is a fair
amount of memory. Much of the data that gets put in chip ram is not
actually required to be there, and it is this that quickly causes the
loss. It's there because the Blitter chip can be used to transfer it
around without the intervention of the cpu. On slower machines this
is fast. On faster machines, the cpu can actually do it faster than
the Blitter. This is why FBlit works. If the software was correctly
programmed enough to indicate that the data was not for direct
display, FBlit will stuff it in fast ram instead. When the Blitter
gets asked to copy it, the system routine is patched and the cpu does
it instead. Its kind of like what you suggest, except the transfer is
from fastram, not disk.
This wont work on everything, but has a good effect on most newer
software. The latest V�'s have been specifically coded with this in
mind. MD2, OS3.5, DOpus, Multiview are all programs which benefit from
this. For eg, with FBlit, after running V� on a 256-col screen,
several MD2 windows open on (DOpus) WB with a backdrop, Genesis
running, I still have over 1Mb chip left. You can also do natty
things like view an image which requires more chipram than you've got
by loading it into Multiview in window mode and scrolling round it.
I do recall, a long while ago, a program (on Aminet?) which tried to
track all memory allocation made by a program and you could manually
swap the whole lot in and out to disk, chipram included. May be worth
looking into, but I recall it was rather unreliable.
Uh, no-one's said it yet, but its only a matter of time before
somebody points out (correctly) that, if you can justify your proposed
purchase, a real gfx card is infinitely better than any other
workaround. :-/
Cheers,
Ian
===
_____________________________________________________________________
Voyager Mailing List - http://v3.vapor.com/
Voyager FAQ....: http://faq.vapor.com/voyager/
Listserver Help: mailto:[EMAIL PROTECTED]?Subject=HELP
Unsubscribe....: mailto:[EMAIL PROTECTED]?Subject=UNSUBSCRIBE
