Hacking So, what's up with SS3D and GW/PastaCFW?

[d0k3]

We all know that it happens: After booting up Gateway / PastCFW on a N3DS, super stable 3D no more works. Temporarily fixing it is just a minor nuisance, as it only requires you to close and open the lid.

What I'm interested in is, what is the technical reason behind the SS3D failure? In fact, any information helps!

Some more information: For GW, I always saw the SS3D failure as (unavoidable) collateral damage, as GW is closed source and (supposedly) does a lot of stuff in the background. The same can't be said for PastaCFW, though. PastaCFW, only patches two adresses in memory - that should be pretty precise and having the same "collateral damage" as GW just seems strange. With other words: the sig checks are at these two memory adresses, how can SS3D also be controlled from that?

So, any ideas?

 

[zoogie]

I don't think it's the sig checks causing the issue, it's probably the soft reboot not being handled right. Just a wild guess.

 

[cearp]

yeah karl3ds people said they encountered and fixed the issue i think, i guess gw didn't think it was worth the time trying to fix it.

 

[Kafke]

As Zoogie said, it's likely an issue with the soft rebooting of the system. IIRC, people mentioned that simply sleeping the console fixes the issue (albeit temporarily). So I'm guessing it just doesn't boot properly when reloading with the patches. If I had to explicitly say, it's probably something that's booted along with the rest of the system, and when you reboot, the SS3D doesn't boot and thus has issues. Sleeping the system and waking it would normally do that boot process for SS3D, and thus would 'fix' the issue.

So it doesn't seem as if the patching broke it, but the rebooting.

 

[Duo8]

There's a coprocessor that handles this. When launching the patched firm the launcher doesn't reset that coprocessor, which leaves it hanging in a weird state.

 

[d0k3]

I don't think it's the sig checks causing the issue, it's probably the soft reboot not being handled right. Just a wild guess.

As Zoogie said, it's likely an issue with the soft rebooting of the system. IIRC, people mentioned that simply sleeping the console fixes the issue (albeit temporarily). So I'm guessing it just doesn't boot properly when reloading with the patches. If I had to explicitly say, it's probably something that's booted along with the rest of the system, and when you reboot, the SS3D doesn't boot and thus has issues. Sleeping the system and waking it would normally do that boot process for SS3D, and thus would 'fix' the issue.

So it doesn't seem as if the patching broke it, but the rebooting.

There's a coprocessor that handles this. When launching the patched firm the launcher doesn't reset that coprocessor, which leaves it hanging in a weird state.

That's a very plausible explanation! I still wonder, why doesn't it happen in NTR CFW? I guess it's possible that NinjHax is the culprit after all.

 

[CIAwesome526]

That's a very plausible explanation! I still wonder, why doesn't it happen in NTR CFW? I guess it's possible that NinjHax is the culprit after all.

nope. i used LoZ: OoT originally and now MSET, both still cause this problem.