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

Attachments

  • IMG_20250415_212227.jpg
    IMG_20250415_212227.jpg
    1.6 MB · Views: 191
Can some get me the 4.92 Evilnat 700mhz/900mhz OC? I have tried modifying it myself but I am having trouble to find the "Temp" paste on my PC, I would have to format my pc I guess, but I wanna push it for later. So, is there a kind soul that would save me the trouble?

Thanks

EDIT**

Just found @Mitsu™ 's post sharing multiple cfw OC's. Thanks buddy, I appreciate it.
 
Last edited:
Earlier I also mentioned that a little more contact pressure can work wonders
If your Temps are in that range the "standart" Evilnat OC 600/750 schould not that Problem
Thank you!
Where can we find that version of OC with 4.92 evilnat? :victorious::cheerful:
 
I dont think there is "that" 4.92 OC cfw from Evilnat
that was just a thing at the 4.90 now you may have to find one with the right clocks ore make one.
One page back is a link to be found from Mitsu ,a nice collection.

Thank you!
Where can we find that version of OC with 4.92 evilnat? :victorious::cheerful:
 
Haven't been keeping up with this thread, but thought I should post a few things.

1st. Higher frequencies lead to more work, which means more current, which means more heat. I tracked this in my own tests which I've not had a chance to compile and post yet. But there is a quite obvious trendline in which heat scales with CORE frquency increases. VRAM OTOH doesn't contribute to the heat until it reaches a stability threshold, then skyrockets. I'm not sure what to make of this yet. Might be thermal transfer, might be architectural...IDK.

***EDIT***
I just realized why this happened. When I first started testing I had the testbench console laying flat against the table, which restricted airflow to the Fan. There were about 4 early measurements like that before I started propping it up so more air can get in unhindered. I'm glad I recorded video so I could review it after noticing a strange trend in the data like that. There were several odd data points where the temps were significan;tly higher without seeming explanation. They all has that in common. It was not getting enough air and heating up more because of it. It wasn't that the VRAM was getting hot nearing the highest frequency.

I'm redoing those measurements now so that the data is accurate and comparable.*****

2nd. The extra work being done will increase the destructive effects of electromigration. The forces applied on the actual traces and transistors inside the die due to the increased activity of electrons passing through them...or more accurately, the electromagnetic fields...causes a breakdown in the circuit. The copper can deform and break, leadi g to an open fault. The dielectric walls that separate them can be broken through and traces short. This process takes time and when we increase frequencies and/or voltage, this time is shortened.

So 100% fact, OVERCLOCKING WILL SHORTEN THE LIFE OF YOUR PS3.

Yes, I agree, I'm not an expert but I can share my experience: I had a PS3 Slim 2100 (NTSC, bought it used), I installed the CFW with overclock (Evilnat 4.89, the one that increases just 100 MHz to the RSX and the VRAM), I kept the temps at max 72 °C with the software fan control, I cleaned it and repasted it with Artic MX-4 (I didn't delid it though, because previously I failed a delid of a Slim 2500), I didn't play much and not with very demanding games like God of War 3 or Uncharted 3, I used it mainly to play Retroarch, simple SNES games, PS1 games and some old Capcom Arcade games, everything looked good, but then one day I wanted to play Retroarch and the PS3 didn't work, it got the YLOD. ☹️ , that was in 2023. I don't have the PS3 anymore.

So, yes, like Felix said, overclocking is not 100% safe.
 
@RIP-Felix, how does the voltage increase work? @Evilnat is studying the possibility of adding it, at least for testing purposes via XAI, alongside Core/Memory adjustments on the fly. What are the risks?

Isnt writting to eeprom too dangeroes? Can it lead to bricks?
 
The VID Tables map the Hex value needed to program the SYSCON EEPROM to select the coresponding voltage for mullion or sherwood syscon. Be sure to use the correct table for your model of PS3.

SYSCON EEPROM Addresses these apply to:
Sherwood = 0x51 (RSX) | 0x50 (CELL)
Mullion = 0x3111 (RSX) | 0x3110 (CELL)

Note: The default value is FF on retail consoles. Writing FF to these address's will revert Core voltage to stock. The 01_patch_rsx_oc.tcl file is a modified version of the dropdown in MFW Builder, which adds more overclock timings. Place it into the "tasks" folder of MFW Builder, overwriting the one in there. Since it adds so many more combinations it may take a few seconds longer for the dropdown to appear after checking the box to enable the overclock. However, if evilnat is going to implement these into his CFW then he should double check we got all the timings written correctly. I think a few of them were reported to revert to stock, meaning we didn't. I haven't looked into this.

About brick risk. If you go too high or low the console will YLOD wit SYSCON core voltage errors, like 1001/1002, or potentially 3003/3004 (cell/RSX respectivily, depending on which you are changing voltage of. This can cause a SOFT Brick, preventing you from using software from unbricking, hoever, you can still revert the changes in EEPROM using UART directly. I would recommend anyone doing this to route these syscon wires out the console to make hooking up a UART easy without having to disassemble afterwards.

It's pretty safe otherwise. The real risk is overclocking too high and not being able to complete an update. If this new method makes it possable for you to do this quickly from XMB, that's better, because it takes time for an update to complete and heat can cause instability before that can occur. So a faster method to apply these LV1 changes in FW will make overclocking "safer," but I won't go as far as to say safe. I would like to try these methods out for myself if possible.
 
Last edited:
RSX core and memory clock lv1 pokes have been tested on superslim and do work. I am currently testing now and have added new oc options to xai for next beta.

Edit: yes, BadHTAB is required ;)
I need to buy a super slim asap. I have a 40nm super slim, but need a 28nm.
 
@RIP-Felix Can you confirm if your table worked on super slim? Consider that we can overclock 28nm now maybe its worth a research.

Also, superslim 40nm and 28nm use a bit different controller chip, pin count is different

40nm = ISL6332MDRZ
28nm = ISL6332ADRZ

IDK, haven't tried to OV a SS yet, but I think it's the same. I did pick up a 28nm model in anticipation for this, but havent followed it closely. I am super interested to try it tho. So I'll try if I can figure out how to do this.
 
Back
Top