I still need to learn how memchunkhax2 actually works. This will take some time. Also, memchunkhax2 doesn't seem to be stable atm. Better to wait for a but.Thanks for the reply. This means memchunkhax2 wont be usefull here :x
I still need to learn how memchunkhax2 actually works. This will take some time. Also, memchunkhax2 doesn't seem to be stable atm. Better to wait for a but.Thanks for the reply. This means memchunkhax2 wont be usefull here :x
Well, this will get long...
I need more details. Is this on a very small SD card? Is the SD card properly formatted? You can check the SD card in the Windows command prompt via chkdsk.
Well, once that is stable, once I know how it works, of course. In the meantime, helpful hints are appreciated.
Alright, still not sure if I got that right . You can only do a Nintendo (home menu) System Transfer once the NAND is already set up, but that is not what you mean, right? So, you transfered the backup from 3DS-A to 3DS-B? For all that I know right now, that should not work at all. The first barrier would be the different encryption (fixable), but that is not everything that stands in the way.
Well, the EmuNAND size is decided the same way everyone else does it now (CakesFW, rxTools, ... even GW). EmuNAND9 is different from GW in that GW just decides to use a big chunk of your SD card (big enough to handle any size), while EmuNAND9 chooses the size based on the actual flash memory size. The EmuNAND created by EmuNAND9 should still be exportable by any other tool. Could you specifiy or give an example?
By the way, while the flash memory sizes differ, the actual NAND size does not. EmuNAND / SysNAND backups can easily be fixed to work on any flash memory size by truncating / padding. I could even build this right into EmuNAND9 (and yes, we could even save more memory). I need more details, though.
No, for SysNAND you need direct and full access to the NAND for this to work. This (access to SysNAND) is actually the only reason why EmuNAND9 needs ARM9 access.
No. You might be able to take over some stuff, tough, once you have set up your N3DS EmuNAND. I suggest you do a new thread for this.
Well, does anyone ever actually read readmes?this looks like an awesome tool !
question, can one setup menuhax with this? so the thing is i try to help a friend who does not have gw/oot/cn etc.
lives away from where i live, so i helped them downgrade their console from 10.3 down to 9.2.
but now i would like to kind of easily help them to format emuNAND and prepare everything sort of swiftly..? i think if i send them too many things it might confuse them and make them give up (they are noobish) I myself am sort of noobish too.. but well.
so question is basically if they could use this tool for formatting emuNAND and then right after kind of run install menuhax within..it? that would be pretty cool.. (As for the rest i will help them set up RXcfw etc.) would need emuNAND set for them along with autoboot set would be ideal.
Only if your SD card is already formatted for EmuNAND. The reason we have to format it is because it also has to be repartitioned to include a hidden partition at the start of the SD card.It's possible to create an emunand without format the sd?
There's not really an option that will save you from a lengthy copy process. You could create the hidden partition in Minitool Partition Wizard. That would mean creating enough (~= 1GB for O3DS) free space at the beginning of the SD card. Partition Wizard can reposition the data, meaning you would lose nothing. If you have done that, you can use EmuNAND9 to just clone the EmuNAND to the new hidden partition.Ok :/
Because I will do a downgrade -> emunand on another O3ds (10.3) with many purchased games...
That's new... Can you check if your files are, in fact, untouched by EmuNAND9? Also, what file system are you formatting the SD card with (FAT16/FAT32/other)? What access point are you using to run EmuNAND9?Having a bit of trouble getting this to work (9.2 O3DS).
When I run complete emunand setup, everything goes smoothly (except it can't seem to find the starter.bin even though it's in the default EmuNAND9 folder) and it says completed successfully. However, after rebooting, my 3DS can't detect my SD card ("could not detect an SD card"). When I check my SD card on my computer, it looks the same before running the complete emunand setup (all the files are there, does not appear formatted). If I format it myself in Windows then the 3DS will recognize it again.
I tried this twice and both times the SD card could not be read after running the complete emunand setup. Any ideas?
Thanks so much!
Good to read that! Quick format is okay, if you don't want to hide data that's actually as good as a full one.Thanks for the fast reply.
My SD card was formatted with the windows formatting tool (FAT32, 32 bit allocation size, quick format). I was using the homebrew launcher .3dsx file as my entry point.
One thing I noticed was that the emunand9 menus were loading extremely slowly, would take like ~20 seconds to finally show all of the info on the screen.
I reformatted the SD card using the official SD association formatter you linked to (quick format) and tried again. This time it worked perfectly and the menus were loading instantly. Something must have been wrong with the format of the SD card.
Thanks for the help! SOLVED!
A question before debugging more on my end - is the emunand created by this tool the same partition size as one created via the GW launcher.dat?
First, I dumped the (GW-created) emunand from my working card into a file using EmunandTool. The file dumped was 1.84 GB (1,979,711,488 bytes).
I did a quick setup on a new SD card using EmuNAND9Tool and then tried to inject the dumped file into the new partition created. The tool generated an error about the size. It wasn't obvious if the older EmunandTool was expecting a larger or smaller partition size.
I then created a partition with the GW launcher.dat and the emunand injected without an issue.
tl;dr Are the partitions created by your utility the same size/configuration as those created with the Gateway utility? And if not, is there a utility out there for dumping/injecting emunand to/from an old Gateway emunand that is more compatible with this utility? I'd prefer to use your EmuNAND9Tool going forward for creating emunand SD cards.
Please let me know if you need/want any more debugging information.
I think d0k3's tool formats the partition based on the nand chip size. GW reserves extra space when partitioning.
Well, does anyone ever actually read readmes?
EmuNAND9 has an autosetup feature, that means that after the EmuNAND is set up, a self extracting homebrew starter pack is installed to the fresh SD card. The starter pack currently included contains Smealums standard homebrew starter pack plus a little extra. And yes, that includes the menuhax manager. Your friend still needs to get his first entry point himself (browserhax maybe?), but afterwards he can use menuhax manager to set it up.
You can also, very easily, customize the starter pack ("starter.bin") to include the files / CFWs / homebrews you want. You only need to create a ZIP file, then process it via an included .BAT file. ReiNAND is already included (but you need to hunt down the evil firmware.bin file yourself), and I think that would be the much better choice of CFW for a noob (auto starts, doesn't contain additional tools that could brick the 3DS), but if you insist on rxTools, you can include that into your custom starter.bin.
In short, include everything that you want to send your friend into your custom starter.bin.
(1)Alright, still not sure if I got that right . You can only do a Nintendo (home menu) System Transfer once the NAND is already set up, but that is not what you mean, right? So, you transfered the backup from 3DS-A to 3DS-B? For all that I know right now, that should not work at all. The first barrier would be the different encryption (fixable), but that is not everything that stands in the way.
Well, the EmuNAND size is decided the same way everyone else does it now (CakesFW, rxTools, ... even GW). EmuNAND9 is different from GW in that GW just decides to use a big chunk of your SD card (big enough to handle any size), while EmuNAND9 chooses the size based on the actual flash memory size. The EmuNAND created by EmuNAND9 should still be exportable by any other tool. Could you specifiy or give an example?
By the way, while the flash memory sizes differ, the actual NAND size does not. EmuNAND / SysNAND backups can easily be fixed to work on any flash memory size by truncating / padding. I could even build this right into EmuNAND9 (and yes, we could even save more memory). I need more details, though.
Yes, the EmuNAND9 folder, including starter.bin, goes to the root of your SD card. To fully understand what starter.bin is, you could try renaming it to starter.zip and open in any ZIP archiver utility (no, it is not a standard ZIP file, but close). To create your own, make a ZIP fiel of your own setup and then drop it onto drop_zip_here.bat inside the starterGen folder (inside the EmuNAND9 release archive).sweet thanks, but could you tell me what to do with that starter bin file? it is in a folder titled emuNAND9 < this folder goes to the root of sd yes?
and as for the the emunand9 app i know that i will have them push the folder containing the .3dsx .smdh into the 3ds folder.
thanks!
A question before debugging more on my end - is the emunand created by this tool the same partition size as one created via the GW launcher.dat?
First, I dumped the (GW-created) emunand from my working card into a file using EmunandTool. The file dumped was 1.84 GB (1,979,711,488 bytes).
I did a quick setup on a new SD card using EmuNAND9Tool and then tried to inject the dumped file into the new partition created. The tool generated an error about the size. It wasn't obvious if the older EmunandTool was expecting a larger or smaller partition size.
I then created a partition with the GW launcher.dat and the emunand injected without an issue.
tl;dr Are the partitions created by your utility the same size/configuration as those created with the Gateway utility? And if not, is there a utility out there for dumping/injecting emunand to/from an old Gateway emunand that is more compatible with this utility? I'd prefer to use your EmuNAND9Tool going forward for creating emunand SD cards.
Please let me know if you need/want any more debugging information.
I think d0k3's tool formats the partition based on the nand chip size. GW reserves extra space when partitioning.
Thanks! Just found some relevant info. I'm cloning my N3DS 1.2GB nand into the 2GB partition on an old card. Hopefully that will work properly.
http://3dbrew.org/wiki/Flash_Filesystem
https://gbatemp.net/threads/how-big-is-the-nand-dump-of-new-3ds.384736/
Oh well... that issue is annoying as hell. What really goes on here is (1) that GW just chooses the biggest possible size for EmuNAND when formatting (ignoring actual flash chip sizes) and (2) that emuNAND Tool assumes that this is the correct and only way to do it and won't accept any other sizes. If we had the source code of emuNAND Tool, it would take me / us 1h tops to either make EmuNAND9 only generate EmuNAND-Tool-compatible EmuNANDs or (better!) to update EmuNAND Tool to make it more compatible. Without the source code, it is trial and error and could take a very long time.(1)
For example:
3DS-A is 10.3.0-28J Samsung 954MB NAND chip.
3DS-B is 4.5.0-10J Toshiba 943MB NAND chip.
After I system-transferred 3DS-A NAND to 3DS-B emuNAND, I dumped 954MB 3DS-B emuNAND image with emuNANDTool 1.0.3.
This is why I said emuNAND size could be different from SysNAND size.
In this situation, EmuNAND9 can only format 943MB emuNAND partition on 3DS-B with a new SD card, which makes it unable to import that 954MB emuNAND image.
If I want to import that 954MB emuNAND image, I need to find a 3DS-C which has 4.1-9.2 Samsung 954MB SysNAND to make EmuNAND9 format a 954MB partition on the SD card for 3DS-B, then import the image, then switch the SD card back to 3DS-B.
(2)
I tried and knew that emuNANDTool 1.0.3 could not recognize EmuNAND9 created emuNAND.