Memory question

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.

Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • I am wondering: Is it normal that P96 «takes» fastmem equivalent to the resolution which you set in screenmode ? For instance: If I set 1024x768x8bit i notice that suddenly 700KB is gone from my available fastmem. If I set for instance 1250x720x8bit it eats up 900KB.

    Is this P96 just grabbing a framebuffer-size to enable double buffering or other calculations ?

    Can it be related to screen-dragging which now is available in P96 ?

    (I am using latest P96 version for this test)


  • The memory management attempts to use as much memory on the GFX card as possible - especially the last update improved on that, specifically to increase local blitter usage. However, fastmem is taken as buffer for other screens. And since you're using a Chameleon, all memory is in a single chip, so no matter what kind of mem you use, it will be located there. Not sure how Alastair handles this, but my guess is that he's using a simple, rather small frame buffer, barely enough to hold the picture, and make the rest available as fastmem. So what you're seeing may actually be both, the GFX card implementation or P96.

  • Thanks for the reply. Yep, I am using a TC and Alastair's minimig-rtg driver is setup to allocate 1MB (new setting in tooltype to define "onboard" RTG ram). So when I load the driver in AmigaOS it allocated that 1MB. But as soon as I change from PAL to any RTG mode, it takes 0,7MB from my fastmem when I use a screenmode of 1024x768x8bit so I was wondering: Why does also allocate another 0,7MB from fastmem and not use that already allocated 1MB in the rtg-driver ? Are you saying that these 0,7MB is the "buffer" which is taken by P96 ?

  • Hi Jens. Just wondering about my question above from aug18. Is it correct that by changing to a p96 rtg screenmode, the driver allocatea an equal portion from fastmem to allocate as buffer (e.g. For when using screen dragging) ? I am in this example asking on a generic basis for instance a4000 with a picasso4 gfx card (not askin in a TC minimig rtg context). Because if it is so, that the rtg driver allocates a buffer from fastmem, I understand. If it does not allocate it, I think there might be a bug 😅 Just trying to find a answer as to why my fastmem goes down when I enable a rtg mode under prefs/screenmode.


  • I've relayed the question to Thomas, as I'm not able to read that from the sources. Remember that I'm not a programmer, I'm just the hardware guy. I only write code :-)

    Got a very fast answer: Fastmem is allocated to have space for VGA memory migration. THis has nothing to do with screen dragging, and it's not a new behaviour, but has always been handled like this: If GFX card memory gets scarce, unused screens are migrated to fastmem in order to have space for a new screen to be opened. This hides memory limitations of GFX cards, as it lets you open more screens than physically fit in the gfx card's memory. Might look like a waste especially on a Chameleon, but with the large amount of memory available these days, I don't see a need to change this.

  • Hi Jens. Keep up the great hardware-work :)

    Thanks for the clarification on the memory question. Now I know that it is a correct behaviour that it allocates a chunk of my fastmem when I choose the RTG mode under screenmode. Great to know the reason behind the behaviour. Thankx!!!

  • As I found out this weekend, it's also the reason why a 4MB version of the Picasso2 doesn't make sense for many systems, as the gfx memory used will be equal to fastmem usage, and that is limited to 4MB in a Z2/24-bit system. Just some almost-useless added info...