forums.ps2dev.org

Hi! How do the sceIO* functions handle things? Does it have another buffer or does it DMA straight into your pointer? AFAICS the only software buffer is in fread(3). fread(3) itself calls read(2) which calls sceIoRead, with some reentrant (*_r) steps in-between. The tests suggests that the PSP kerne...

AFAICS access time for small files doesn't change, this only impacts smalls reads in larger files: test_bufsiz= 1024 - read(2): 401ms - lseek(2): 467ms test_bufsiz= 2048 - read(2): 397ms - lseek(2): 444ms...

Hmmm, BAD news. I tried recompiling the game port I'm working on (GNU FreeDink), and apparently this patch dramatically _harms_ the loading time. I suppose that when accessing lots of small files or when doing a decent number of fseek()s, reading big chunks (with a 65k buffer) harm performances (lik...

Maybe we can use this technique to change the FILE* internal buffer size though. (apparently this happens in newlib/libc/stdio/makebuf.c:109) I tried the following patch: --- newlib-1.16.0.bak/newlib/libc/stdio/makebuf.c 2007-05-02 01:03:36.000000000 +0200 +++ newlib-1.16.0-psp/newl...

I'd suggest something like the PSP_HEAP_SIZE_XXX defines... make a weak variable called something like "_fread_bufsize" that defaults to 1024 when not defined, but otherwise takes the defined value. That way, someone who's aware of the memory constraint and wants the fastest speed can add...

sure, if you could write a patch I'll apply it. I'll give this a try! Urm be careful though (I haven't checked where the buffer is defined) but there is always the risk that increasing the size could make existing code fail due to higher memory requirements (well when recompiled against a new libc)...

Hi, I saw that the memory stick access is pretty unefficient when using fread(3). From what I can see this is because BUFSIZ is set to 1024 in the psptoolchain, and it could be improved to up to 8x. How about using a BUFSIZ value like 65k to (dramatically) improve Memory Stick perfs? I did the follo...

Thinking about it, it may be better, in fact, to start a minimal "bootstrap" program that itself starts the front-end. When the front-end quits, it saves the parameters in a file which is read by "bootstrap" to run the main game. You lose 100-200k RAM in the process, but you avoi...

Thanks for your answer. Lot of unnecessary crap in your code. And yes the trailing spaces in the makefile lines screw things up. Yes, the code was as-is, since I was aiming at getting something that worked before trying to trim it. I wasn't clear, but actually the Makefile bug was the only thing to ...

Beuc wrote:

Code: Select all

USE_KERNEL_LIBC=1 
USE_KERNEL_LIBS=1 

Hmmm, it doesn't show on the forum but did you know that a trailing space in 'USE_KERNEL_LIBC=1 ' can seriously mess you build? Just learnt about it XD

Arrrrrrrrrrrrrrrrrrrrrrrrrrgh!!!

Thanks Torch. Here's the code, I'm trying to follow your advice: #include <pspsdk.h> #include <pspkernel.h> #include <string.h> #include <stdio.h> PSP_MODULE_INFO&#40;"nanofe", 0x1007, 1, 0&#41;; PSP_MAIN_THREAD_ATTR&#40;PSP_THREAD_ATTR_USER&#41;; int plugin_thread &#40...

Hi, I'm trying to load a module from within a kernel module. When I use: SceUID modid = sceKernelLoadModule&#40;"hello.prx", 0, &option&#41;; from the kernel module, it returns 0x80020149 (SCE_KERNEL_ERROR_ILLEGAL_PERM_CALL). I tried using USE_KERNEL_LIBS=1 to allow the kernel ...

I now have a kernel module. However, when I use: SceUID modid = sceKernelLoadModule&#40;"hello.prx", 0, &option&#41;; from the kernel module, it returns 0x80020149 (SCE_KERNEL_ERROR_ILLEGAL_PERM_CALL). I read at http://forums.ps2dev.org/viewtopic.php?p=66785 that I can use USE_...

You'll find lots of example user, kernel, and vsh modules in this forum. Look around a little first, then ask. :) Oh, a RTFM. Long time no see. So according yo samples/prx/prx_loader/main.c, "kernel mode" just means "memory partition ID == mpid == 1", to be used in pspSdkLoadSta...

Kernel modules are loaded into the kernel partition. That means that when the user modules exit, the user partition is completely devoid of modules. Using a kernel module is your best bet to get the most memory. Just be sure to keep it small - you don't have much space in the kernel partition to pl...

Ya it didn't strike me that it could be fragmentation and not because of the memory not being freed. But in that case isn't it pretty much impossible to predict at which location the intermediate module will be loaded, regardless of how small, thus still fragmenting the memory and limiting the maxi...

In the loader module free the heap, load your app and call SelfStopUnloadModule. In module_start() of your app use sceKernelFindModule to check until your loader app is no longer present.. Then use malloc. Well in the app I tried to start the main() with a sleep(5) - and the memory was still not fr...

One solution I found is to use: sceKernelSelfStopUnloadModule&#40;1, 0, NULL&#41;; However the module I loaded just before still can't use all memory, because it's started before the front-end is unloaded (even if it sleep(2) before the first malloc) - sceKernelMaxFreeMemSize() and more dire...

Hi, I'm writing a front-end to start my homebrew with different parameters. To maximize the homebrew's available memory, I'm already calling: __psp_free_heap&#40;&#41;; to free all malloc'd memory. However, there's still the front-end itself: the executable code, and the data segment. Since ...

As to the first part, what are you using to define the heap size in the app? I normally use something like "PSP_HEAP_SIZE_KB(-256);", which means gimme everything except for 256 KB. I found that I have 10M of data segment (.bss) in my executable (e.g. static struct arrays), which looks li...

Hi, I was investigating an out-of-memory crash, and I found that malloc doesn't alloc all available memory: int tmalloc = 0; while &#40;malloc&#40;1024&#41; != NULL&#41; tmalloc += 1024; /* while &#40;malloc&#40;1024*1024&#41; != NULL&#41; */ /* tmalloc += 1024*1024; ...

Torch wrote:Simply add the prototype for it in your source and it will work.

Cool. I did but actually I had forgotten an "extern C" somewhere (I'm using Guichan so the program is C++), hence I thought I didn't work. It works fine now - only using '__' functions is probably a bit ugly.
Thanks :)

I confirm that the heap is not freed - sadly __psp_free_heap() doesn't seem to be public, and it's the only function with access to the memory blockid used by newlib AFAICS.
Is there another way?

Thanks - what function should I use to free the heap?
I didn't manipulate it directly.

OK, apparently something going wrong (800200d9) if I run an SDL app from another SDL app - even if I unloaded everything: Works: - run text-mode app 1 - user chooses app to launch - call pspSdkLoadStartModule(SDL App 2) - SDL App 2 is run Doesn't work: - run SDL app 1 - user chooses app to launch (g...

int k1 = pspSdkSetK1&#40;0&#41;; SceUID mod = sceKernelLoadModule&#40;path, 0, NULL&#41;; if &#40;mod >= 0&#41; &#123; mod = sceKernelStartModule&#40;mod, 0, NULL, NULL, NULL&#41;; if &#40;mod < 0&#41; //Error &#125; pspSdkSetK1&#40;k1&#41;; R...

Hi, I'd like to run my FreeDink(.org) homebrew with some additional parameters, so it can run a given addon instead of the main game. In another words I need to write a simple frontend to do the job. What's the best way to run the game engine from the frontend - that is, run an homebrew from another...

Here are my notes from a couple days ago. I managed to run some of it, but not all. A tutorial: http://www.ngine.de/index.jsp?pageid=4292 Another (French) tutorial with a better Makefile: http://www.metagames-eu.com/forums/psp/tuto-remotejoy-psplink-ou-comment-afficher-lecran-de-votre-psp-sur-le-pc-...

And here's the patch:
http://forums.ps2dev.org/viewtopic.php?t=11869

zziplib already has code similar to mine (__zzip_get32(c)), I made it use it in all little-endian cases.

zziplib makes a misaligned 32bit pointer dereference, which causes a crash, at least when the zip has a preamble. This was further discussed and diagnosed at http://forums.ps2dev.org/viewtopic.php?t=11864 This patch makes zziplib always rely on portable char[4]->int conversion instead of the less po...