GP32 Gp32 Memory Available To Programs...

[Squidge]

Does anyone know if different amounts of free memory to programs is available under different bios's? I know it shouldn't make a difference, but I'm just curious.

Below is an available memory graph for MultiFW2/PacRom for a 100Kb GXB (malloc through gp32 SDK, using the "test" DKA application as a template)

To do one for a different BIOS, simply create a program that does nothing but allocate memory, and when it fails, output the number of succesful allocations. Do this for each block size between 1mb and 1kb, as shown above, and then map it.

 

[loki666]

dont know but i think all bios use the same system ram area which is 0x0C79C000 to 0x0C7FFFFF (but not for sure)

edit: btw, if we achieve to runs rtems on the gp32 maybe we could gain some free space, but not sure (rtems eat a few ram for object handling ofcourse)

 

[Robster]

Heh... I can't see the point of doing this, but I like its style

Anyway, I enjoy the odd pointless pursuit, so I "reverse-engineered" the results and found that I can replicate Squidge's results if initial heap size is 7585kB and the malloc overhead per allocation is 16 bytes (which is pretty standard).

Now, as loki666 says, system ram starts at 0x0C79C000, which leaves 7792kB for program and heap. With 7585kB on the heap, it means the program took up 207kB. Which is interesting, as Squidge said the gxb was 100kB. Where did the extra 100kB go, Squidge? Does the program have lots of static arrays and stuff?

 

[Squidge]

Well, here's the program in full...

#include <gp32\gpstdlib.h>
#include <gp32\gpmem.h>
#include "defines.h"
#include "gpgraphic.h"
#include "gpfont.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdarg.h>

/* Converts 8bit rgb values to a GP32 palette value */
#define GP_RGB24(r,g,b) (((((r>>3))&0x1f)<<11)|((((g>>3))&0x1f)<<6)|((((b>>3))&0x1f)<<1))

/* Global variables */
GPDRAWSURFACE gpDraw[2];

/* Sets a single GP32 palette entry */
void GpSetPaletteEntry ( u8 i, u8 r, u8 g, u8 b )
  {
    GP_PALETTEENTRY entry = GP_RGB24(r,g,b);
    GpPaletteEntryChange ( i, 1, &entry, 0 );
  }

void GpMain (void * arg)
  {
    int * t;
    unsigned long memalloced;
	char str[256];

    /* Initialize graphics */
    GpGraphicModeSet(8, t);
    GpLcdSurfaceGet(&gpDraw[0], 0);
    GpLcdSurfaceGet(&gpDraw[1], 1);
    GpSurfaceSet(&gpDraw[0]);
    GpLcdEnable();

    GpSurfaceFlip(&gpDraw[0]);
    GpSetPaletteEntry ( 0, 0,0,0 );
    GpSetPaletteEntry ( 1, 255,0,0 );
    GpSetPaletteEntry ( 2, 255,255,255 );

#define TO_MALLOC (1)

	sprintf (str, "Allocing in %dKb chunks", TO_MALLOC);
    GpTextOut(NULL, &gpDraw[0], 0, 0, str, 1);
	memalloced = 0;
	while (malloc(TO_MALLOC*1024)!=0)
	{
  memalloced += TO_MALLOC * 1024;
	}
	
	sprintf (str, "Managed %dKb before failure.", memalloced / 1024);
	GpTextOut(NULL, &gpDraw[0], 0, 30, str, 1);

    while(1);
  }

As you can see, it's very small, and GCC manages to compile to a 100kb GXB.

Now, since this is using the standard SDK, does this mean the SDK is using up 100kb for it's end of the deal, or that 100kb is reserved by the BIOS for internal housekeeping, that it doesn't bother to free when executing your program, despite the fact that it'll never return there? This is what I'm interested in - if we tried the same thing under the old GP bios and the new European bios, would we get different results?

After all, 100kb could be the difference of an emulator/port working or not.

 

[Robster]

hmmm... you've got me kind of interested now, which is frustrating because I'm at work and can't look at any of this myself

gcc is just linking the sdk libraries, they are what takes up most of the gxb size. I can't see where the 100k is allocated, but I don't think it will depend on the bios.

One thing you could check is where those LCD buffers are:

sprintf (str, "gpDraw[0] buffer is at %08X", gpDraw[0].pt_buffer);
   GpTextOut(NULL, &gpDraw[0], 0, 60, str, 1);
(str, "gpDraw[1] buffer is at %08X", gpDraw[1].pt_buffer);
   GpTextOut(NULL, &gpDraw[0], 0, 90, str, 1);

Also, if you do just one allocation (of any size) and print its address, you'll find where the heap starts. Or you could just look at the map file. Damn being stuck at work!

 

[Squidge]

I need sleep, but before I go, here's some results. I'll figure them out in the morning, as my brains in economy mode at the mo'

gpDraw[0] @ 0xC7B4000
gpDraw[1] @ 0xC7C6DF0

First malloc @ 0xC0334C8
Last succesful malloc @ 0xC795248

 

[mr.spiv]

dont know but i think all bios use the same system ram area which is 0x0C79C000 to 0x0C7FFFFF (but not for sure)

Erm.. don't depend on hardcoded values but use the BIOS SWIs to get the end of available RAM. For example in all those numerous 32M modded GP32s the end of available RAM is much lower due additional MMU tables.. :blink:

 

[DaveC]

....As you can see, it's very small, and GCC manages to compile to a 100kb GXB.

Now, since this is using the standard SDK, does this mean the SDK is using up 100kb for it's end of the deal, or that 100kb is reserved by the BIOS for internal housekeeping, that it doesn't bother to free when executing your program, despite the fact that it'll never return there? This is what I'm interested in - if we tried the same thing under the old GP bios and the new European bios, would we get different results?

After all, 100kb could be the difference of an emulator/port working or not.

I don't know about all of this programming jargon, but I do know that there are a few things that will not work on my system and I have been told that it is "European FW" I don't know which version though. Squidges own BOR beta 4 just resets my system when I select a .pak to play. But BOR beta 3 seems to work. The Giana sisters won't work either. So there must be some kind of memory problem or something.