Hacking Homebrew To people still running an emuNAND on your 3DS, what is your reasoning

[fluff663]

i play with dev titles and stuff like that and dont want to break my sysnand in the process

 

[SylverReZ]

i play with dev titles and stuff like that and dont want to break my sysnand in the process

I do the same too with many of the leaked dev files I had back in the day.

 

[NightScript]

This is actually a very valid point I never even thought of. Though, in my experience even shitty flash storage does last a while, and I have a feeling some other component on the 3DS will fail long before the flash storage

How long is a "while", though? On the DSi side of things, we're dealing with corrupted NANDs from even simple System Updates. We have even implemented an entirely different method of our guide to avoid installing Unlaunch (though ironically, a lot of NAND writes are caused by the Home Menu so this is useless. Still, you can't beat sense into a rock)

-----

Overall, I suppose from what I've seen of the thread, there are three legitimate reasons why one would keep an EmuNAND:
1. Multibooting into different versions of the 3DS OS. Back in the day, it was common to downgrade EmuNAND to 2.1.0
- This also allows using other CFW that never got updates to work on the latest, such as Gateway. Gateway has a more stable cheat engine than Luma3DS as well as the ability to load non-installed games through the .3DS format. This is a subbullet because I am leaving out the MAJOR downsides (clone bricking, online headers), although it's bordering that line because Gateway is a MAJOR risk on SysNAND by not including update patches to .firm partitions
2. Having different menu's without the use of 3DSBank. This is important because you have to be booted into one menu to even realize that you're in the wrong menu and have to switch, yet EmuNAND allows you to use different menu's selectable right from the boot menu
3. eMMC wear.

 

[Dionicio3]

How long is a "while", though? On the DSi side of things, we're dealing with corrupted NANDs from even simple System Updates. We have even implemented an entirely different method of our guide to avoid installing Unlaunch (though ironically, a lot of NAND writes are caused by the Home Menu so this is useless. Still, you can't beat sense into a rock)

NAND corruptions isn't always explicitly a sign of the chip failing. I'm more talking about the chip completely failing and either entering a read only mode (which is what I tend to see happen with flash storage), or just stop being detected by the console all together

Multibooting into different versions of the 3DS OS. Back in the day, it was common to downgrade EmuNAND to 2.1.0

Yeah I mentioned this later as a cool possible use case, specific when dualbooting a retail and dev firmware. Downgrading for the use of exploits isn't necessary anymore though

This also allows using other CFW that never got updates to work on the latest, such as Gateway. Gateway has a more stable cheat engine than Luma3DS as well as the ability to load non-installed games through the .3DS format. This is a subbullet because I am leaving out the MAJOR downsides (clone bricking, online headers), although it's bordering that line because Gateway is a MAJOR risk on SysNAND by not including update patches to .firm partitions

I have never really seen instability with Luma3DS's cheat engine other than maybe when it was first introduced. But everything I initially saw got fixed fast. Also, staying on such a dramatically low firmware that works with Gateway will lock you out of certain games that require new firmware versions (though this might not be an issue as I'm not sure what firmwares Gateway works up to/games that require anything newer than it)

Having different menu's without the use of 3DSBank. This is important because you have to be booted into one menu to even realize that you're in the wrong menu and have to switch, yet EmuNAND allows you to use different menu's selectable right from the boot menu

This is another use case that's decent, even if pretty niche. I personally find it very hard to even come close to the 300 title limit without using badges (and I used to be a heavy pirate as you'd know lol)

eMMC wear.

Fair, but then again, I bet another component (my guess the SD reader itself) will fail first

 

[ghjfdtg]

How long is a "while", though? On the DSi side of things, we're dealing with corrupted NANDs from even simple System Updates. We have even implemented an entirely different method of our guide to avoid installing Unlaunch (though ironically, a lot of NAND writes are caused by the Home Menu so this is useless. Still, you can't beat sense into a rock)

The corruption you mentioned is caused by libfat not updating the second file allocation table because it's simply not supported. I wish devkitPro would drop libfat in favor for FatFs already which is proven and super stable. This is not acceptable.

 

[NightScript]

The corruption you mentioned is caused by libfat not updating the second file allocation table because it's simply not supported. I wish devkitPro would drop libfat in favor for FatFs already which is proven and super stable. This is not acceptable.

Uh, neither the official System Updater or Unlaunch use libfat. System Updater uses whatever lib Nintendo made, while Unlaunch uses Nocash code:tm:

 

[ghjfdtg]

Uh, neither the official System Updater or Unlaunch use libfat. System Updater uses whatever lib Nintendo made, while Unlaunch uses Nocash code:tm:

Yes, but any homebrew not from nocash that writes to the twln partition fs is inevitably messing it up. There were exploits before unlaunch existed. This is my theory where the corruption comes from. eMMC is super reliable and durable. I doubt it's the cause.

 

[Dionicio3]

Yes, but any homebrew not from nocash that writes to the twln partition fs is inevitably messing it up. There were exploits before unlaunch existed. This is my theory where the corruption comes from. eMMC is super reliable and durable. I doubt it's the cause.

They were talking about bricks they've seen that were caused directly from the official System Updater and Unlaunch, not about any potential bricks caused by other software. Bringing up these other software is irrelevant

 

[ghjfdtg]

They were talking about bricks they've seen that were caused directly from the official System Updater and Unlaunch, not about any potential bricks caused by other software. Bringing up these other software is irrelevant

No, the homebrew apps using libfat introduce inconsistency to the filesystem. This only shows up when Unlaunch or the system updater try to modify the same filesystem. That's why i brought it up.

Anyway, i agree this is not exactly relevant for this thread. Just mentioned this because the eMMC on DSi is allegedly unreliable.

 

[Dionicio3]

No, the homebrew apps using libfat introduce inconsistency to the filesystem. This only shows up when the Unlaunch or the system updater try to modify the same filesystem. That's why i brought it up.

Most users aren't running libfat homebrew that write to NAND before the use of System Updater/Unlaunch. In fact, most users don't run any homebrew at all before running System Updater, and only run dumpTool before Unlaunch

 

[SylverReZ]

Using Gateway on my modded 2DS. I used sysUpdater and the 6.2 update pack to downgrade my 2DS to support it.

 

[RedColoredStars]

Using Gateway on my modded 2DS. I used sysUpdater and the 6.2 update pack to downgrade my 2DS to support it.

Cool story to bump after 9 months bro, but the topic is emunand on 3DS.

 

[kineticUk]

Cool story to bump after 9 months bro, but the topic is emunand on 3DS.

She’s talking about emunand on 3DS bro.

 

[RedColoredStars]

She’s talking about emunand on 3DS bro.

Ok. my apologies then. But should probably say Gateway emunand on 3DS . Still an odd bump after 9 months.