I do the same too with many of the leaked dev files I had back in the day.i play with dev titles and stuff like that and dont want to break my sysnand in the process
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)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
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 togetherHow 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)
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 thoughMultibooting into different versions of the 3DS OS. Back in the day, it was common to downgrade EmuNAND to 2.1.0
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)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
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)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
Fair, but then again, I bet another component (my guess the SD reader itself) will fail firsteMMC wear.
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.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)
Uh, neither the official System Updater or Unlaunch use libfat. System Updater uses whatever lib Nintendo made, while Unlaunch uses Nocash code:tm: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.
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.Uh, neither the official System Updater or Unlaunch use libfat. System Updater uses whatever lib Nintendo made, while Unlaunch uses Nocash code:tm:
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 irrelevantYes, 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.
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.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
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 UnlaunchNo, 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.
Using Gateway on my modded 2DS. I used sysUpdater and the 6.2 update pack to downgrade my 2DS to support it.
She’s talking about emunand on 3DS bro.Cool story to bump after 9 months bro, but the topic is emunand on 3DS.
She’s talking about emunand on 3DS bro.