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

[Shadowtrance]

Hmmm... @Shadowtrance, could you help us? This is not actually dangerous (don't worry, we'll find dangerous stuff later ).

By the way, Shadowtrance, I hope you see this... the last few commits will also help further limit the number of edits you have to make. You don't need to edit common.h anymore, a small change in the Makefile will suffice. Plus, the new Makefile will also automagically copy theme files.

Yeah just woke up not long ago. And yep saw the changes. Can you update the menu gfx generator to reflect the menu changes for E9?
So for setting it to theme mode in the makefile i just put what? the path like i did in common.h in the theme section? /E9UI for example...

Also what am i possibly helping with? still half alseep lol (10am here)

 

[d0k3]

Yeah just woke up not long ago. And yep saw the changes. Can you update the menu gfx generator to reflect the menu changes for E9?
So for setting it to theme mode in the makefile i just put what? the path like i did in common.h in the theme section? /E9UI for example...

Also what am i possibly helping with? still half alseep lol (10am here)

No need to haste at all... It's 1:30 am here and I need to get to sleep . You just put E9UI (without the '/') in there, and it will do the same and more as before. And I'll see about the menu GFX generator tomorrow.

This is what is interesting to test. Especially the thing that needs two 3DS consoles. Don't worry about NAND sizes - won't matter, we're only interested in SysNANDs. And backup your SysNAND (as if I have to tell you...).

By the way, big changes coming up for Decrypt9... but you may have already seen the latest commits.

 

[Shadowtrance]

No need to haste at all... It's 1:30 am here and I need to get to sleep . You just put E9UI (without the '/') in there, and it will do the same and more as before. And I'll see about the menu GFX generator tomorrow.

This is what is interesting to test. Especially the thing that needs two 3DS consoles. Don't worry about NAND sizes - won't matter, we're only interested in SysNANDs. And backup your SysNAND (as if I have to tell you...).

By the way, big changes coming up for Decrypt9... but you may have already seen the latest commits.

Yeah true, but it gives me something to do and keep my mind off my dog who is no longer with us as of yesterday.
I'll have a look at thing that needs testing if i can.

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

Trying to find an image for the sd unmount erm image is proving to be a pain...my google fu isn't working.

 

[dark_samus3]

Yeah true, but it gives me something to do and keep my mind off my dog who is no longer with us as of yesterday.
I'll have a look at thing that needs testing if i can.

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

Trying to find an image for the sd unmount erm image is proving to be a pain...my google fu isn't working.

use an eject symbol

 

[Shadowtrance]

use an eject symbol

Good idea! haha Just need one for cancelled now.

 

[dark_samus3]

Good idea! haha Just need one for cancelled now.

btw, I'm working on submenu support for D9MenuSim, it also supports EmuNAND9 (think I showed you that) it's also easy to update for future menu projects provided they use a similar menu scheme... Anyways currently have all E9 submenus working but the code isn't exactly modular so I'm working on making it modular and then I'll push it to github and do a second release

 

[Shadowtrance]

btw, I'm working on submenu support for D9MenuSim, it also supports EmuNAND9 (think I showed you that) it's also easy to update for future menu projects provided they use a similar menu scheme... Anyways currently have all E9 submenus working but the code isn't exactly modular so I'm working on making it modular and then I'll push it to github and do a second release

Cool
How's this look now? Not so empty. haha

 

[dark_samus3]

Cool
How's this look now? Not so empty. haha

Looks awesome!

 

[Shadowtrance]

And i think that will do for cancel

 

[Shadowtrance]

@d0k3 just tried the latest changes to E9, the theme define in the makefile does indeed need the / before the folder name, so /E9UI otherwise it doesn't work.
Just tested it without the / so just E9UI in makefile, images aren't found when loading E9, but works as normal if i rebuild with the / added before E9UI.

 

[d0k3]

@d0k3 just tried the latest changes to E9, the theme define in the makefile does indeed need the / before the folder name, so /E9UI otherwise it doesn't work.
Just tested it without the / so just E9UI in makefile, images aren't found when loading E9, but works as normal if i rebuild with the / added before E9UI.

Yup, correct. But I need to fix this, cause otherwise there might be trouble later on. Sorry reading about your dog passing away .

On our new issue... the only way the second folder / <id1> can change should be if the SD CID changes. The SD CID can be read via this tool. If it can change... no idea yet.

 

[d0k3]

I have an idea, but this will need confirmation. @dark_samus3 here's my theory.

As you know, the <id0> in "/Nintendo 3DS/<id0>/<id1>" comes from the SysNAND and won't change as long as you don't format your SysNAND. The <id1> comes from the NAND CID and won't change as long as either (a) the SD stays the same or (b) there is already an <id1> folder in there (even if that does not match the SD CID).

Now, what happened here? I'll try to explain... For most users, once they get their 3DS console, they start using it with the very small SD card that is provided with it (SD0). Based on SD0 and it's SD CID, the <id1> is calculated. Now, users very soon notice that this SD is just too small (why the ... can't any manufacturer provide a large enough SD card, btw?), so they buy a new one (SD1) and copy all their stuff over. Note that at this point the 3DS is using SD1, but the <id1> is still calculated from SD0. This is perfectly okay and intended to work that way. Even Nintendo thought about the possibility of their users switching SD cards and wanting to keep using their data. Now, what will happen if the SD card is completely wiped? The 3DS still knows it's <id0>, because the SysNAND hasn't changed, but the <id1> is recalculated based on SD1.

And, yes, that problem should be there with GW software as well, it just hasn't been noticed on a larger scale by now. Can anyone help me confirm the above?

@Galcian44 , I assume the above also describes your 3DS / SD card history, correct?

 

[Galcian44]

I have an idea, but this will need confirmation. @dark_samus3 here's my theory.

As you know, the <id0> in "/Nintendo 3DS/<id0>/<id1>" comes from the SysNAND and won't change as long as you don't format your SysNAND. The <id1> comes from the NAND CID and won't change as long as either (a) the SD stays the same or (b) there is already an <id1> folder in there (even if that does not match the SD CID).

Now, what happened here? I'll try to explain... For most users, once they get their 3DS console, they start using it with the very small SD card that is provided with it (SD0). Based on SD0 and it's SD CID, the <id1> is calculated. Now, users very soon notice that this SD is just too small, so they buy a new one (SD1) and copy all their stuff over. Note that at this point the 3DS is using SD1, but the <id1> is still calculated from SD0. This is perfectly okay and intended to work that way. Even Nintendo thought about the possibility of their users switching SD cards and wanting to keep using their data. Now, what will happen if the SD card is completely wiped? The 3DS still knows it's <id0>, because the SysNAND hasn't changed, but the <id1> is recalculated based on SD1.

And, yes, that problem should be there with GW software as well, it just hasn't been noticed on a larger scale by now. Can anyone help me confirm the above?

@Galcian44 , I assume the above also describes your 3DS / SD card history, correct?

Yup, that's it .

So it seems that changing the <id1> is not an issue as long as your change the folder's name of your backup with the new <id1> generated on the wiped SD card. You will be able to retrieve your data.

 

[d0k3]

Yup, that's it .

So it seems that changing the <id1> is not an issue as long as your change the folder's name of your backup with the new <id1> generated on the wiped SD card. You will be able to retrieve your data.

I think it would have also worked if you just deleted the full Nintendo 3DS folder before copying your data back.

 

[d0k3]

... okay, i tested it. All @Galcian44 and everyone else having that issue would have had to do is to delete the new 'Nintendo 3DS' folder instead of just copying the old / backupped one over the new one. In essence, this is a non-issue. And not caused by EmuNAND9, to remark .

So, users, keep in mind when restoring your SD backup at least delete the '/Nintendo 3DS/' folder (if existing) first. That means from the SD card, not from the backup.

Oh, and fun fact. You can rename the <id1> in /Nintendo 3DS/<id0>/<id1> to anything, as long as that anything consists fully of lower case hexadecimal numbers (0-9, a-f) and is 32 symbols long. 32x zero will work, f.e. Or you can be creative:
deadc0defacecafeb00bdeaffadeaced
... still completelly valid

 

[Ygreck]

Is it possible to integrate something like libSu to backup your sysNand >=9.3?

 

[halefire94]

Hi all, I am completely new to homebrewing the 3ds (and homebrewing at all).

I have installed a 10.3 emuNAND on my system using emuNAND9 and a 9.2 sysNAND. However, that was all on a 4GB SD card, and would like to transfer that to a 64GB card. Are there any guides available that will walk me through how to transfer it using emuNAND9 (if it can do that?)

Thanks!

 

[d0k3]

Is it possible to integrate something like libSu to backup your sysNand >=9.3?

No, not at the moment.

Hi all, I am completely new to homebrewing the 3ds (and homebrewing at all).

I have installed a 10.3 emuNAND on my system using emuNAND9 and a 9.2 sysNAND. However, that was all on a 4GB SD card, and would like to transfer that to a 64GB card. Are there any guides available that will walk me through how to transfer it using emuNAND9 (if it can do that?)

Thanks!

You have to format the new SD for EmuNAND... backup the EmuNAND from your current SD and copy that to the new SD, then clone the backup to the new SD card EmuNAND (all in EmuNAND09, no other tools required). You may still want to transfer the contents of your old SD to your new SD. Just try it, nothing can go wrong as long as you have backups.

 

[d0k3]

There's a new release on GitHub:

• Restructured SD format menu, now also contains 'legacy' EmuNAND format option
• Oversized starter.bin files are now allowed per user choice
• Updated starter.bin file
• Some minor bug fixes

The 'legacy' option uses the same sizes for EmuNANDs as the GW software did, in essence wasting a lot of space. However, some older tools may require the EmuNAND to have that size to work. It is still recommended to use the default option (which is also used in the 'Complete EmuNAND Setup'.

Also, @Shadowtrance, I added the new menu structure to the generator script.

 

[Galcian44]

... okay, i tested it. All @Galcian44 and everyone else having that issue would have had to do is to delete the new 'Nintendo 3DS' folder instead of just copying the old / backupped one over the new one. In essence, this is a non-issue. And not caused by EmuNAND9, to remark .

So, users, keep in mind when restoring your SD backup at least delete the '/Nintendo 3DS/' folder (if existing) first. That means from the SD card, not from the backup.

Oh, and fun fact. You can rename the <id1> in /Nintendo 3DS/<id0>/<id1> to anything, as long as that anything consists fully of lower case hexadecimal numbers (0-9, a-f) and is 32 symbols long. 32x zero will work, f.e. Or you can be creative:
deadc0defacecafeb00bdeaffadeaced
... still completelly valid

That's good news ! Thank you for your work