PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

[Pacorretaco]

Frankenstein Phat PlayStation 3
(How to Swap an unreliable 90nm RSX with a more reliable 65nn or 40nm)

I hate being the guy saying this, but this is one of the reasons why things sometimes go wrong:
People read "swap unreliable 90nm RSX with more reliable 65 or 40nm RSX" and start forming ideas and expectations in their minds that may not necesarily be down to reality.
"Unreliable" and "more reliable" are dangerous words. Honestly I don't like them there. Even if you did an excellent job.

well this was an unexpected development! just read through the last 80 pages, and now the dream of upgrading my cecha12 with a 40nm gpu seems to have none from a big cope, to very likely to happen in the near future.

does anyone believe that they will be able to make the syscon compatible with replacement (or ideally 65/40nm) cpu's? iirc that was the main obstacle to resurrecting many ylod systems.

if my system can eventually be upgraded to become truly bulletproof i will be a very happy bunny.

Yes, perhaps now it may be possible to perform these RSX swaps. But this is just a wonderful new path for troubleshooting or repair. Doesn't mean all RSX should be replaced. It is not an "upgrade"!
Replacing RSX with different one is still not magic. Not only it is a very complicated procedure that can go very wrong, but you are still left with an incredibly complicated machine with many different points of failure. Including the RSX again!

If you think it is just a way to make the whole machine "bulletproof" then think again. This is giving "tokin replacement" vibes... Taking things out of context can be dangerous.

Especially considering that now it is still soon to talk about reliability. Just ask @truemaster and his succesful frankenstein. I am sure DeadEnd did the best possible job, but still that didnt stop the machine from giving problems a while later. Fortunately I think everybody understood the risks from the beginning there.
Or the original frankenstein from Sony that icferrum had and spawned this thread... Which was still giving graphical artifacts

Without even talking about the possible failures, even for experienced technicians...

Something interesting has been happening with my first Frankenstein!!
65nm on a COK-002. All done by the book.
It booted fine after setting it all up.
After 3rd boot this morning it threw the YLOD. Syscon log showed 3013/2120. I replaced the RSX again with a fresh CXD2991 and it booted again. Until 3rd boot it YLOD again ‍
It seems to be frying the RSX's
It has done it 3 times now.
It's either 3013/2102 and or 2120,2120 has never been related to the HDMI IC for me as the SONY chart says,its always been the RSX but I removed the HDMI IC just to double check but went back to 2102 without it,telling me that the RSX is fried. 2102 has always been a dead RSX for me.
I'm going to convert this unit back to a 90nm and try again on the next one and hope that it's just a one off. Tried converting back and no joy. Since I have tried converting to a 40nm and get 3013/2120 again which in my experience is telling me the RSX is no good.
It's chewing into my 65nm RSX's lol
Will try again tomorrow with a different RSX
Keep in mind I have 1000's of reballs under my belt so i'm not a newbie fooking things up

Should be as reliable as a slim now...fingers crossed!

So yeah... Emphasis on "fingers crossed" hehehe

 

[Pacorretaco]

Also @RIP-Felix I remember you also had a successful RSX swap but sadly PS2 mode was not working

What happened with that? Still a mystery?
Have you considered removing the modchip and trying to do it the other way with the EEPROM patch?

 

[Pacorretaco]

What 2 methods are electrically identical?

(A) View attachment 36386 (B) View attachment 36387

How are the above methods (A) and (B) electrically identical?

I'm not sure i understand what you mean.

Because a bridge wire allows the current to by-pass the filtering caps.

The photos below, with bridge wires, aren't filtering out the AC noise, because current, like water will just take the path of least resistance. In the photos below, the current just crosses over via the bridge wires. Why even have filtering capacitors in that case?

View attachment 36389 View attachment 36391

I am no Electrical Engineer, and maybe this would be more relevant in the Tokin thread, but I think the reason they are electrically the same, is that the "capacitor" itself is the low-impedance path to ground for the interference.

Otherwise if the wire made any difference, then why wouldn't the noise do something like this?

 

[truemaster]

as for my self the factory 90nm rsx did have problems. although i and @DeadEnd didnt though what cell was at the last leg. that much was confirmed by @vyktormvmpay25 after he willing to see my board that glod with error 2031 we though rsx solder points were gone bad again. so before atempting to fix a ylod cok-001 or cok-002 see if cell has life left. otherwise do a good reflow with temprature mesurements and let it alone

 

[RIP-Felix]

@Workz_777 the current is not supposed to go through the capacitor. The capacitor is in parallel with the current and only the noise will bypass the processor by taking the path of least resistance through the capacitor.

Does that make sense?

 

[RIP-Felix]

Also @RIP-Felix I remember you also had a successful RSX swap but sadly PS2 mode was not working

What happened with that? Still a mystery?
Have you considered removing the modchip and trying to do it the other way with the EEPROM patch?

It's on the list of projects I need to revisit. I have 2 more consoles I want to attempt a 40nm swap on first.

 

[RIP-Felix]

I hate being the guy saying this, but this is one of the reasons why things sometimes go wrong:
People read "swap unreliable 90nm RSX with more reliable 65 or 40nm RSX" and start forming ideas and expectations in their minds that may not necesarily be down to reality.
"Unreliable" and "more reliable" are dangerous words. Honestly I don't like them there. Even if you did an excellent job.


Yes, perhaps now it may be possible to perform these RSX swaps. But this is just a wonderful new path for troubleshooting or repair. Doesn't mean all RSX should be replaced. It is not an "upgrade"!
Replacing RSX with different one is still not magic. Not only it is a very complicated procedure that can go very wrong, but you are still left with an incredibly complicated machine with many different points of failure. Including the RSX again!

If you think it is just a way to make the whole machine "bulletproof" then think again. This is giving "tokin replacement" vibes... Taking things out of context can be dangerous.

Especially considering that now it is still soon to talk about reliability. Just ask @truemaster and his succesful frankenstein. I am sure DeadEnd did the best possible job, but still that didnt stop the machine from giving problems a while later. Fortunately I think everybody understood the risks from the beginning there.
Or the original frankenstein from Sony that icferrum had and spawned this thread... Which was still giving graphical artifacts

Without even talking about the possible failures, even for experienced technicians...



So yeah... Emphasis on "fingers crossed" hehehe

Yes, people need to realize this is not an upgrade - a mod they want to apply to a working console. It's a path forward for consoles with dead RSX. In the past you needed a working 90nm, which are harder to find and unreliable. The 65nm and 40nm are readily available and more reliable. I chose my words carefully!

 

[Computer Booter]

I personally do not have ANY data to show how reliable or long lasting a 40nm swap will or should last, as others have said there are many other problems that can occur on these systems other than the RSX. While I understand we should not use the term "upgrade" the only thing I will say is that the heat is significantly lowered compared to the 90nm so in that sense it is a nice "upgrade" but other than that, I cannot vouch for system longevity or stability. Users with a 40nm BCPS3 will have to find out by using the systems

As far as the tantalum replacements, Id say the tantalizer would be the best option to replace them, as for the bridge wires I was under the impression that it is identical (electrically) to the original setup. The NEC Tokins have an internal bridge which the bodge wire restores. I guess I can see that since the bodge wire is outside of the Tantalums and not internally that it could be different. I have no idea or input on this matter, I am just going by how I know how to install them. If there is a better way and it works I would have no problem installing in that way. Id rather just use Tantalizers but from what I can see it would add significantly to the install time and also costs.

 

[Workz_777]

Deleted (wrong thread)

 

[Workz_777]

Deleted (wrong thread)

 

[Pacorretaco]

But a bridge wire has no resistance, compared to the route that flows past the filtering capacitors. It's the bridge wire that has the lowest impedance in this case.

And that's where I think the misconception lies.

First of all the bridge wire is already there even in your design.
And the reason why this is not a problem is that the capacitor has an even lower impedance to ground, so that is the path that the AC noise takes. It is going through the capacitor but it is not going through the bridge wire and the IC. At least that is how I understand it

 

[Workz_777]

I've delete all those NEC/Tokin posts i made here, i shouldn't have posted them here anyway, it's not the right thread, i'm sorry please excuse me for that, i made a mess of this thread.

 

[blckbear_]

And that's where I think the misconception lies.

First of all the bridge wire is already there even in your design.
And the reason why this is not a problem is that the capacitor has an even lower impedance to ground, so that is the path that the AC noise takes. It is going through the capacitor but it is not going through the bridge wire and the IC. At least that is how I understand it

That's more or less how it works yes (electrical engineering student here, I guess better than nothing lol). The capacitors work in two different ways, and that depends on what type of current you're using (AC or DC). Digital signals are all DC, and noise present on digital signals can be interpreted as an AC current superposed on the DC signal. Capacitors, when presented with DC current, they charge up for an amount of time and then current stops flowing into them because they're already charged, similar to filling a water bottle to the top. But when presented with AC, capacitors in series act as a conductor because when AC passes through them you're charging and discharging them, thus the capacitor is a path for AC to go through.

So in the circuits shown, as @RIP-Felix said, they're identical, as a conductor in parallel to the already existing conductor is the same as one conductor, they're both connected to the same stuff (both the trace and the added wire connect the source to the IC's pin with the cap in the middle going in series to ground). So to summarize, both circuits are the same and both work as the AC current (the noise) finds a path to ground through the capacitor while the DC signal is stable on the IC's pin.

Noise reduction caps are not an obstacle to the noise, but an alternate (and better) route for the noise to go through instead of going to the IC's pin, so whenever a conductor that carries noise has an alternate route for it (the cap in this example) it should work the same.

 

[DeadEnd]

Yes necesarily and yes always, that's the thing. That's why it is a little ambiguous hehehe.

Because the BitTraining is always done by the CPU. There is no "RSX bittraining" because it is something that goes both ways.
It happens Not only between the CPU and the RSX, but also between the CPU and the Southbridge.

That's why 3034 alone is not deterministic information. Not enough. Now if you look at the bringup sequence, there will be some more useful details, and maybe RSX mentioned along with associated 44xx error if it is CPU<--->RSX bittraining. Sometimes even more useful details (Like in FLEXIO_ID case)

But still there is that little ambiguity. The hamburger loving friend (RSX) is being called but not answering properly. Maybe he finally had his cardiac arrest. But maybe he is alive and his phone is just broken... Maybe somebody cut the wires. Or maybe your own phone is broken? Maybe you have gone deaf from that ear? (CPU)
You knew his hamburger habit was going to end badly soon... But after all he also had a habit of dropping his phone a lot with his greasy fingers... Hmm...

Paco, do your research more carefully. Bittraining is not always done by CPU. Each component does its own https://www.psdevwiki.com/ps3/Rambus_Registers#RSX_RRAC_Registers

 

[DeadEnd]

I hate being the guy saying this, but this is one of the reasons why things sometimes go wrong:
People read "swap unreliable 90nm RSX with more reliable 65 or 40nm RSX" and start forming ideas and expectations in their minds that may not necesarily be down to reality.
"Unreliable" and "more reliable" are dangerous words. Honestly I don't like them there. Even if you did an excellent job.

Imho it would be more reliable if the machine is not overused and is in good condition originally. New RSX also has to be in good condition (preferrably new). I also want to point that soldering RSX with lead free solder back to the board is not a good idea. The board is quite fragile to high temperatures over 200 degrees, so you are always taking the risk of frying/popping something else.

 

[Pacorretaco]

Paco, do your research more carefully. Bittraining is not always done by CPU. Each component does its own https://www.psdevwiki.com/ps3/Rambus_Registers#RSX_RRAC_Registers

I would like a 3rd person opinion on that, or a better explanation to help me see what you are seeing...

So the CPU is not always involved in our bittraining? How is that?

 

[DeadEnd]

I would like a 3rd person opinion on that, or a better explanation to help me see what you are seeing...

So the CPU is not always involved in our bittraining? How is that?

Well what you said made it sound like only CPU is taking care of Bittraining for every other component. In reality they all do their own training. CPU does its own, RSX does its own, SB does its own. The link is linking to the RSX Bittraining section, but there are others if you scroll to the beginning.

 

[Pacorretaco]

Well what you said made it sound like only CPU is taking care of Bittraining for every other component. In reality they all do their own training. CPU does its own, RSX does its own, SB does its own. The link is linking to the RSX Bittraining section, but there are others if you scroll to the beginning.

Well If made it sound like that is because that is what I thought.
The bittraining happens between the CPU and RSX and between the CPU and SB.

Just because there are those descriptions there mentioning RSX or SB doesn't mean they are doing it on their own.
Or at least that's how I understood it.

If I am wrong I am happy to learn but I'd like to hear from @sandungas or @M4j0r

 

[DeadEnd]

Well If made it sound like that is because that is what I thought.
The bittraining happens between the CPU and RSX and between the CPU and SB.

Just because there are those descriptions there mentioning RSX or SB doesn't mean they are doing it on their own.
Or at least that's how I understood it.

If I am wrong I am happy to learn but I'd like to hear from @sandungas or @M4j0r

@M4j0r was my source for this information. But you can hear it from him too if it helps...

 

[M4j0r]

Because the BitTraining is always done by the CPU. There is no "RSX bittraining" because it is something that goes both ways.
It happens Not only between the CPU and the RSX, but also between the CPU and the Southbridge.

Paco, do your research more carefully. Bittraining is not always done by CPU. Each component does its own https://www.psdevwiki.com/ps3/Rambus_Registers#RSX_RRAC_Registers

I would like a 3rd person opinion on that, or a better explanation to help me see what you are seeing...

So the CPU is not always involved in our bittraining? How is that?

Well what you said made it sound like only CPU is taking care of Bittraining for every other component. In reality they all do their own training. CPU does its own, RSX does its own, SB does its own. The link is linking to the RSX Bittraining section, but there are others if you scroll to the beginning.

Well If made it sound like that is because that is what I thought.
The bittraining happens between the CPU and RSX and between the CPU and SB.

Just because there are those descriptions there mentioning RSX or SB doesn't mean they are doing it on their own.
Or at least that's how I understood it.

If I am wrong I am happy to learn but I'd like to hear from @sandungas or @M4j0r

@M4j0r was my source for this information. But you can hear it from him too if it helps...

Syscon is the calibration master and CELL, RSX, SB all take part in the calibration process, of course in conjunction with the connected chip, but not coherently. Just from the name "interface calibration" it's easy to tell that not the link but the interface gets calibrated. So each chip can do it on it's own, but I guess that's not what the starting question is about.
Syscon first handles the CELL <-> SB link and then the CELL <-> RSX link - it'll ask SB and RSX if everything went fine. If yes it'll ask CELL if the links are good.