Legacy creates the EmuNAND the same way GW (meaning: it may waste tons of space). This is useful if you want 100% compatibility with EmuNAND Tool and some other older tools. However, Multi EmuNAND Creator serves the same purpose as EmuNAND Tool and has no trouble with EmuNAND9 default EmuNANDS.
Yes it does that, for O3DS too. That's not wasted space, it is required so that the EmuNAND actually works in CFWs and GW. Also, the start of the FAT partition is always aligned to 4MB (because of erase block bounds, but that goes pretty deep into SD formatting theory).
Hmm... It was at least 10 MB, not much but it's a really small card so every MB counts, not sure but I think that was a bit of wasted space (though I may be wrong on that one it looks like) *shrug* whatever though, still an awesome tool regardless
I'll try to explain... we absolutely need to use at least the size of the NAND chip. Why? Because CFWs expect the first 0x200 byte of the EmuNAND memory to be exactly at offset [SysNAND memory size]. The actual first 0x200 byte of the SD card are used for the MBR.Hmm... It was at least 10 MB, not much but it's a really small card so every MB counts, not sure but I think that was a bit of wasted space (though I may be wrong on that one it looks like) *shrug* whatever though, still an awesome tool regardless
Ah, yeah that makes sense (I did know that the header was moved to the end of the NAND backup to make room for the MBR), what I meant though was after the 0x200 bytes of the NAND header and before the start of the fat32 header I had about 10 MB of extra space (I separated out the NAND backup, MBR, fat32 partition and free space out to separate files and measured them, there was 10 MB of (seemingly) random garbage (no strings or anything distinguishable) though it may have to do with the 4 MB alignment but with the odd size of 10 MB I don really see how that could be the case, (maybe it's because one of the blocks was only half used up or something) But I'd think there'd be SOME data written there, maybe just zero's to pad it or something, I mean sure as little reads/writes as possible helps extend the life of the card as much as possible... anyways doesn't really matter I was mostly curious
10MB is too much... You already know that the NAND header has the distinct 'NCSD' string in there and may look like garbage bytes otherwise? Can you give me the exact size of your NAND (coincides with the size of NAND backups by EmuNAND9 / Decrypt9) plus the FAT32 offset? The MBR (first 0x200 byte) could help as well, as EmuNAND9 writes helpful info in there.
This emuNAND was made long before EmuNAND9 was a thing, so what I'm saying is, GW probably does it to the max size of the o3ds NAND (there a 2 sizes, don't know the difference between them), yes I know the NAND header has NCSD in it and I would have considered that a string... I'll do a bit more investigation after I eat in a bit (looks like there's some strange stuff already going on based on some quick research)
Now I understand... well, GW uses one size fits all, thus both O3DS NAND chip sizes lead to a same size EmuNAND in GW.
Run it straight through sysNAND, no CFW involved, you'll get better results
Yes
Ah, OK I thought you meant you somehow manually updated the emuNAND version... You possibly need to set emuNAND up again, not 100% sure
just backup the Nintendo 3DS folder and as long as sys and emuNAND are linked then your games will show up... nothing you can do afaik if they're unlinked
