Homebrew Official [Release] EmuNAND9 - Open Source EmuNAND Formatter & Manager

[WiiUBricker]

How can I see if I'm on emuNand or sysNand?

 

[MRDOCA]

Quick question. I want to swap out my current 4gb sd card and replace it with something bigger. How can I copy my emunand over to the new one? Is it as simple as backing up the emunand to bin then inserting the new sd card creating a emunand partition and cloning from the emunand.bin?

 

[ihaveahax]

How can I see if I'm on emuNand or sysNand?

this depends on the custom firmware you're using, often by replacing "Ver." in System Settings. rxTools does "RX-E", ReiNand does "Rei", Gateway does "GW3D".

an easier way to do this, if you NANDs are unlinked is to give them different Home Menu themes. if you are using menuhax, change the theme in menuhax_manager.

 

[d0k3]

And done.

@madridi4ever & @kiwiis we're currently trying to find out what's going wrong there with CakeHax + EmuNAND9 / Decrypt9. Maybe you can try if the simple sample application attached to this post works for you? This has the same entrypoints as Decrypt9 and EmuNAND9.

--------------------- MERGED ---------------------------

Quick question. I want to swap out my current 4gb sd card and replace it with something bigger. How can I copy my emunand over to the new one? Is it as simple as backing up the emunand to bin then inserting the new sd card creating a emunand partition and cloning from the emunand.bin?

You also need to copy the contents of your SD card filesystem over. Other than that, you'll be good to go.

 

[Shadowtrance]

@madridi4ever & @kiwiis we're currently trying to find out what's going wrong there with CakeHax + EmuNAND9 / Decrypt9. Maybe you can try if the simple sample application attached to this post works for you? This has the same entrypoints as Decrypt9 and EmuNAND9.

Just tested it on my n3ds via MSET and it seems to work fine as is. As does Emunand9UI and Decrypt9UI once i change the #define BOT_SCREEN0 in both to what is in HelloEntryPoint. Otherwise (before the change) I'm greeted with black screens and no way to reboot other than forced power off.

 

[d0k3]

Just tested it on my n3ds via MSET and it seems to work fine as is. As does Emunand9UI and Decrypt9UI once i change the #define BOT_SCREEN0 in both to what is in HelloEntryPoint. Otherwise (before the change) I'm greeted with black screens and no way to reboot other than forced power off.

Okay, thanks a ton! Duh, that will mean some extensive modifications to the Makefile now. And maybe, BootCTR will need some changes, too.

 

[Shadowtrance]

Okay, thanks a ton! Duh, that will mean some extensive modifications to the Makefile now. And maybe, BootCTR will need some changes, too.

Nah we should just have one version of each imo.... 3dsx only haha Would save a lot of headaches / head scratching when it doesn't work etc etc...

 

[d0k3]

Nah we should just have one version of each imo.... 3dsx only haha Would save a lot of headaches / head scratching when it doesn't work etc etc...

Well, some entrypoints are still useful for the small remainder of users who don't have SysNAND HBL access or have other reasons not to use HBL. The GW 4.x Launcher.dat should be very obsolote by now though. And you're correct, maintaining all these entrypoints is a huge pain in the ass.

 

[d0k3]

Just tested it on my n3ds via MSET and it seems to work fine as is. As does Emunand9UI and Decrypt9UI once i change the #define BOT_SCREEN0 in both to what is in HelloEntryPoint. Otherwise (before the change) I'm greeted with black screens and no way to reboot other than forced power off.

@mid-kid sorry for bothering you again. The problem with booting the payload seems to be in my testing method (BootCTR). Just fixing the bottom framebuffer offset to 0x080FFFD0 seems to do the job with CakeBrah (instead of BootCTR). Trying to find out more, but in the meantime, there's something you might have the answer to...

Was the bottom framebuffer offset for GW always 0x080FFFD0? Asking because 0x080FFFD4 was used in the past for the GW 4.x browser entrypoint. I never used that entrypoint, but afaik that entrypoint worked for a lot of users, even if there was something wrong with the offset. I don't want to make my Makefile more complicated than it already is, so I'd very much prefer just changing the offset and to be done with it (only if it doesn#t break anything, though).

 

[Shadowtrance]

Well, some entrypoints are still useful for the small remainder of users who don't have SysNAND HBL access or have other reasons not to use HBL. The GW 4.x Launcher.dat should be very obsolote by now though. And you're correct, maintaining all these entrypoints is a huge pain in the ass.

True. Probably a very small minority who use other entry points / don't have sysnand HBL (for whatever strange reason). I only find myself using the 3dsx versions these days to be honest.
And yeah the GW Launcher.dat version "should" be pretty much obsolete now and i guess should be removed too maybe, i see no use for it at all now.

If it was ME maintaining it all though I'd say screw it and remove every other version besides the 3dsx one haha

 

[d0k3]

Alright, new release. New in this:
* Allow specifiying the file name when dumping / restoring the SysNAND / EmuNAND
* Updated starter.bin
* CakeHax entrypoint fixed (experimental, may break the GW 4.x browser entrypoint)

Testing the CakeHax entrypoint and the GW 4.x Launcher.dat entrypoint is highly appreciated. If you can, please test this entrypoints and let me know if it works for you. Also, @kiwiis and @madridi4ever might want to give this a try.

 

[Madridi]

Alright, new release. New in this:
* Allow specifiying the file name when dumping / restoring the SysNAND / EmuNAND
* Updated starter.bin
* CakeHax entrypoint fixed (experimental, may break the GW 4.x browser entrypoint)

Testing the CakeHax entrypoint and the GW 4.x Launcher.dat entrypoint is highly appreciated. If you can, please test this entrypoints and let me know if it works for you. Also, @kiwiis and @madridi4ever might want to give this a try.

Works great! So does the Decrypt9. I am happy you were able to solve this issue

Nah we should just have one version of each imo.... 3dsx only haha Would save a lot of headaches / head scratching when it doesn't work etc etc...

Noooo don't give him any ideas lol

Waiting for your UI update versions

 

[Shadowtrance]

Works great! So does the Decrypt9. I am happy you were able to solve this issue


Noooo don't give him any ideas lol

Waiting for your UI update versions

Totally giving him ideas. The amount of entry points to cover is no doubt annoying for him and to be honest no one has an excuse to not have access to homebrew menu atm with the amount of *hax to choose from. Prove me wrong.

And I'll look at updating the UI versions shortly.

 

[Shadowtrance]

Ok E9UI is updated.
https://github.com/Shadowtrance/EmuNAND9/releases/tag/v1.1.0

Working on D9UI now.

 

[Madridi]

Totally giving him ideas. The amount of entry points to cover is no doubt annoying for him and to be honest no one has an excuse to not have access to homebrew menu atm with the amount of *hax to choose from. Prove me wrong.

And I'll look at updating the UI versions shortly.

Lol I disagree! True, HBL is probably the best thing out there, the main entry point in my opinion remains the browser vuln for those on 9.2

Getting to HBL is tedious with browserhax. At the very least, it does not have a 100% boot rate.

As for homemenuhax, I understand that it's the hottest thing on the scene right now and I agree with how valuable it is. However, those with linked NAND (like myself.. For multiple reasons) cannot benefit from it. We cannot launch cfw. (Unless v2 fixed that somehow). So basically, homemenuhax is out of the question for me, in which case, the browser vuln is the best out there for those who can't use homemenuhax.

So yeah I'm happy with the browser entry point please don't ruin it for me lol

 

[dark_samus3]

Lol I disagree! True, HBL is probably the best thing out there, the main entry point in my opinion remains the browser vuln for those on 9.2

Getting to HBL is tedious with browserhax. At the very least, it does not have a 100% boot rate.

As for homemenuhax, I understand that it's the hottest thing on the scene right now and I agree with how valuable it is. However, those with linked NAND (like myself.. For multiple reasons) cannot benefit from it. We cannot launch cfw. (Unless v2 fixed that somehow). So basically, homemenuhax is out of the question for me, in which case, the browser vuln is the best out there for those who can't use homemenuhax.

So yeah I'm happy with the browser entry point please don't ruin it for me lol

Well, considering the MSET .dat file can be used with the browser without any fiddling, taking the gateway version out would just take out redundancy, since cakehax payloads are able to be run from HBL, browser and MSET so taking the GW launcher.dat out is the way to go IMO

 

[d0k3]

Well, considering the MSET .dat file can be used with the browser without any fiddling, taking the gateway version out would just take out redundancy, since cakehax payloads are able to be run from HBL, browser and MSET so taking the GW launcher.dat out is the way to go IMO

Alright, but what if you are on O3DS v4.x? Does CakeHax work with that as well and is it as reliable?

 

[Madridi]

Well, considering the MSET .dat file can be used with the browser without any fiddling, taking the gateway version out would just take out redundancy, since cakehax payloads are able to be run from HBL, browser and MSET so taking the GW launcher.dat out is the way to go IMO

Not for those who have gateway? like me..

Oh you mean out of emunand9 and decrypt9? Yeah that I agree with

--------------------- MERGED ---------------------------

Alright, but what if you are on O3DS v4.x? Does CakeHax work with that as well and is it as reliable?

If you're of 4.x you'd use MSET wouldn't you? I don't know much about that as I never was on 4.x

 

[mid-kid]

Was the bottom framebuffer offset for GW always 0x080FFFD0? Asking because 0x080FFFD4 was used in the past for the GW 4.x browser entrypoint. I never used that entrypoint, but afaik that entrypoint worked for a lot of users, even if there was something wrong with the offset. I don't want to make my Makefile more complicated than it already is, so I'd very much prefer just changing the offset and to be done with it (only if it doesn#t break anything, though).

Keep in mind every screen has two buffers, so in total we have 6 framebuffers. 0xD4 was the __second__ bottom framebuffer, and should be used depending on 0x080FFFDC (so the correct way of handling it is the same as you do for the top screen), If I'm right (For some reason the GW launcher just always seemed to set the second bottom FB). @Normmatt knows this better than myself, so tagging for confirmation.

 

[d0k3]

Keep in mind every screen has two buffers, so in total we have 6 framebuffers. 0xD4 was the __second__ bottom framebuffer, and should be used depending on 0x080FFFDC, If I'm right (For some reason the GW launcher just always seemed to set the second bottom FB). [USER=311583]@Normmatt knows this better than myself, so tagging for confirmation.[/USER]

Yup, that's what I thought. I guess I can bring true GW compatibility back then, if I choose the bottom framebuffer depending on that value, same as I'm doing with the top framebuffer now. Maybe also just ditch that old thing. No one is using that anyways and I don't like having untested stuff in there.