SDL switched to usermode

[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 ;)

[pegasus2000]

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.

Jimparis, I need an information. Who is the responsable about the
development of PSPSDL ?

I need to contact him....

[jimparis]

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

[pegasus2000]

Can you contact me on MSN ?

[email protected]

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]

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).

Well. Ok.

I'm thinking about this. Here, in Italy, a developer has suggested to
me that porting Allegro library isn't the best solution. He said that,
in his opinion, it's better to port SDL.

So, I'm thinking this: is it possible to port SDL under nd ?

You know the features of your porting for PSP, so I would ask to you if
we could work together in order to add to nd the SDL compatibility.

For example: which are the PSP-dependant parts of SDL ?

[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

Code: Select all

PSP_HEAP_SIZE_KB(-1024);

To get a heap that is the max minus a MB.

[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]

So, I'm thinking this: is it possible to port SDL under nd ?

You know the features of your porting for PSP, so I would ask to you if
we could work together in order to add to nd the SDL compatibility.

For example: which are the PSP-dependant parts of SDL ?

Sure, SDL is easy to port (it's been ported to lots of architectures). Just look at the source code. To see the differences between stock SDL and what we did for PSP, see

Code: Select all

svn diff -r441:HEAD svn://svn.pspdev.org/psp/trunk/SDL/

(there are some extraneous changes to config.guess, but I think most of that diff is relevant). Most of the stuff you'll want to look at are in the psp dirs:

Code: Select all

src/timer/psp
src/main/psp
src/joystick/psp
src/audio/psp
src/video/psp
src/thread/psp

[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.]

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.

Which channel? I'm currently joined to #psp-programming as jlfenton... at least I think I am. I'm not much of an irc user. :)

EDIT: As far as the heap goes, the main thing is the code in _sbrk() in newlib.

Code: Select all

		if (heap_size == (unsigned int) -1) {
			heap_size = sceKernelMaxFreeMemSize();
		} else {
			heap_size *= 1024;
		}

Leave the -1 and positive for backwards compatibility, and just make negative values other than -1 deduct from the max, like so

Code: Select all

		if &#40;&#40;int&#41;heap_size < 0&#41; &#123;
			heap_size = sceKernelMaxFreeMemSize&#40;&#41; + &#40;heap_size == &#40;unsigned int&#41; -1&#41; ? 0 &#58; &#40;int&#41;heap_size * 1024;
		&#125; else &#123;
			heap_size *= 1024;
		&#125;

PSP_HEAP_SIZE_MAX is currently defined to be PSP_HEAP_SIZE_KB(-1), so leave that. With the mod above, using PSP_HEAP_SIZE_KB(-10) would result in the heap size being set to
sceKernelMaxFreeMemSize() + (-10*1024).

[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]

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.

We'll release ndSDL in Nanodesktop distribution as a LGPL library
and we'll report all notes about the paternity of the code and about
the changes that have been made.

Moreover: I'm collecting a team here, in Italy. Actually we are three
developers. The works will begin in July.

I would be very glad if you would partecipate with my team.

[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.