Custom Firmware Extender 3.1 - Coder needed

[Madridi4ever]

Updated first post with the link. Anyone willing to look at it?

Nowadays PSP scene is so silent, we need an OFW update or a third analog for the PSP-go

Yeah I know.. I am just hoping to get one of the best plugins we have completely upgraded and preserved for the future. Hopefully, the task is small enough for a developer to take a look at it

Advertising

[Madridi4ever]

Last plea for help before I give up

Advertising

[Joel16]

Alright I gave it a shot, but unfortunately I wasn't able to find a complete solution to the problem. There was however some progress, as it now manages to enter USB mode and doesn't freeze or anything either. You can find the updated source here.
My modifications mainly included updating function NIDS and offsets for 6.60. You can find these in cfe_redirect/syspatch.c. The firmware checks for 6.20 and greater indicate my modifications in the source code.

Madridi4ever should post a detailed description of the current problem, and what the build from my updated source has achieved. He's also going to indicate how it should behave 'normally' as in the 5.XX CFW's. Hopefully some dev can pinpoint the problem as I believe there isn't much left to do

Also here's the latest build from my modification.

[Madridi4ever]

Alright I gave it a shot, but unfortunately I wasn't able to find a complete solution to the problem. There was however some progress, as it now manages to enter USB mode and doesn't freeze or anything either. You can find the updated source here.
My modifications mainly included updating function NIDS and offsets for 6.60. You can find these in cfe_redirect/syspatch.c. The firmware checks for 6.20 and greater indicate my modifications in the source code.

Madridi4ever should post a detailed description of the current problem, and what the build from my updated source has achieved. He's also going to indicate how it should behave 'normally' as in the 5.XX CFW's. Hopefully some dev can pinpoint the problem as I believe there isn't much left to do

Also here's the latest build from my modification.

Well, first of all, thanks for taking a shot at it, and the progress made is huge! What's remaining to completely fix it is I believe something very minor.

Right, so the original patch was created for 5.00 M33, it was never updated after that, and while most functions worked in all later firmwares, one feature (and a BIG feature) was not, which is "remap USB to ms".

What this feature did, was letting you browse your entire directory on your PC from your game tab on your PC, which made it act as an ISO loader. It ran iso, homebrew, and ps1 games all through this function.

The original one we have simply freezes the psp whenever this option is selected. The mod posted above solved that. It no longer freezes the psp, and we have remapping working again!

However, while remapping works and you can view all ISO, homebrew, and ps1 from your PC, it doesn't run, and I BELIEVE I know why this happens:

Originally, on 5.00, once you run anything, it goes to the gameboot screen then runs whatever was selected. In gameboot, USB was disconnected, and reconnected. (Meaning you hear the ding sound twice on the PC). This mod however, disconnects the USB as intended in gameboot, but it never reconnects, which causes it to go to a black screen when running an ISO, or going back to the main menu with an error when running homebrew/ps1 games.

So I believe all that's remaining is to see why the USB is not connecting, maybe an offset needs to be updated somewhere.

My theory is that the release contains 5 main prx files:
cfe_loader
cfe_light
cfe_game
cfe_vsh
cfe_redirect

Now, I am purely speculating, but it seems to me that when you activate remap from (cfe_loader), it activated that in (cfe_redirect), it activates usb in (cfe_vsh), then I run the game, (cfe_vsh) deactivates usb and (cfe_game) is supposed to turn it on but it is not. Some maybe there is an offset somewhere in cfe_loader or cfe_game code that needs updating.

I hope someone can take a look at it.

[badman12345]

@madridi4ever, I'm in the same boat as you. I'm trying to get the CFE 3.1 (specifically the ubshost aspect of it) working with 6.60ME-2.3, and I think that joel16 has made some great progress for us here. I think that there are just a few more NIDs that don't match to 6.60 yet. Maybe he can comment.

I'm no coder, but I have tinkered with some code in the past.

Here's what I see:
In the syspatch.c file, all of the NIDs have been updated for the 6.60 FW (although it looks like it applies these NIDs to all firmwares from 6.20 to 6.61, and I know for a fact that 6.60 and 6.20 use different NIDs, so maybe we should tinker with that a bit too at a later date.... anyway, neither here nor there right now).

Anyway, here's what I'm seeing...
1) the sceKernelExitVSHVSH NID doesn't seem to be correct for 6.60, which is why I assume he hardcoded the correct one (0x5AA1A6D2) into utils.c rather than calling nid[0].
2) The displaynids that he added under getDisplayNids for 6.60 are incorrect, and are actually referencing the 6.60 controller nids... The two displaynids should be (I believe): nid[0] = 0xFBB369FD (this is sceDisplayGetFrameBuf) and nid[1] = 0xFE5884EF (sceDisplayWaitVblank)
3) Similarly, I THINK the controlnids are wrong too, and should be: nid[0] = 0xBE30CED0 (sceCtrlReadBufferPositive) and nid[1] = 0x2BA616AF (sceCtrlPeekBufferPositive)

I'm going to scour through the nids in all of the files tonight and see if I can make some more progress. I'll recompile and give it a whirl and report back.

[Joel16]

1) the sceKernelExitVSHVSH NID doesn't seem to be correct for 6.60, which is why I assume he hardcoded the correct one (0x5AA1A6D2) into utils.c rather than calling nid[0].

According to uOFW, It's correct. Just incase you didn't know, uOFW is a project that aims to reverse the psp kernel's (6.60) modules. Edit: I forgot you were talking about utils.c haha, I was thinking of nid[0] in syspatch.c. According to PROCFW, sceKernelExitVSH_660 uses the NID 0x08F7166C so I'm not too sure on that one. However sceKernelExitVSH does use 0x5AA1A6D2, but anyways updated!

2) The displaynids that he added under getDisplayNids for 6.60 are incorrect, and are actually referencing the 6.60 controller nids... The two displaynids should be (I believe): nid[0] = 0xFBB369FD (this is sceDisplayGetFrameBuf) and nid[1] = 0xFE5884EF (sceDisplayWaitVblank)

This is a mistake in my case , I must have gotten mixed with getDisplayNids(int); and getCtrlNids(int);
I have updated both the NIDs on my github repository. I also updated the sceDisplay_driver nids.

3) Similarly, I THINK the controlnids are wrong too, and should be: nid[0] = 0xBE30CED0 (sceCtrlReadBufferPositive) and nid[1] = 0x2BA616AF (sceCtrlPeekBufferPositive)

I'm sure my control NIDS are correct according to 6.60's libdoc.xml. But it depends if you're using sceCtrl_driver lib or sceCtrl. The NIDs you stated works for sceCtrl_driver. However the ones I've used was for sceCtrl.

Code: Select all

<FUNCTION>
		<NID>0x1F803938</NID>
		<NAME>sceCtrlReadBufferPositive</NAME>
</FUNCTION>

Code: Select all

<FUNCTION>
		<NID>0x3A622550</NID>
		<NAME>sceCtrlPeekBufferPositive</NAME>
</FUNCTION>

There shouldn't be any problem with the control NIDs, since he said my mod manged to get remapping working again. (It didn't previously). The problem lies somewhere with launching ISOs, homebrew and PS1 content.

Here's my updated build (Built using the last 3 commits): Custom_Firmware_Extender_3.1 MOD A8.zip

[badman12345]

Awesome! Thanks for the update. I'm going to give your newest build a try tonight. I wonder if he remembered to try some different iso drivers. My understanding is that streaming isos usually need to use OE Isofs, which no one ever uses anymore. I think a lot of newer games need to have the Isos patched to stream from the HD as well.

[Joel16]

Awesome! Thanks for the update. I'm going to give your newest build a try tonight. I wonder if he remembered to try some different iso drivers. My understanding is that streaming isos usually need to use OE Isofs, which no one ever uses anymore. I think a lot of newer games need to have the Isos patched to stream from the HD as well.

Madrid4ever reported that the ISOs still fail to load. I'm guessing it must be a problem with one of the loadexec functions then.

[badman12345]

Thanks for your effort! I'll give it a try tonight too, and then I'll try to do some more research.

By the way, I saw your cyanogenpsp homebrew. Impressive stuff dude!

[Madridi4ever]

@badman12345

First of all, thank you so much for your reply. I was starting to lose hope of anyone showing interest haha

Thanks for your comments, I think Joel16 addressed them. As he already told you, I did test the build, and I see no change at all (nothing worse nothing better). However, I did notice another issue, which I think is related to this same issue: try enabling usb remapping, then disabling it by clicking on it again, then enable it a second time. It won't work until you restart the psp again.

The same symptoms are shown with the build we have now. Technically, when you run a psp game, what it should do is disable the usb and reconnect, but the issue is that it never reconnects. Coincidence? I personally don't think so

As for the drivers, no that's not true about the OE drivers. In fact, I never used this particular driver lol. I always used to use NP9660 driver. In any case, to confirm, I do have my original PSP1000 with 5.00 M33 still installed with this plugin, and confirmed how it works there to compare the issues with 6.60/6.61 ME CFW, and yeah NP9660 works there.

I did however notice in the code that not all drivers are defined, which is to be expected since inferno driver for example is a new driver, but I expected the normal UMD driver (which requires you to have a umd in the drive) or NP9660 driver to work.

And yes I tried all drivers just in case I missed something but that failed lol

Whatever you can find will be greatly appreciated. If you want me to test anything as well I can do that

Thanks again