forums.ps2dev.org

[jimparis]

In rev 2378, I updated libSDLmain to not use kernel mode, and to not install stdio redirection or exception handlers anymore. This should let it work on new firmware (3.xx). Let me know if there are any problems.

[hibbyware]

Nice one jimparis,

This should help solve a few of the SDL lib users problems,

[Pirata Nervo]

Cool jimparis
Good job ;)
_________________

Upgrade your PSP

[pegasus2000]

[jimparis]

Well, right now I'd guess that I'm the one responsible.

[pegasus2000]

Can you contact me on MSN ?

nanodesktop@hotmail.it

I need to speak with you...

[Archaemic]

Glad to see someone finally did something about this.

Sorry, just being a little cynical here :P

Speaking of things I've done that never got committed, did my patch to pbp-unpack, or similar, ever get committed? I mean, so far, the only PBP that fails is the 3.93 PBP, and only because it's oddly padded, but there's no reason to have a pbp-unpack that fails sometimes :/

[jimparis]

Pegasus: just talk to me here.

Archaemic: yeah, I kept meaning to apply something similar but just never got around to it until now. The patch I applied goes a bit further and sets PSP_HEAP_SIZE_MAX, stack size, etc.

I just applied your unpack-pbp patch as well (rev 2379).

[pegasus2000]

[Archaemic]

Ahhh, okay, I admit that I did forget about that stuff. I looked through the patch, but I didn't see anything about the heap size...(I just looked again, and it is there...must've overlooked it the first time)

Although, when I set the heap size to max, I had a problem. That is, SDL_Init couldn't create a thread because the PSP was running out of memory. I believe this occurred because almost all of the user memory was used by the block allocated for newlib's heap. I overcame this in PSPComic with a hack whereby I allocated some memory (a few dozen kilobytes) from the user partition with sceKernelAllocPartitionMemory, initialized newlib's heap with free(malloc(1)); and then freed the memory I allocated previously. It worked fine, but it's still a little bad that I had to do this in the first place. Still, my solution worked and allows the extended memory to be used on the Slim, which makes me happy :)

[J.F.]

The heap size has always been a bit of a pain... trying by trial and error to guess how big to make the heap. My own suggestion a while back was to add an optional parameter to the MAX macro that would make the heap (MAX - parameter) so that you could get the max heap size while leaving enough free for things like threads. That would be especially helpful now that we have the Slim with its extra memory. If you need (MAX - some_space) right now, you either have to waste a lot of Slim memory, or do two separate builds for the Phat and Slim, using trial and error to figure out each heap size.

Perhaps the best way to handle it would be to modify the newlib heap init code so that if the requested heap size is negative, to add the max heap size to that value. Then you could simply do

[jimparis]

If that's true, it sounds like PSP_HEAP_SIZE_KB_MAX() is sort of useless.
It would be OK if you spawned threads before using malloc(), but not if you did the malloc() first.

Hmm. I think JF's solution is probably best -- maybe:
PSP_HEAP_SIZE_KB(1024) // reserve 1024 KB for heap
PSP_HEAP_SIZE_KB(-1024) // reserve all but 1024 KB for heap
PSP_HEAP_SIZE_KB(0) // reserve all memory for heap
PSP_HEAP_SIZE_MAX() = PSP_HEAP_SIZE_KB(-1024) // for compatibility

Another idea would be to just replace newlib's malloc implentation with one that calls sceKernelAllocPartitionMemory directly. I suspect that would be too inefficient and might hit strange limitations about how many blocks can be allocated, etc.

[jimparis]

[jimparis]

I set PSP_HEAP_SIZE_KB(20480) for now. I'll implement JF's suggestion at some point (or if someone could provide a patch, it'll happen faster!) and then we can use something like PSP_HEAP_SIZE(-1024) as default.

[Insert_witty_name]

We had a rather lengthy discussion on IRC (JF get yourself on there!) about this subject and we'll correct it ASAP, when we can decide on a good workaround.

[J.F.]

[Archaemic]

Going to venture a guess here and say #pspdev on Freenode. At least, that's the PSP channel I go to. And I see IWN there. So I'd say it's a fairly good guess :P

[pegasus2000]

Yes. I have seen your code. It's a good work, compliments.

I'm thinking this: for the nd version of SDL, I could use the
HW accelerated code of your SDL version when SDL is used
in full screen mode, and I could use own nd routines when
SDL is used in windows.

After, I'll map all calls to the hardware (thread, joystick etc.),
to the corresponding nd HAL routines. So, if I'll want to port
SDL under other platform, it will be sufficient to write a new
HAL.

I want, if it is possible, a permission to include your code in
ndSDL library. Naturally, I'll indicate in the documentation
that the accelerated code has been written by you.

Moreover, I want to ask you if you can help me with some infos,
when I don't understand some pieces of your code.

Thanks in advance.

[jimparis]

It's not all my code; most of the HW accelerated stuff in particular was rewritten by mrbrown and rinco. Check "svn annotate" output. But anyway, it's open source, so you're certainly welcome to use the code as you wish, as long as you follow the licensing terms (LGPL for that code). You certainly wouldn't be able to incorporate SDL in your own code without following the LGPL anyway.

[pegasus2000]

[jimparis]

I can offer occasional tips or answer questions to the best of my ability, but I don't have the time or interest at the moment to join the team or do any specific porting work, sorry.