Hacking Why should I switch to sysnand?

  • Thread starter Thread starter Seriel
  • Start date Start date
  • Views Views 11,084
  • Replies Replies 96
well luckily i do have emuNAND backup, just in case.
but since i wanted a fresher cleaner mSD i went on ahead and swapped nands then wiped my GW emuNAND partition. ( i have had used my GW card very rarely since i only play .cia)




yeah, but i guess i will leave that be for now, as everything is working perfectly for me :)
All the other stuff for the nand is pretty small
 
  • Like
Reactions: leonmagnus99
All the other stuff for the nand is pretty small

then i wish i had dumped/injected those once as well, but oooh well xD too late.

and i am way to lazy to work on that (by having to create emuNAND again bla!)
so i would assume my n3ds would only have issues playing gba/ds games yah?

if thats the only issue, then i am fine with the way it is.

cause i only play ds/gba rarely on my og3ds. and they work fine on them.
 
Just finished switching, everything went well :)
Managed to shave 4 seconds off the boot time by removing the emuNAND partition and changing from exFAT to FAT32 with 64kb allocation unit size.
 
Just finished switching, everything went well :)
Managed to shave 4 seconds off the boot time by removing the emuNAND partition and changing from exFAT to FAT32 with 64kb allocation unit size.

what program did you use ? i was not given the allocation size with Easus, only NTFS allocation shows up for me to choose what to use, but when i selected FAT32 it would not appear.

i wonder how important that 64kb allocation size is XD
 
what program did you use ? i was not given the allocation size with Easus, only NTFS allocation shows up for me to choose what to use, but when i selected FAT32 it would not appear.

i wonder how important that 64kb allocation size is XD
I used EaseUS Partition Master. FAT32Format GUI should also have this option, although I couldn't get it to run on my system.
 
  • Like
Reactions: leonmagnus99
I used EaseUS Partition Master. FAT32Format GUI should also have this option, although I couldn't get it to run on my system.

i have used the same ._.

i think it put allocation size for my mSD automatically since it did not give me the option to manually change it,

but for NTFS format it would allow me to manually input whatever allocation size i wanted.
but for FAT32 it would not, oh well i should be fine ovo..

how much seconds does it take for u to boot into your aurei cfw sysNAND :) ?

mine takes.. like 7-10 seconds ..
 
i have used the same ._.

i think it put allocation size for my mSD automatically since it did not give me the option to manually change it,

but for NTFS format it would allow me to manually input whatever allocation size i wanted.
but for FAT32 it would not, oh well i should be fine ovo..

how much seconds does it take for u to boot into your aurei cfw sysNAND :) ?

mine takes.. like 7-10 seconds ..
I'm using a 128GB card, which has abnormal boot times. With an emuNAND partition it would take 13 seconds, but now it boots up in 9. Currently I'm also testing the same on a 64GB card on a separate console to see if there are any changes.
 
  • Like
Reactions: leonmagnus99
I'm using a 128GB card, which has abnormal boot times. With an emuNAND partition it would take 13 seconds, but now it boots up in 9. Currently I'm also testing the same on a 64GB card on a separate console to see if there are any changes.

9 seconds is normal , pretty good.

even 13 seconds is good mate, but what are you filling the 128 mSD with.. LOL.
i have 64gig and still got 20gigs free with 30-50 cias installed.
 
  • Like
Reactions: NekoMichi
9 seconds is normal , pretty good.

even 13 seconds is good mate, but what are you filling the 128 mSD with.. LOL.
i have 64gig and still got 20gigs free with 30-50 cias installed.
So far I've used up about 60GB, some of it is from full ROM sets. I have full ROM sets for the NES, SNES, GB, GBC, and some Sega systems for some retro gaming on the go.
 
So far I've used up about 60GB, some of it is from full ROM sets. I have full ROM sets for the NES, SNES, GB, GBC, and some Sega systems for some retro gaming on the go.

thats neat mate,

btw. i read this just now on a ps forum regarding the allocation size,
i dont know how much different it would be considered for a HDD though.
here's what it says.

"
Having a bigger File Allocation Size had its advantages and disadvantages:

Pros:
- Less disk space usage on Large Files
- Fast read times

Cons:
- It consume 2x or 3x disc space on smaller files
* The correct example of this case is "Atelier Meruru" game that is only 2.8GB game but it consumes nearly 4GB of space on FAT32 HDD. This is because that most of the files (3k+ files are less than 256byte which breaks the 32k and 64kbyte cluster size. Each cluster can only store 1 file information, any files is smaller than 32kbyte are will be stored on a single cluster and the remaining space will be consumed, even if that space is empty or null.) are to small that it needs to store every file in individual cluster.
- Slow seek times on files that is stored on a single cluster (file indexing is not implemented on FAT32, NTFS it is) so sometimes you have to wait much longer unlike when you play it using BD disc.
* Correct example is "Naughty Bear" game.

---------------------

On most cases: you should keep your self on 32kbyte cluster size, to avoid problems."

i have no idea what Easus Partition Master has put for me (with the allocation size) as when i formatted my mSD some day ago, it did not let me choose a manual Allocation Size.

so i just went on and formatted it without being able of doing so, so i guess it has made it default

ah to check the allocation size, chkdsk can be used.
 
Last edited by leonmagnus99,
  • Like
Reactions: NekoMichi
Argument for life of SD Card vs NAND is bogus for 2 reasons:

1) SD Cards these days are rated for 1,000,000 writes. If you write 100 times per day to it it will last you 27 years. Realisitically you probably write to it far less than that, maybe one or two times per day if your system is on 24/7. Reads do not effect life time.

2) NAND is rated for about as many read/writes as SD Cards. Id much rather have an easily replaceable piece of hardware die than soldered on chip.

At the end of the day though your 3DS will die way before memory dying is a concern.
 
Last edited by Chrushev,
-less space taken up on SD card
-longer life for your SD card (reads and writes to NAND are done on the actual 3DS NAND chip not on your SD card. SD cards are only good for a certain number of reads/writes so extends life)
-only install DSi/GBA once
-closer to a truly hacked system ... feels like you've really beaten your console

be honest, with the extending life thing, how many years are we talking here until that becomes relevant?
 
what program did you use ? i was not given the allocation size with Easus, only NTFS allocation shows up for me to choose what to use, but when i selected FAT32 it would not appear.

i wonder how important that 64kb allocation size is XD
When I choose to format a partition, this window comes up:

Screen Shot 2016-04-04 at 23.00.40.png

The allocation unit size can be set under "Cluster Size". Do you have the same options as above?
 
My N3DSXL doesn't have the space where the SD card heat up as much as when I use EmuNAND which basically made my 3ds run on my SD card
 
I was actually thinking of switching to sysnand. Does it matter if you installed arm9 on emunand or sysnand?
 
I was actually thinking of switching to sysnand. Does it matter if you installed arm9 on emunand or sysnand?
A9LH is only installed to SysNAND, you can use the new Decrypt9 to restore your EmuNAND to SysNAND without erasing A9LH (which would require a reinstall on a O3DS or Brick a N3DS)

first, update Decrypt9 (download the new decrypt9 zip and copy the bin to /aurei/payloads/ and name it "default.bin")
then you will want to backup your current EmuNAND to "emuNAND_original.bin"

Copy and Paste from @Plailect's Guide

Enter Decrypt9
  1. Reboot, then open Decrypt9 from arm9loaderhax by holding L+R on boot
Copying RedNAND data to SysNAND
  1. Go to "SysNAND Options"
  2. Go to "SysNAND Backup/Restore..."
  3. Select "NAND Restore (keep a9lh)"
  4. Confirm and restore from emuNAND_original.bin
----------------
Once you do this, you will be on 10.7 (or whatever version your EmuNAND/RedNAND was on) SysNAND and have retained A9LH.
 
Last edited by driverdis,
  • Like
Reactions: Harvest God
When I choose to format a partition, this window comes up:

The allocation unit size can be set under "Cluster Size". Do you have the same options as above?

mine is abit different mate, it shows allocation size on the right side.
either way, i think its fine :)

i wont re-format just for the cluster size thingie XD
thanks .
 
I've tested a few console/setup combinations, here are the results:

O3DS A9LH + AuReiNAND 4.1 (SanDisk Ultra 32GB microSD + adaptor)
9.2 sysNAND + 10.7 emuNAND - 8 seconds to boot into emuNAND
9.2 sysNAND + 10.7 emuNAND - 8 seconds to boot into sysNAND
10.7 sysNAND + no emuNAND - 8 seconds to boot into sysNAND

N3DS A9LH + AuReiNAND 4.1 (SanDisk Ultra 128GB microSD)
9.0 sysNAND + 10.7 emuNAND - 13 seconds to boot into emuNAND
9.0 sysNAND + 10.7 emuNAND - 13 seconds to boot into sysNAND
10.7 sysNAND + no emuNAND - 9 seconds to boot into sysNAND

N3DS XL A9LH + AuReiNAND 4.1 (SanDisk Ultra 64B microSD)
9.2 sysNAND + 10.7 emuNAND - 8 seconds to boot into emuNAND
9.2 sysNAND + 10.7 emuNAND - 8 seconds to boot into sysNAND
10.7 sysNAND + no emuNAND - 7 seconds to boot into sysNAND

Additional testing procedure notes:
All memory cards were formatted to FAT32 with an allocation unit size of 64KB. Prior to testing, each console was booted into the Home Menu and then shut down at least once to allow AuReiNAND to patch the firmware.bin. AuReiNAND's "use pre-patched firmware" option was enabled to prevent firmware patching from interfering with the boot time. Replicate tests for each console/setup combination were unnecessary as boot times were consistent and showed no significant variance.
Booting A9LH into sysNAND with no emuNAND partition gave boot times that were almost identical to the negative controls (unmodded consoles) whereas booting to sysNAND with an emuNAND partition present yielded no change in boot time as compared to booting to emuNAND. It looks like there comes a point where the NAND setup location no longer becomes a limiting factor, for O3DS the shortest boot time achieved was 8 seconds while on N3DS the minimum time was 7 seconds. Anything below that would involve other bottlenecks such as SD class.
 
Last edited by NekoMichi,

Site & Scene News

Popular threads in this forum