RAM issue with PRX modules

[carl0sgs]

Hi again!
I'm having some trouble with the project "MultiTasKing", and I need your help.

I have realized that some functions, when used from .prx modules, get too much RAM (sprintf function, printf function).

Other functions, such as the one in the Curl library ported by JoJoSoft, work from the main EBOOT, but crash the PSP when used from a .prx.
This is really strange, cause it crashes even calling a function contained in the main EBOOT, which uses the Curl functions (I mean, not calling those functions directly). The same function works great when called from the main EBOOT :-S

Another problem is that, when removing the PSP_HEAP_SIZE_KB(-5*1024); (which reserves 5MB of the memory for loading PRXs) from the main program, then it freezes (even treating the main eboot as another .prx module -module_start... etc-).

I'm not sure what is the problem, I hope you can help me with this :-)

Thank you very much.

[Raphael]

I have realized that some functions, when used from .prx modules, get too much RAM (sprintf function, printf function).

What do you mean by "get too much RAM"?

Another problem is that, when removing the PSP_HEAP_SIZE_KB(-5*1024); (which reserves 5MB of the memory for loading PRXs) from the main program, then it freezes (even treating the main eboot as another .prx module -module_start... etc-).

When you give the whole heap to your main eboot, then obviously there is no RAM left to load the prxs into (unless a kernel mode prx, but still those won't be able to do any dynamic memory allocation from user space memory).

Regarding your curl problem, I'm not sure what the problem might be, but I see no real reason why curl shouldn't be able to be called from a prx, or at least through the main eboot - if everything is done correctly.
I have no real clue about curl's functionality though, so don't take that as given.

[carl0sgs]

I have realized that some functions, when used from .prx modules, get too much RAM (sprintf function, printf function).

What do you mean by "get too much RAM"?

In my program, you can see the free RAM in the desktop (usually ~5.125mb).
When I load a prx it goes down a little bit.
When the .prx module use one of those functions, then it goes down to 0.273mb or 0.001mb.

(Other function that eats all the ram when used from a .prx is the opendir() from c++ -I used the psp internal directory functions and that was solved-).

I want to make the main program like the other .PRXs, so I don't want to set a heap for it.
The graphic functions are inside the main eboot, so when an image is loaded, it is stored inside the main program's memory (the "heap" we set). This is a barrier, since we need "free" memory for running .PRXs.

(This is difficult to explain, sorry)

I'm sure that there is a function that is not working properly :-S

I did a test with printf (removing all the unnecesarry stuff).
Something like this:

Code: Select all

while(1) {
pspDebugScreenPrintf("Free RAM: %0.3f MB\n",sceKernelTotalFreeMemSize()/1000000);
sceKernelDelayThreadCB(100000);
}

And, for some reason, in the first line, it showed a lot of RAM (~50MB), but in the second line, it showed 0.001MB.
I'm sure the problem is inside the printf function (the sprintf function does the same).
But the same code, without being launched with a:

Code: Select all

int thid = sceKernelCreateThread("multiTasKing", main_thread, 0x18, 0x10000, PSP_THREAD_ATTR_USER, NULL);
if (thid >= 0) sceKernelStartThread(thid, args, argp);
return 0;

(Maybe the problem is in something there :-S)

Thanks for your help ;-)

[Raphael]

Well, the problem is not printf or your program running from a seperate thread or not - the problem is your misunderstanding of sceKernelTotalFreeMemSize() and the memory management of the PSP and the PSPSDK.

When the first allocation takes place in an application, the heap with a specific size, defined by either PSP_HEAP_SIZE_KB() macro or the default size (all 24MB of user memory for a main app, 64KB for a prx) is created by calling sceKernelAllocPartitionMemory. From this point on, all allocations through malloc or memalign are only managed by the libc software layer, and any call to sceKernelTotalFreeMemSize() will only return the amount of memory that is available to other applications (which will be zero, or close to zero if you allocated something from a normal elf).

Hence it's absolutely correct that your "test" will print the total of available user heap (~50MB, assuming you're on a PSP 3k with the extended memory) to your application in the first line (because the sceKernelTotalFreeMemSize() gets executed before it goes into the print function) and from the second line on prints next to zero (because the print function internally allocates memory, hence the heap gets initialized as above, either with 64kb if from a prx or the full range of available memory from the main eboot).

If you want a different behaviour for your "OS", you should write your own memory manager or just directly use the sceKernel* memory functions. However, this will make your program incompatible with other programs that use normal libc malloc/memalign.

[carl0sgs]

Thanks for the explanation.
But I still don't understand why the memory goes next to 0, if the defaults are 24MB and 64Kb. It should go to 26MB when called from the main app :-S

Am I defining the heap with this?:
int thid = sceKernelCreateThread("multiTasKing", main_thread, 0x18, (heap size), PSP_THREAD_ATTR_USER, NULL);

What does 0x10000 means there? :-S

I'm not sure how to fix this :-S

Thanks for your help

Edit: Maybe undefining the malloc functions and redefining them with the sceKernel ones?

[ne0h]

That's the thread stack

[Raphael]

Thanks for the explanation.
But I still don't understand why the memory goes next to 0, if the defaults are 24MB and 64Kb. It should go to 26MB when called from the main app :-S

That 24MB default was meant for PSPs with 32MB of RAM (24MB User memory + 8MB Kernel memory), while for the PSPs with 64MB of RAM it will come out as something along the 50s. Basically, default (no PSP_HEAP_SIZE_KB() macro or PSP_HEAP_SIZE_KB(-1)) means that ALL available user space memory is allocated for the heap.

What does 0x10000 means there? :-S

It should be obvious, but: http://en.wikipedia.org/wiki/Hexadecimal
And as already said, this is the stack size, not the heap size.

[carl0sgs]

Ok thank you both.
I'm going to define the heap in the PRX to see if it makes a difference :-)

[carl0sgs]

Nope, it doesn't work :-S

Still wondering why can't I use the Curl and the openDir() functions from a .prx

Please help me :-S

[anmabagima]

Hi,

(~50MB, assuming you're on a PSP 3k with the extended memory)

I've seen on a wiki that the PSP-2000 has already 64MB of RAM.
Is it possible to use this on PSP-2000 nearly complete ? Or is it limmeted to some value.

Regards
AnMaBaGiMa

[Raphael]

Hi,

(~50MB, assuming you're on a PSP 3k with the extended memory)

I've seen on a wiki that the PSP-2000 has already 64MB of RAM.
Is it possible to use this on PSP-2000 nearly complete ? Or is it limmeted to some value.

Regards
AnMaBaGiMa

As far as I'm aware of, you have around 50MB of that available for user memory. The rest is kernel space memory, and though there's a way it can be accessed and allocated, it's not recommended unless there's really no other way for your program to function.

[anmabagima]

Hi,

this confirmation is enough for me.

Thanks.

Regards...

[carl0sgs]

Edit: Ok the following was not true, just ignore it :-S I'll continue looking for a solution.

I found the way to fix this :-P

Just made this functions:

Code: Select all

SceUID MTsceKernelCreateThread (const char * name, SceKernelThreadEntry entry, int initPriority, int stackSize, SceUInt attr, SceKernelThreadOptParam * option) {
return sceKernelCreateThread (name, entry, initPriority, stackSize, attr, option);
}

int MTsceKernelStartThread (SceUID thid, SceSize arglen, void * argp) {
return sceKernelStartThread (thid, arglen, argp);
}

INSIDE the main eboot module, and exported them.

Example in the prx:

Code: Select all

int module_start(SceSize args, void *argp) {

int thid = MTsceKernelCreateThread(HomebrewName, main_thread, 0x18, 0x10000, PSP_THREAD_ATTR_USER, NULL);

if (thid >= 0) MTsceKernelStartThread(thid, args, argp);

return 0;

}

Then using them to load the prx threads inside the main module, solving the RAM thing.

Thank you for explaining me how did this worked.

Hope this fix is useful for others ;-)

Cheers,
Carlos