PS3 Project RSX Boost: Overclock your Retail PS3 RSX Speeds (ps3 cfw only)

zecoxao said:
PoC Release: USE AT YOUR OWN RISK
Testing Purposes Only
.​
https://www88.zippyshare.com/v/9UScoN3a/file.html

REBUG 4.84.2 D-REX OVERCLOCKED 600 750.

MD5

44c6ca7ab8a1b0174ee3a8f1fd64c823 PS3UPDAT.PUP_4.84.DEX-PS3UPDAT.PUP

Flash at your own risk.

@STLcardsWS
Click to expand...
Zwei said:
I have a doubt
is it possible to add COBRA 8.30 with all Evilnat tools in this rebug?
Click to expand...

You can manually replace the cobra , as you already have the 8.30 stage2.bin provided by EvilNat for Rebug 4.84.2
 
Last edited:
Zar said:
I was wondering if maybe we could underclocking the RSX / CPU ? to make it more stable as it should have less heat so less risk of YLOD ?
Instead of overclocking it which ofc it increases performance but also the risks of overheat/ylod...

I'm not an expert I'm just asking :p
Click to expand...
Im a bit afraid of overclockings too, but by now is hard to know the results, lets say... if the result of the overclock is just an increase of 1ºC or 2ºC (and there is no electrical degradation) then is completly worthy
And in the other way around applyes the opposite rule... if the result of an underclock is just a reduction of 1ºC or 2ºC then is not worthy at all because is relativelly easy to control that 2ºC by speeding up the fan a bit instead of underclocking it

Also, as far i understood there are 2 posible RSX/CORE speeds, and 4 posible RSX/VRAM speeds... this makes a total of 8 combinations
Probably some of that combinations doesnt makes sense because are not worthy... lets say... all them works but we are not sure which combination is the most optimal


EDIT:
Ohh well, if we count the default speeds we have 3 posible RSX/CORE speeds, and 5 posible RSX/VRAM speeds for a total of 15 combinations :D
 
Last edited:
In Managunz or wMM, to apply underclocks & overclocks semi permanently (until a new pup installation) with any valid combination of core/memory settings, one could write new code to extract CoreOS from Flash Memory, decrypt/unsign lv1.self, patch the elf, reencrypt/resign it, if ever the self file size is bigger, rebuild CoreOS & finally overwrite CoreOS in Flash Memory, with a post write hash validation check for good measure.

Applying overclocks/underclocks on the fly at runtime is more complicated, like ze mentioned before, restarting lv1 without reinitializing the entire memory and reloading the self from Flash Memory, consequently losing under/overclock patches, must be feasible but it would probably require one or more lv1 patches to be determined.
 
DEX357 said:
@aldostools is it possible in future to add this to webman mod in the form of a switch between stock and oc mode?
Click to expand...
Like I said, it is possible in theory but even if Aldo were inclined to include such a feature, it might be better to wait a little, see what conclusions we might draw from testers feedback before making this feature widely available to everyone.
Moreover wMM may not be the best target to implement this stuff, I think xai_plugin may be a better candidate.
 
bguerville said:
In Managunz or wMM, to apply underclocks & overclocks semi permanently (until a new pup installation) with any valid combination of core/memory settings, one could write new code to extract CoreOS from Flash Memory, decrypt/unsign lv1.self, patch the elf, reencrypt/resign it, if ever the self file size is bigger, rebuild CoreOS & finally overwrite CoreOS in Flash Memory, with a post write hash validation check for good measure.

Applying overclocks/underclocks on the fly at runtime is more complicated, like ze mentioned before, restarting lv1 without reinitializing the entire memory and reloading the self from Flash Memory, consequently losing under/overclock patches, must be feasible but it would probably require one or more lv1 patches to be determined.
Click to expand...

The method described is the proper way, but a lighter method would be to patch in flash memory the lv1.self already patched and re-signed. It would be matter of find the correct offset and write around 1.1 MB to flash memory.

BTW I just implemented a new storage device sector dumper / sectors viewer in /getmem.ps3mapi

it currently works in read-only mode, so it should be helpful for developers.

I was thinking in implement a write mode, but I think it would be too risky to make such functions available to everyone.

upload_2022-3-24_12-59-0.png


EDIT: In my flash dump, the offset of lv1.self is found at 0x19E990
 
Last edited:
aldostools said:
The method described is the proper way, but a lighter method would be to patch in flash memory the lv1.self already patched and re-signed. It would be matter of find the correct offset and write around 1.1 MB to flash memory.

BTW I just implemented a new storage device sector dumper / sectors viewer in /getmem.ps3mapi

it currently works in read-only mode, so it should be helpful for developers.

I was thinking in implement a write mode, but I think it would be too risky to make such functions available to everyone.
Click to expand...
Using ready made lv1 self files is possible of course but that may require keeping a library of lv1 files for various CFWs depending on what hard coded patches were applied, we would need to compare the various customized 4.8x lv1.elf files available out there and if there are differences, write a reliable detection algo. We may also need to take into consideration any homebrew that might patch lv1 self in Flash Memory, not a common practice but still to be confirmed, I am thinking about specific homebrews, maybe ccapi or sen enabler which may or not implement such mods.

sys_storage syscalls read/write sector by sector so replacing just the lv1 self isn't usually possible without having to rebuild both the start & end sectors of the lv1.self sector range.

Also there's the potential issue of the self file size change which may imply rebuilding CoreOS anyway.

And I agree, custom Flash Memory patching with user provided data & no frame of reference for validation would be very risky IMHO. I wouldn't touch this with a barge pole personally.
 
Last edited:
bguerville said:
In Managunz or wMM, to apply underclocks & overclocks semi permanently (until a new pup installation) with any valid combination of core/memory settings, one could write new code to extract CoreOS from Flash Memory, decrypt/unsign lv1.self, patch the elf, reencrypt/resign it, if ever the self file size is bigger, rebuild CoreOS & finally overwrite CoreOS in Flash Memory, with a post write hash validation check for good measure.

Applying overclocks/underclocks on the fly at runtime is more complicated, like ze mentioned before, restarting lv1 without reinitializing the entire memory and reloading the self from Flash Memory, consequently losing under/overclock patches, must be feasible but it would probably require one or more lv1 patches to be determined.
Click to expand...

zecoxao said we could just poke lv1 see here: https://www.psx-place.com/threads/p...your-retail-ps3-rsx-speeds.36801/#post-327070
 
Zar said:
zecoxao said we could just poke lv1 see here: https://www.psx-place.com/threads/p...your-retail-ps3-rsx-speeds.36801/#post-327070
Click to expand...

You might want to read on and check what he said on the subject after that post though..

Personally I don't know either how to restart lv1 without clearing the memory, including any poke that may have been applied, and reloading lv1.self from the Flash Memory.
There could always be a trick I am not aware of, if anyone knows a way then by all means share it, but as things stand at my end, I am assuming that it might still be doable but possibly require extra patches, some reversing of the lv0/lv1 init procedure would be needed to answer those questions.
 
bguerville said:
You might want to read on and check what he said on the subject after that post though..

Personally I don't know either how to restart lv1 without clearing the memory, including any poke that may have been applied, and reloading lv1.self from the Flash Memory.
There could always be a trick I am not aware of, if anyone knows a way then by all means share it, but as things stand at my end, I am assuming that it might still be doable but possibly require extra patches, some reversing of the lv0/lv1 init procedure would be needed to answer those questions.
Click to expand...

This syscall reboots the system unloading only LV2 without erase LV1:
{system_call_3(379, 0x8201, NULL, 0);} /*load LPAR id 1*/

By the way, @TheRouLetteBoi posted in my github a test version of his VshFpsCounter.sprx
https://github.com/aldostools/webMAN-MOD/issues/636#issuecomment-1078177051

If it works, I think it can be useful for comparison.

EDIT: The VshFpsCounter.sprx by @TheRouLetteBoi works very good
 
Last edited:
My bad, I though it was a permanent patch from the poke on lv1, that's why I asked. I didn't see the next post about the reset mem.

(Just like it's done on with "hdd freespace unlock" app by 3141cards, it's just a poke on lv2 but it's permanent)
 
Last edited:
hi, who can try with demon soul? sometimes the games have big slowdown (on 2nd stage with lot of flying creatures).
no way for use application on every cfw for overclock?
 
Hmmm, im figuring a test that could be handy to see the performance of the RSX VRAM chips
In the last Metal Gear Solid games published for PS3 there is a very notable problem, it happens if you move on to to top of some building/mountain, then use the snipper rifle with max zoom to aim to a different place very far away from you (lets say, the tip of other mountain)... then turn around and do the same in other direction

What happens inmediatly when you look with the snipper rifle is you are going to see the graphics with the quality of a PS1 (just a bunch of rough polygons and the textures completly blurred)... but if you stay quiet looking at the same place they starts "popping" 1 or 2 seconds later, lol
That delay is huge... it was something aceptable because the performance of the RSX is limited and because there is no other way to do it in the PS3 but i guess this delay is completly dependant of the speed of the RSX VRAM chips
You know, is a matter of loading textures as fast as posible, probably the same test works in lot other games, but the game engine of the metal gear solid was on the limits with that

And for the RSX CORE speed maybe could be better to use another game where there is lot of calculations of collisions in between polygons... dunno... in a Grand Theft Auto with infinite life and rocket launcher in a highway causing the hugest chaos posible


EDIT:
The first test with the snipper rifle is nice because you can repeat exactly the same in different gaming sessions and measure the time of that delay very well
The second test is not so good because the amount of chaos you are going to cause in a highway with a rocket launcher is random... is imposible to do exactly the same in different gaming sessions, it should work for a comparison but is a bit orientative, not an exact result
 
Last edited:
Maybe with OC'ed PS3 someone can implement graphics improvements such as nearest neighbour filtering ( little brother Vita already has this )
 
i could try demons souls but i'm pretty sure the fps rate would be locked to 30fps (i've tested on other games but only pes 2018 and fifa 21 are in 60fps)
 
You must log in or register to reply here.

Similar threads

Back
Top