What has changed in coding for the newer firmwares ?
What has changed in coding for the newer firmwares ?
Hi folks,
I have created some code and some games for the 1.5 firmwares, that code just works fine onwards to the OE versions (tested up to 3.02 OE)
however code that works fine does not work correctly anymore on m33, since I do not want to upgrade to that firmware I am stuck with this problem. Can anybody tell me what function calls and the sort have changed/added/deleted etc.? or is there something else going on?
one thing was that a lot did not work with setting the processor to 333 but when i set it to 222 it worked a lot better but not perfect. Are there more of these kinds of things? I have searched the forum but could not find anything, if i missed something please do let me know.
greets ghoti
I have created some code and some games for the 1.5 firmwares, that code just works fine onwards to the OE versions (tested up to 3.02 OE)
however code that works fine does not work correctly anymore on m33, since I do not want to upgrade to that firmware I am stuck with this problem. Can anybody tell me what function calls and the sort have changed/added/deleted etc.? or is there something else going on?
one thing was that a lot did not work with setting the processor to 333 but when i set it to 222 it worked a lot better but not perfect. Are there more of these kinds of things? I have searched the forum but could not find anything, if i missed something please do let me know.
greets ghoti
My PSP games:
Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php
Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php
I dont know if this has anything to do with it.. but the newer firmwares (or just the new slim psp idk) only support 2.00+ apps. I dont know if that means you have to code it different though. I think possibly you just change the fw version in the makefile? I'm no expert so dont totally depend on my word lol. I honestly dont know the difference in coding for other versions of firmwares I just do 1.50 :\
Enlighten me, Reveal my fate -- Follow - Breaking Benjamin
So it should be made a fw 2.0 app and it need to be build as a prx?
are there other differences ?
are there other differences ?
My PSP games:
Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php
Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php
Porting a 1.50 firmware homebrew to 3.xx firmware
Someone should sticky a article like this as a lot of people ask about this. Comments or suggestions would be welcome. If you want to provide links related to this to add in a links selection, that would be nice.
Porting a 1.50 firmware homebrew to 3.xx firmware
3.xx firmwares require your homebrew be in prx format. To get your homebrew in this format, you need to follow a few basic steps:
1. Modify your Makefile - You need to add the following to your Makefile to compile a prx (before the include $(PSPSDK)/lib/build.mak line):
2. Set your homebrew to user mode - Your homebrew needs to start in user mode. To do this, change the 2rd argument in PSP_MODULE_INFO to 0. For most homebrew you will also need to increase your heap size. The heap size is the amount of memory available to malloc. I set mine to 20mb. The bellow code should be at the top of your main source file (normally main.c).
Alternatively you can use PSP_HEAP_SIZE_MAX(); if you have a toolchain compiled on or after Sep. 30th, 2007 (revision 2321). This will allocate as big of a heap as it can. Please note you should recompile your entire toolchain (or at least pspsdk and newlib) to use this, otherwise your homebrew will crash with a Exception - Bus error (data).
3. Try running your app - You should now be able to compile your app with a normal make and copy over the EBOOT.PBP per usual. There is no kxploit or % folder for 3.xx firmware. If you are running your application from psplink, you need to run the prx file instead of the elf file or it will not run. At this point your homebrew should run unless you have kernel calls in your code. If your code has kernel calls you will get a 0x8002013C error when you try to start the homebrew. Don't panic, move on to step 4. If your homebrew runs, great, skip step 4.
4. Locate and deal with your kernel calls - You need to figure out what is a kernel call and what isn't. To do this, you can use prxtool -f <prx file>. Here is a example output:
If you look at the above output you can see there is a import called IoFileMgrForKernel. This import has one function. Refer to this page: http://silverspring.lan.st/1.5x/kd/iofilemgr.html. Search on the page and you will find that 0x411106BA matches the function sceIoGetThreadCwd. You can now search for this function and either (a) replace the kernel call with user mode code -or- (b) move the kernel call into a kernel mode prx and load that kernel mode prx from your homebrew. Option B is out of the scope of this tutorial so search the forums to figure out how to do this. Option A is the preferable solution unless you have to use a kernel call. I went to the main page http://silverspring.lan.st and clicked on 1.5x firmware. From this page I found sceIOFileManager in the list and clicked on it to get to the above page. A search function would have been nice.
Porting a 1.50 firmware homebrew to 3.xx firmware
3.xx firmwares require your homebrew be in prx format. To get your homebrew in this format, you need to follow a few basic steps:
1. Modify your Makefile - You need to add the following to your Makefile to compile a prx (before the include $(PSPSDK)/lib/build.mak line):
Code: Select all
BUILD_PRX = 1
PSP_FW_VERSION = 371
Code: Select all
PSP_MODULE_INFO("My Homebrew", 0, 1, 0);
PSP_HEAP_SIZE_KB(20480);
3. Try running your app - You should now be able to compile your app with a normal make and copy over the EBOOT.PBP per usual. There is no kxploit or % folder for 3.xx firmware. If you are running your application from psplink, you need to run the prx file instead of the elf file or it will not run. At this point your homebrew should run unless you have kernel calls in your code. If your code has kernel calls you will get a 0x8002013C error when you try to start the homebrew. Don't panic, move on to step 4. If your homebrew runs, great, skip step 4.
4. Locate and deal with your kernel calls - You need to figure out what is a kernel call and what isn't. To do this, you can use prxtool -f <prx file>. Here is a example output:
Code: Select all
$ prxtool -f project.prx
... output left out (it's a lot of output) ...
Import 9, Name UtilsForUser, Functions 1, Variables 0, flags 40010000
Functions:
0x79D1C3FA [0x0008CF34] - UtilsForUser_79D1C3FA
Import 10, Name LoadExecForUser, Functions 2, Variables 0, flags 40010000
Functions:
0x05572A5F [0x0008CF3C] - LoadExecForUser_05572A5F
0x4AC57943 [0x0008CF44] - LoadExecForUser_4AC57943
Import 11, Name IoFileMgrForKernel, Functions 1, Variables 0, flags 00010000
Functions:
0x411106BA [0x0008CF4C] - IoFileMgrForKernel_411106BA
Done
Last edited by CpuWhiz on Tue Oct 09, 2007 12:09 pm, edited 2 times in total.
Hi
that tutorial is really nice !! Can I use this information on my site? (to help others)
So basicly what you say is you can only run this in higher firmwares, so for game releases there should be a 1.50 release and a 3.x release right?
that tutorial is really nice !! Can I use this information on my site? (to help others)
So basicly what you say is you can only run this in higher firmwares, so for game releases there should be a 1.50 release and a 3.x release right?
My PSP games:
Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php
Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php
I don't mind. I wrote it to help others, so go for it. Just don't claim it as your own and we're cool.Ghoti wrote:Can I use this information on my site? (to help others)
Yes. If you remove your kernel calls (if you had any), all you should have to do to make a 1.50 build is to comment out the two lines in the Makefile and (I think) the PSP_HEAP_SIZE_KB line, then build normally.Ghoti wrote:So basically what you say is you can only run this in higher firmwares, so for game releases there should be a 1.50 release and a 3.x release right?
Re: Porting a 1.50 firmware homebrew to 3.xx firmware
Not quite... the SECOND argument = 0 is user mode. The third arg is the version number, and the fourth is the revision number. Also, I think the SDK was recently updated so that the heap was expanded to the max for 2.x/3.x homebrew, so the heap size shouldn't be needed anymore.CpuWhiz wrote: 2. Set your homebrew to user mode - Your homebrew needs to start in user mode. To do this, change the 3rd argument in PSP_MODULE_INFO to 1. For most homebrew you will also need to increase your heap size. The heap size is the amount of memory available to malloc. I set mine to 20mb. The bellow code should be at the top of your main source file (normally main.c).Code: Select all
PSP_MODULE_INFO("My Homebrew", 0, 1, 0); PSP_HEAP_SIZE_KB(20480);
Sorry, minor mistake there. Thanks for the info and corrections J.F.
Edit: Do you mean PSP_HEAP_SIZE_MAX() from this revision?
Edit: Do you mean PSP_HEAP_SIZE_MAX() from this revision?
Code: Select all
------------------------------------------------------------------------
r2321 | tyranid | 2007-09-30 11:08:16 -0600 (Sun, 30 Sep 2007) | 2 lines
Added a define to allow easy allocation of all available memory for the heap (needs an updated newlib)
------------------------------------------------------------------------
Probably, but I'm not exactly sure how that affects the programs as I haven't tested that myself. :)CpuWhiz wrote:Sorry, minor mistake there. Thanks for the info and corrections J.F.
Edit: Do you mean PSP_HEAP_SIZE_MAX() from this revision?Code: Select all
------------------------------------------------------------------------ r2321 | tyranid | 2007-09-30 11:08:16 -0600 (Sun, 30 Sep 2007) | 2 lines Added a define to allow easy allocation of all available memory for the heap (needs an updated newlib) ------------------------------------------------------------------------
As to the minor correction, it's easier to keep track of when you do it this way:
Code: Select all
#define VERS 1
#define REVS 3
PSP_MODULE_INFO("IdStorageManager", 0, VERS, REVS);
I dont think I have a clue since I have only been coding for a couple of days now.. but why can't you run in kernel mode 3.xx? I've got 3.03-C(maybe this is why?) and it works fine.. BUT here is what probably makes it work
PSP_THREAD_ATTR_USER should make the thread in user mode correct? why cant you put it into kernel mode and run a user thread like this?
I cannot run anything besides a user thread though in my firmware.. is this because this is the only way you can run it? or can you put in PSP_THREAD_ATTR_KERNEL? because I tried that(if it even works on other fw's) and it crashed :\
Code: Select all
thid = sceKernelCreateThread("update_thread", CallbackThread, 0x11, 0xFA0, PSP_THREAD_ATTR_USER, NULL);
Code: Select all
PSP_MODULE_INFO("TEST", 0x1000, 1, 1);
PSP_MAIN_THREAD_ATTR(0);
..
..
//From SDK Sample
int SetupCallbacks(void)
{
int thid = 0;
thid = sceKernelCreateThread("update_thread", CallbackThread, 0x11, 0xFA0, THREAD_ATTR_USER, 0);
if(thid >= 0)
{
sceKernelStartThread(thid, 0, 0);
}
return thid;
}
Enlighten me, Reveal my fate -- Follow - Breaking Benjamin
It think it's better not to run in kernel mode in any case. Sony can't really change user mode without breaking most the games, so sticking to user mode is better for compatibility. If you need something from kernel mode, use the external prx. Then when Sony changes kernel mode (like with 3.71), you just have to change the prx, not the entire program.
Re: Porting a 1.50 firmware homebrew to 3.xx firmware
Hi, I am porting a homebrew YDICT (which is an English-Chinese Dict). I found that in the existing code, the second argument of PSP_MODULE_INFO had already been 0 (usermode). Does this mean I can skip the 4th step in your tutorial safely?CpuWhiz wrote:Someone should sticky a article like this as a lot of people ask about this. Comments or suggestions would be welcome. If you want to provide links related to this to add in a links selection, that would be nice.
......
Thanks.
Re: Porting a 1.50 firmware homebrew to 3.xx firmware
Not necessarily. If it didn't have "BUILD_PRX = 1" in the makefile, it is being built and a static elf and won't be able to load external prxs. If it has that in the makefile, then maybe you can skip ahead.ppyyf wrote:Hi, I am porting a homebrew YDICT (which is an English-Chinese Dict). I found that in the existing code, the second argument of PSP_MODULE_INFO had already been 0 (usermode). Does this mean I can skip the 4th step in your tutorial safely?CpuWhiz wrote:Someone should sticky a article like this as a lot of people ask about this. Comments or suggestions would be welcome. If you want to provide links related to this to add in a links selection, that would be nice.
......
Thanks.
If hb is compiled for the high fw, eg:
-will it work same as kernel app on all 3.XX custom fws, as 3.40 OE?
Code: Select all
PSP_FW_VERSION = 371
00000110 00000110 00000110
Hmm... As i see, 3.XX hb may be compiled only in user mode, but you may do kernel calls via included kernel libs in KM PRX?Be3f wrote:If hb is compiled for the high fw, eg:-will it work same as kernel app on all 3.XX custom fws, as 3.40 OE?Code: Select all
PSP_FW_VERSION = 371
00000110 00000110 00000110
Yeah.
The only REAL requirements are:
- EBOOT.PBP has to be in usermode (can be also an elf... but recommended t oadd BUILD_PRX=1 to makefile, along the EXTRA_TARGETS=EBOOT.PBP, and don't forget to expand stack)
- Don't call kernel stuff in usermode apps (and vice versa)
But apart that, you can make PRXs from kernel or usermode, as you wish :) Just don't forget to load them to the correct memory partition.
The only REAL requirements are:
- EBOOT.PBP has to be in usermode (can be also an elf... but recommended t oadd BUILD_PRX=1 to makefile, along the EXTRA_TARGETS=EBOOT.PBP, and don't forget to expand stack)
- Don't call kernel stuff in usermode apps (and vice versa)
But apart that, you can make PRXs from kernel or usermode, as you wish :) Just don't forget to load them to the correct memory partition.
I sucessfully used PSP_HEAP_SIZE_KB(21000) even on a Fat.... but that's pretty close to the limit, tried a bit more, and got errors then....
AFAIK this also applies to the Slim, since the additional memory is an additional mem partition and does not simple expand the "normal" memory we are used to use....
AFAIK this also applies to the Slim, since the additional memory is an additional mem partition and does not simple expand the "normal" memory we are used to use....
I've read and I'm currently reading as much as I can find on prx related threads, and try to make things work on my sdk/psp with poor results, mainly because I've got these main big question without any clue, some points I found lead me to confusion:
1) I have to extract any kernel command in a separate c file, a completely dissociated c source with its own makefile (that build_prx=1 thing), that let me have a .prx file. Then I need another "main" c source that have to import those previous kernel calls. I'm trying this way but all I get is a psp crash.
2) when I add the build prx =1 in makefile I get both the pbp and the prx, working together and ready to be placed under game folder (afaik is impossible, with one source only)
3) both main makefile and prx's must have build_prx=1, or only the prx makefile
4) I'm a jerk and one can play directly the prx without an eboot (O__O sounds stupid, but I found a thread here telling to play a prx)
5) no prx needed, if I switch to user mode and add in my main.c makefile build_prx=1 I get my eboot.pbp ready to go (and the exports? doesn't make sense 4 me, again I found a thread here with an example made this way)
6) I'm very very jerk because prx has not to stay in the eboot folder but in SEPLUGINS (or wherever else) and be enabled from recovery menu (I tried but always get crashes)
7) someone wrote "you can try playing the .elf" is it possible???? anyway I don't want an "elf" executable...
I tend to believe I have to code my pretty main.c with its own makefile, including the needed prx-file include
after compile I expect to obtain just the runnable eboot. (without prx=1 in makefile, I want a pbp here?)
Then I have to begin a brand new C project, provide the needed kernel calls, add the prx=1 thing in makefile and expect
to obtain my module.prx, and some exports file.
Done this, I copy the pbp and the prx in a nice game/371 folder and play the eboot (sometimes I get also a further
"corrupted data" icon, don't know if it's normal). Looks pretty easy, but after gameboot my psp crashes. :P
1) I have to extract any kernel command in a separate c file, a completely dissociated c source with its own makefile (that build_prx=1 thing), that let me have a .prx file. Then I need another "main" c source that have to import those previous kernel calls. I'm trying this way but all I get is a psp crash.
2) when I add the build prx =1 in makefile I get both the pbp and the prx, working together and ready to be placed under game folder (afaik is impossible, with one source only)
3) both main makefile and prx's must have build_prx=1, or only the prx makefile
4) I'm a jerk and one can play directly the prx without an eboot (O__O sounds stupid, but I found a thread here telling to play a prx)
5) no prx needed, if I switch to user mode and add in my main.c makefile build_prx=1 I get my eboot.pbp ready to go (and the exports? doesn't make sense 4 me, again I found a thread here with an example made this way)
6) I'm very very jerk because prx has not to stay in the eboot folder but in SEPLUGINS (or wherever else) and be enabled from recovery menu (I tried but always get crashes)
7) someone wrote "you can try playing the .elf" is it possible???? anyway I don't want an "elf" executable...
I tend to believe I have to code my pretty main.c with its own makefile, including the needed prx-file include
after compile I expect to obtain just the runnable eboot. (without prx=1 in makefile, I want a pbp here?)
Then I have to begin a brand new C project, provide the needed kernel calls, add the prx=1 thing in makefile and expect
to obtain my module.prx, and some exports file.
Done this, I copy the pbp and the prx in a nice game/371 folder and play the eboot (sometimes I get also a further
"corrupted data" icon, don't know if it's normal). Looks pretty easy, but after gameboot my psp crashes. :P
Hi! :)
You can put all your kernel command in a single prx
You have to compile the prx and the app separately.
Both prx and app needs BUILD_PRX = 1
Here there's a little sample:
http://www.sakya.it/downloads/testPer371.rar
To compile it:
Copy both the EBOOT and the prx in the same directory (x:\PSP\GAME3xx\test)
http://forums.ps2dev.org/viewtopic.php?t=9022
It's almost the same source you can find in this thread, but this is for kernel 3.71
The only difference with the 3.52 version is that I had to import the correct NIDS for kernel functions (changed by Sony in kernel 3.7)
Ciaooo
Sakya
You can put all your kernel command in a single prx
You have to compile the prx and the app separately.
Both prx and app needs BUILD_PRX = 1
Here there's a little sample:
http://www.sakya.it/downloads/testPer371.rar
To compile it:
Code: Select all
cd prx
make
psp-build-exports -s mylib.exp
cd ..
make
http://forums.ps2dev.org/viewtopic.php?t=9022
It's almost the same source you can find in this thread, but this is for kernel 3.71
The only difference with the 3.52 version is that I had to import the correct NIDS for kernel functions (changed by Sony in kernel 3.7)
Ciaooo
Sakya
Also, to build a 3.XX EBOOT, you need to edit pspdev/psp/sdk/lib/build.mak - delete strip_ here:
(I may have an old SDK - November 2006...)
Code: Select all
$(PSP_EBOOT_SND0) strip_$(FINAL_TARGET) $(PSP_EBOOT_PSAR)
00000110 00000110 00000110
It's very simple to get all the Slim memory added to the normal partition - just add this to the makefile:Hellcat wrote:I sucessfully used PSP_HEAP_SIZE_KB(21000) even on a Fat.... but that's pretty close to the limit, tried a bit more, and got errors then....
AFAIK this also applies to the Slim, since the additional memory is an additional mem partition and does not simple expand the "normal" memory we are used to use....
Code: Select all
PSP_LARGE_MEMORY = 1
Code: Select all
PSP_HEAP_SIZE_MAX();