Because with A9LH you cannot lose your system even if it's sysNAND only? A9LH and it's payloads load before anything else when the console is booted, so even if sysNAND is bricked it still can be restored.
So with A9LH you can install everything without fear as well. Your reasoning for emuNAND being better as such is invalid.
So with A9LH you can install everything without fear as well. Your reasoning for emuNAND being better as such is invalid.
For most people, it's due to the constant switching between emunand and sysnand, as well as the fact that you might end up using double the SD space for things like DSiware or GBA VC. However, the benefits is that you have 2 systems on the same handheld. One for testing to see if things work well, and the other for stable stuff. If you update your emunand and it breaks with your CFW, at least your system is safe while you simply restore your emunand backup.
Well I mean, there's no reason to not have one, if you're that worried about space then just delete it and get it over with, but some people have found several different ways to make emuNANDs extremely useful. And you can't forget people that still use Gateway in 2017 and have issues just from trying to run a sysNAND only setup.
Buuuuuttttt, to each their own, right?
Last edited by CreAtor135,
Because with A9LH you have no reason to have emuNAND?
A9LH gives you the benefits of an emuNAND (Brick protection, you can update...) without the needed extra space of the emuNAND
BTW: probably
'd
A9LH gives you the benefits of an emuNAND (Brick protection, you can update...) without the needed extra space of the emuNAND
BTW: probably
'dThere is no reason to have one either if you're an average user. If you have GW then it's another story.
D
Deleted User
Guest
Menuhax is mainly the problem with a emunand setup due to the boot rate.The other thing is simply the emunand taking up 2gb of space and if you want to inject vc games in cia format you have to install them both on the sysnand and emunand on a emunand setup which also takes space.
Not really. A9LH is installed on the CTRNAND chip, which is the same location as your sysnand. If your sysnand gets bricked, there's a slim chance your A9LH installation gets corrupted. Slim, but still possible. And if Nintendo released an update that bypasses your CFW's Firm0/1 protection, you lose A9LH on your sysnand. Again, a slim thing, but not impossible.
Most reasons against emuNAND are as "invalid" as the ones given by "emuNAND fans". I mean "save space"? Like I care about space on my 128GB SD card. Except for people with 4GB card, it's not possible to really care about 2GB, and in that case the solution isn't to get rid of emuNAND but to upgrade the card. Though same kind of invalid arguments on the other side with stuff like "fool-proof setup". Well technically you could restore your NAND from decrypt9 on a9lh even if you screw up badly. And you'd be really unlucky to get NAND wearing soon so there is nothing to be afraid of. So yeah, with these kind of bad arguments, everyone could argue for days without convincing anyone.
The one real reason why emuNAND is inferior to sysNAND is because of GBA VC and stuff like that that really depend on sysNAND but that are really straightforward when you are using your sysNAND as your main NAND.
And the one reason why someone would "need" an emuNAND is because of Gateway (though a better idea would be for them to support sysNAND for real...).
The one real reason why emuNAND is inferior to sysNAND is because of GBA VC and stuff like that that really depend on sysNAND but that are really straightforward when you are using your sysNAND as your main NAND.
And the one reason why someone would "need" an emuNAND is because of Gateway (though a better idea would be for them to support sysNAND for real...).
Posted by accident, my reply is finished now.
Personally, emuNAND is easier for me because I'm always changing proxy settings on my 3DS, so emuNAND saves me a bit more time when I wanna switch between proxies and official services. Other people use emuNAND like the user system on a PC for their children to have their own personal profiles on the same 3DS. Those are just my examples, but I'm sure there are plenty of others out there.
Last edited by CreAtor135,
And the only reason for Gateway are the cheats, which I've been hearing people ask for other CFW to support out of the box, so that's one thing that should make Gateway completely obsolete.
i think emunand now is better for developers, they can brick and simply restore or create another to use
If Nintendo released an update that bypassed the protection everyone's console would brick. Pretty obvious why they haven't done it. Nintendo isn't stupid, they surely know about A9LH and it's "weakness", but the problem is that they can't do anything about it without bricking everyone's consoles. Also if you install something to your sysNAND that doesn't mesh well and it gets bricked, there's no chance to brick A9LH because of what we just talked about .. it's protected.
Their recent update was a pretty nice attempt at silently bricking us, but it fell flat because Luma was prepared, doesn't stop other CFWs from getting affected though. In the event that a sysNAND gets bricked in the future, people will be glad they kept emuNAND.
Yeah, unless said app that doesn't mesh well was (un)intentionally coded to corrupted/erase A9LH. That's another topic all together, and would rather not go into an argument about. Nintendo isn't stupid, they wouldn't risk bricking their consoles, but doesn't mean users wouldn't do something to cause it.
Luma, for example, is created to protect A9LH by preventing it from being overwritten by Nintendo. It detects A9LH and stops writes to it.
Yeah, theirs was, so was mine.
--------------------- MERGED ---------------------------
Not for those who already have it. Swapping .3ds files is way faster than installing cias.
FIRST OF ALL: NO ARM9LOADERHAX IS NOT PROTECTED. What is protected is FIRM0 and FIRM1 because thats where the Payloads are stored in. also a9lh DOES NOT have a self-protection, the FIRM Protection gets applied by the code that is run by the arm9loader, which is in most cases Luma/Corbenik, which are signature patchers which apply FIRM Protection, that that on updating FIRM0 and FIRM1 can not get overwritten.
Gateway does not have any kind of FIRM protection, so if you update running a Gateway Payload, your FIRM0 and FIRM1 get overwritten and you loose arm9loaderhax.
Gateway knows this, but they don´t care at all.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
RedColoredStars:
There is an actual trailer with footage too. lol. Going to watch it tonight. Grabbed it from... a place. -
-
@
SylverReZ:
@Psionic Roshambo, JonTron's back yet again until he disappears into the void for another 6 or so months.+1 -
-
-
-
-
-
-
