PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

[RIP-Felix]

Okay, I'm posting these custom fan tables for a 40nm on a COK-001. I have used them, but haven't done extensive testing. @David Rainer want's to try it. Just know that theses are experimental and NOT OFFICIAL!

fantbl setini 0 p0 00.00 64.00 0x33
fantbl setini 0 p1 60.00 65.00 0x40
fantbl setini 0 p2 61.00 66.00 0x48
fantbl setini 0 p3 64.00 67.00 0x4d
fantbl setini 0 p4 65.00 68.00 0x5a
fantbl setini 0 p5 66.00 69.00 0x66
fantbl setini 0 p6 66.50 70.00 0x73
fantbl setini 0 p7 67.00 71.00 0x80
fantbl setini 0 p8 67.50 72.00 0x99
fantbl setini 0 p9 68.00 75.00 0xff
tshutdown setini 0 85
fantbl setini 1 p0 00.00 53.00 0x33
fantbl setini 1 p1 48.00 54.00 0x40
fantbl setini 1 p2 49.00 55.00 0x48
fantbl setini 1 p3 53.00 56.00 0x4d
fantbl setini 1 p4 54.00 57.00 0x5a
fantbl setini 1 p5 55.00 58.00 0x66
fantbl setini 1 p6 55.50 59.00 0x73
fantbl setini 1 p7 56.00 60.00 0x80
fantbl setini 1 p8 56.50 65.00 0x99
fantbl setini 1 p9 57.00 70.00 0xff
tshutdown setini 1 75
r 34fe 2
eepcsum
w 34fe 29 da

Here are the default 90nm tables for the COK-00X in case you want to revert:

fantbl setini 0 p0 00.00 74.00 0x33
fantbl setini 0 p1 60.00 75.00 0x40
fantbl setini 0 p2 61.00 76.00 0x48
fantbl setini 0 p3 67.00 77.00 0x4d
fantbl setini 0 p4 68.00 78.00 0x5a
fantbl setini 0 p5 71.00 79.00 0x66
fantbl setini 0 p6 71.50 80.00 0x73
fantbl setini 0 p7 72.00 81.00 0x80
fantbl setini 0 p8 72.50 82.00 0x99
fantbl setini 0 p9 73.00 85.00 0xff
tshutdown setini 0 85
fantbl setini 1 p0 00.00 83.00 0x33
fantbl setini 1 p1 48.00 84.00 0x40
fantbl setini 1 p2 71.00 85.00 0x48
fantbl setini 1 p3 77.00 86.00 0x4d
fantbl setini 1 p4 78.00 87.00 0x5a
fantbl setini 1 p5 80.00 88.00 0x66
fantbl setini 1 p6 80.50 89.00 0x73
fantbl setini 1 p7 81.00 90.00 0x80
fantbl setini 1 p8 81.50 91.00 0x99
fantbl setini 1 p9 82.00 95.00 0xff
tshutdown setini 1 95
r 34fe 2
eepcsum
w 34fe 15 71

To use them just copy the contents and paste into the CMD terminal.

EDIT: I just noticed that the above commands end up changing the checksum at 34fe. The last line in those will not run the write to fix the checksum until you hit enter. So double check that the checksum should be what I have written or change it.

The SYSCON changes for the new method of installing a 40nm could change what this checksum should be. I'm not sure. So just double check before hitting enter on the last line when the string stops executing these sequentially.

 

[vyktormvmpay25]

Was about to ask what is the best fantbl for this mod. I got one working those days that will be sent to USA that I have from January here. Need to complete cure process and assembly for final test. I'll add example of measurement in faulty findings thread and rest of thermal config I'll discuss with sandungas on his thermal thread.
Edit updates
Just take it as reference, measurements can differ from board, rsx, cell, etc
https://s.go.ro/joj7tp6d
I just don't work on boards with lower resistance on cell under 2.7 ohms.
Made my statement and won't change my mind.

 

[RIP-Felix]

So we don't know yet. I know that @sandungas has been recording and studying the thermal config of various boards. He may have a better idea of the "official" curve we should be using.

Maybe mimicing the curve from a slim? My concern with that is slim has a completely different heatsink and case. So it's thermal response would not perform the same in a COK-00X Case. Because of that I think we are in uncharted terretory and will have to develop our own curve.

I will say that the CPU dominates this process. It's heat is the limiting factor for temps vs noise. And it will refuse to be kept under control at a reasonable fan noise level.

I set the max CPU temp at 75C and thermal shutdown at 85C. I based that more off my own preferrences from PC fan curves and what seemed reasonable given the fan noise (with stock fan, not the D14F or 19-blade). There is a lot of room here for improvement and experimenting. But it's easy to just modify the code to try something new.

 

[Workz_777]

I just don't work on boards with lower resistance on cell under 2.7 ohms.
Made my statement and won't change my mind.

So CELL VDDC under 2.7 ohms and CELL VDDC over 4.7 ohms = no good?

I have a SEM-001 CELL VDDC that reads 5.1 ohms, and a DIA-001 CELL VDDC that also reads 5.1 ohms. What should i make of this? Are these CELL(s) on the border of needing a re-ball, or no?

I have a 2nd SEM-001 that i'm aiming to read its resistances soon, will let you guys know. I also have a 90nm, 65nm RSX (off board) so would like to read / measure their points to help add to the data-pool of RSX (off board readings) ...i'm still waiting on the 40nm RSX to arrive, was told it was NOS but then later told it was used. If / when it arrives will aim to post it's measurements, is this the correct thread for that?

 

[vyktormvmpay25]

Dang Felix greate support this youtube from now

Ive tried to do this for so long @David Rainer .We thank you so much you show people how is done!
You will reach for sure as good as factory with that jig and bound back etc...
Please use as well my new profile ive send you https://s.go.ro/kt24bxhc
if i dont catch to much with streams ill send photos for jig modifications to match for cok boards,it is acctualy for sem 001 but will match after few adjustments.
edit
Not sure if i added this as mini tutorial ,ill add again as referance so anyone is free to adapt by any thermal compounds they think or like
https://s.go.ro/93xitgz7

 

[RIP-Felix]

Victor is talking about VDDC of slim model MB. The way I read it, he just doesnt want to chance it on a CPU below 2.7 ohms. And didn't you say @vyktormvmpay25 that you warrany your repairs for redulously long period of time?

I think that's why he has to be so picky. In europe the PS3 was more popular. I guess that also means he can reject more consoles, since he's not hurting for business. Just seems wiered that anyone can make a living reballing slims. They are so cheap why not just buy another one?

Or maybe that's just in the US? Over here the BC models are the only desirable ones. The idea of anyone here going to the lengths victor does for a slim is crazy.

 

[Workz_777]

Victor is talking about VDDC of slim model MB. The way I read it, he just doesnt want to chance it on a CPU below 2.7 ohms. And didn't you say @vyktormvmpay25 that you warrany your repairs for redulously long period of time?

I think that's why he has to be so picky. In europe the PS3 was more popular. I guess that also means he can reject more consoles, since he's not hurting for business. Just seems wiered that anyone can make a living reballing slims. They are so cheap why not just buy another one?

Or maybe that's just in the US? Over here the BC models are the only desirable ones. The idea of anyone here going to the lengths victor does for a slim is crazy.

Ahhh, right, phew lol. Yeah, Sony never gave us the CECHAxx x in Europe, instead we got the PS1 / PS2 emulation model CECHCxx. Why??? I really wish i knew. Why did USA and Asia (CECHBxx) get the real BC PS3 and Europe got the emulation model instead. Sony doesn't like Europe maybe?

 

[vyktormvmpay25]

Right @RIP-Felix slims are cheap here as well but also becoming hard now to get,wont fix many ps3 this year imo.That condition for VDDC on CELL side is also for COK001/002.
Again dont follow to much my opinion ! Everyone is free to take his time with lower then 2,7 ohms cell resistances on any board.
I just shared what i do to them to work, I dont state anyone to follow exactly what I do . All is just long time investmet,wasn't easy to reach ,but finaly makes that possible.
Edit I forgot to add VDDC for cell on this so i made quick one in same folder/link early posted
https://s.go.ro/b26gmj15
Cell somehow will deviate rsx measurements ,like all tied on board ,if one is lower will affect in time other one.

 

[DeadEnd]

Ahhh, right, phew lol. Yeah, Sony never gave us the CECHAxx x in Europe, instead we got the PS1 / PS2 emulation model CECHCxx. Why??? I really wish i knew. Why did USA and Asia (CECHBxx) get the real BC PS3 and Europe got the emulation model instead. Sony doesn't like Europe maybe?

On the contrary europe got a model that can output higher quality image for ps2 games than CECHA. I showed one comparison video on my channel. Also they most likely were losing too much money on CECHAs in the US and Japan so they decided to stick to cheaper but "improved" version for EU.

 

[truemaster]

@Workz_777 sony needed to reduce costs and thats why they put ee and rambus out. ps1 is emulation to all revisions. also cok-001 has a nasty bug that some ps2 will black screen if upscaling is on. on cok-002 this isnt happening.

 

[RIP-Felix]

On the contrary europe got a model that can output higher quality image for ps2 games than CECHA. I showed one comparison video on my channel. Also they most likely were losing too much money on CECHAs in the US and Japan so they decided to stick to cheaper but "improved" version for EU.

Whatever you have to tell yourselves. I agree it looks sharper, but it came at the expence of compatablility. I forget exactly how much less compatible the COK-002 was. I think the A/B models were like 95% ish, and the C/E models were 85% ish. I don't remember exact figures.

Does anyone actually know? Or are those compatibility charts actually wrong. I think I remember someone trying some games suppoedly on the incompatible list and all of the ones he tried worked. But did he play all the way through? What bugs exist? Why were they on the incompatible list in the first place? IDK.

I'm not sure there is a difinitive compatibiliy list. It may have just been based on reports, which are unreliable.

 

[sandungas]

Was about to ask what is the best fantbl for this mod. I got one working those days that will be sent to USA that I have from January here. Need to complete cure process and assembly for final test. I'll add example of measurement in faulty findings thread and rest of thermal config I'll discuss with sandungas on his thermal thread.

So we don't know yet. I know that @sandungas has been recording and studying the thermal config of various boards. He may have a better idea of the "official" curve we should be using.

Maybe mimicing the curve from a slim? My concern with that is slim has a completely different heatsink and case. So it's thermal response would not perform the same in a COK-00X Case. Because of that I think we are in uncharted terretory and will have to develop our own curve.

I will say that the CPU dominates this process. It's heat is the limiting factor for temps vs noise. And it will refuse to be kept under control at a reasonable fan noise level.

I set the max CPU temp at 75C and thermal shutdown at 85C. I based that more off my own preferrences from PC fan curves and what seemed reasonable given the fan noise (with stock fan, not the D14F or 19-blade). There is a lot of room here for improvement and experimenting. But it's easy to just modify the code to try something new.

I wrote a post to @marciolsf with my oppinion here
https://www.psx-place.com/threads/m...s-better-than-webman.34626/page-2#post-326269
The hardware solutions i mentioned are something i consider failproof since many years ago... actually the "PS3 fan acelerator" could be named "PS3 geek mind liberator", lol

The other suggestion to increae fan speeds only is something relativelly easy to do. Of course... modifying only the speeds from inside the thermal config can be considered something a bit "meh" but in the practise the result is pretty much the same than the hardware solutions i mentioned

To find the optimal configuration for an specific PS3 model (or a specific frankenstein combo) is really neeeded to do some temperature tests, this takes some time because is needed to keep a record of the temperatures "on real time" under different workload conditions. Lets say... at least at 3 different points
-Along the first 15-30 minutes inmediatly after booting from ambient (this is like a warmpup, where CELL is going to be pushing speeds up)
-Idle in XMB for a lot of time, idle inside a homebrew, or doing some light tasks, like web browsing, watching videos, dunno (half workload)
-Inside a very demanding game (full workload, we need to find the highest temperature "peaks" that are unestable by nature)

If some of you is interested in working with me into building "the definitive" thermal config for factory COK-001 (not frankie), or a COK-001 frankie 40nm RSX let me know, but this could take us some days, you will need to do some temperature tests, and write several versions of the thermal config to syscon... and is going to take me lot of time to calculate it, to explain some of the "rules" i found used by sony, and to explain my arguments about what im trying to achieve

 

[DeadEnd]

Whatever you have to tell yourselves. I agree it looks sharper, but it came at the expence of compatablility. I forget exactly how much less compatible the COK-002 was. I think the A/B models were like 95% ish, and the C/E models were 85% ish. I don't remember exact figures.

Does anyone actually know? Or are those compatibility charts actually wrong. I think I remember someone trying some games suppoedly on the incompatible list and all of the ones he tried worked. But did he play all the way through? What bugs exist? Why were they on the incompatible list in the first place? IDK.

I'm not sure there is a difinitive compatibiliy list. It may have just been based on reports, which are unreliable.

All I know is the compatibility lists online are rather outdated. They don't list ALL the games. And yeah, it's hard to tell if those people actually played through from the beginning to the end or just tested a few missions and called it a day. Some will work but there will be glitches. I know that Matrix Path of Neo is glitching on C models for instance, but works ok on A and there isn't any sharpness differences in it. So that can be a bit random.

 

[RIP-Felix]

How hard would it be to write a "themal test" program that queried the SYSCON for temps and fan % every few seconds and graphed the output? Preferrable over UART so the console doesn't have to be soft modded.

Or just spit the temps and % into a text file we could later graph

 

[vyktormvmpay25]

In Cok002 I remember I have automatic pulled temperatures constantly from SB uart without any commands. Test that when on XMB

 

[marciolsf]

How hard would it be to write a "themal test" program that queried the SYSCON for temps and fan % every few seconds and graphed the output? Preferrable over UART so the console doesn't have to be soft modded.

Or just spit the temps and % into a text file we could later graph

I was thinking about that last night... kinda the problem is that the python script (and the powershell one as well) are more of a "tunnel" to enable communications with syscon (@M4j0r correct me if i'm wrong). Once you connected in, you're talking directly with syscon and using its own language.

If we can modify it to accept parameters beyond [comm port] [CXR|CXRF], then it would be trivial to run the script on a loop, grab the output and stash it somewhere for reporting. I can probably wing that in powershell (now that someone ported the basic framework over), but i'm hopeless with python. I'm thinking it could, at its most barebones implementation, be something like

script.py [commport] [cxrf] [internal command]

and then it's up to the person running to pipe it out to a csv file. Something like

script.py [commport] [cxrf] [internal command] >> temp.csv

 

[sandungas]

How hard would it be to write a "themal test" program that queried the SYSCON for temps and fan % every few seconds and graphed the output? Preferrable over UART so the console doesn't have to be soft modded.

Or just spit the temps and % into a text file we could later graph

Hmmm thats a nice idea, i dont know almost anything about python but is pretty much as C language, i think this can be made with an infinite "for" loop containing a "wait" and the uart command/s "tmp get 0" etc... inside the loop

Some weeks ago i was trying to figure how works the python scripts related with syscon, because i was trying to see how to do a new script with only 2 features: "read thermal config to file" and "write termal config from file"
This would allow us to backup or restore the whole thermal config area in a single "click", and also allows to prepare the thermal config in a hexeditor in PC and share it with other people as a .bin file

Both things would be extremelly convenient to create custom thermal configs

In Cok002 I remember I have automatic pulled temperatures constantly from SB uart without any commands. Test that when on XMB

As far i remember it was because you was using webman in one of his dynamic fan speed modes, what you see in the SB debug screen is the "echo" of a syscon service named [SERV_THERM] that is pretty much telling:
[SERV_THERM] temperature requested by GameOS
[SERV_THERM] temperature requested by GameOS
[SERV_THERM] fanpolicy changed to manual 23% speed
[SERV_THERM] temperature requested by GameOS
[SERV_THERM] fanpolicy changed to manual 24% speed

The messages informing that the speed have changed happens only when needed (if webman decides is needed), but the others requesting the temperatures from the sensors happens every 3 seconds in a infinite loop
Anyway... that screen from the SB debug is not good enough for what we need because is going to contain lot of unrelated info, we just need to record temperatures and speeds in the most "clean" format posible because this kind of tests are going to take a good amount of time, so the file is going to be huge

Btw, as far i remember webman have a function that can record that temperature requests in a .txt file

 

[RIP-Felix]

Anyway... that screen from the SB debug is not good enough for what we need because is going to contain lot of unrelated info, we just need to record temperatures and speeds in the most "clean" format posible because this kind of tests are going to take a good amount of time, so the file is going to be huge

Btw, as far i remember webman have a function that can record that temperature requests in a .txt file

Well, we can change the wait time in the loop to 15s, 30s, or 1min. Depending on how much resolution we need in the graph. I think evey second would be needed to plot quick changes, but 10s would be enough to get a good idea of warmup and average temp once up to to temp.

 

[sandungas]

Well, we can change the wait time in the loop to 15s, 30s, or 1min. Depending on how much resolution we need in the graph. I think evey second would be needed to plot quick changes, but 10s would be enough to get a good idea of warmup and average temp once up to to temp.

In the tests with higher workload it would be needed to use a high resolution, like the 3 seconds i mentioned, and imo (as a experiment, im not sure if syscon is going to complain about receiving so many commands so fast) it would be interesting to reduce it to 1 second to try to see how fast are moving up/down the highest temperature peaks
But yeah, for the first tests we dont need that accuracy, the most important thing we need to find in the first tests is the difference of temperatures in between CELL and RSX (at different temperature ranges)
You know... using vehicles as example... we have a car (the fan) with 2 drivers (CELL or RSX) and we need to find who is driving the car... and adjust the "tempU" values to dont allow the same driver to drive the car all the time

Lets say... in the custom thermal config you posted here you reduced the "tempU" values for CELL and RSX... but the reduction for RSX is bigger than CELL... so is like you are making RSX more sensistive
The concept is fine, but we dont know very well "who is driving the car"

As a reference... if you take a look at the graphs i made... and you take the "tshutdown" values as reference (shown as a big dot at top of the graphs) you are going to see most/all PS3 models have a difference of around 5ºC-10ºC in between CELL and RSX at full workload

After the frankenstein RSX 40nm that difference should be reduced... but how much ? thats what we dont know
But this is relativelly easy to find in the first tests... just keep attention at the difference of temperatures in between CELL/RSX and ignore the fan speed, in this first test where our only goal is to find the difference of temperatures in between CELL/RSX the speed doesnt matters

 

[RIP-Felix]

Lets say... in the custom thermal config you posted here you reduced the "tempU" values for CELL and RSX... but the reduction for RSX is bigger than CELL... so is like you are making RSX more sensistive
The concept is fine, but we dont know very well "who is driving the car"

As a reference... if you take a look at the graphs i made... and you take the "tshutdown" values as reference (shown as a big dot at top of the graphs) you are going to see most/all PS3 models have a difference of around 5ºC-10ºC in between CELL and RSX at full workload

After the frankenstein RSX 40nm that difference should be reduced... but how much ? thats what we dont know
But this is relativelly easy to find in the first tests... just keep attention at the difference of temperatures in between CELL/RSX and ignore the fan speed, in this first test where our only goal is to find the difference of temperatures in between CELL/RSX the speed doesnt matters

CELL is definitely driving the car. The 40nm RSX produces so little heat the temperature zones that keep the cell under control actually keep the RSX way under. Adjusting the Cell curve more aggressively cools the RSX even further.

The only reason to adjust the RSX curve is so you know if/when its thermal paste goes bad. The temps will rise. If you have a lowered curve it won't have to rise as far before you notice the fans ramping up. This alerts you something is wrong sooner, at a lower temp.

The CPU curve should be adjusted just to keep the CELL within more reasonable sound/temp ratio. I personally don't like the fan noise above 30%. However, with the default SYSCON curve, fresh thermal paste on a delidded CELL, under the most intense load, the fan ramps to 33% to keep the CELL around 75C. The load is GTA5, which uses all available SPU's. Character standing on the shoreline with water physics/ripples in the foreground, buildings in the distance to push draw distance, reflections, and rendering calculations. Spinning around in circles to force the calculations to continuously refresh. And doing this for 15-20mins to heat saturate saturate the console, whose case is unmodified (no hole cut in the bottom!) and fully assembled to ensure correct airflow. 33% is pretty quiet. I can stand 40-44% under intense loads. But that's preference. So I adjusted the curve to keep the Cell as cool as possible without needing more than 40-44% fan (to suit my acoustic preference).

It's easy to do that using the temperature's on the fan tables, but you could just adjust the fan% too. I think @Pacorretaco mentioned that at some point. My issue is that they're not in plain English and I'm not sure what code to use for 1 - 100%. @sandungas Can you help me understand how to convert 0x33, 0x40, etc into fan %? I tried hexadecimal & ASCII to text converters online and they don't look right. Say I wanted 41%, what would that be? 0x41? What % is 0x4d? I'd like a table 1-100% and it's corresponding code so I can just use that.