Shuffle Install Semi-Works on 3DS with 64 KB Cluster Size #132
Comments
|
I recently acquired a SanDisk 200 GB micro SDXC. This one is formatted as FAT32 and 64 KB and is being used on a second system, a New 3DS (original). It has been checked for authenticity with H2testw. Specifications of the New 3DS
This handheld does not exhibit lag navigating and scrolling through the themes list. I have no trouble installing a 10 theme shuffle. It doesn't stutter or crashes. I will add more themes into the folder and see if I can get Anenome3DS to crash. If after adding 1000 themes into the folder and the problems do not come up, I'll go back and check my N3DSXL with the 128 GB card by freeing up space. That 128 GB only has about ~1.5 GB free. This might be the issue. |
|
Alright, results are in. To ensure having too many themes doesn't cause the crash, I added a total of 1608 themes. Instead of doing 1000 themes as stated before, I wanted to try testing for an upper limit by having over twice the total of my N3DSXL's 787 themes count. On the N3DS, Anemone3DS lags a bit when scrolling through the themes as the icons refresh and load up. I picked the 10 themes at 160 intervals to check if Anemone3DS installs themes from anywhere in the list and not just those closer up front. Themes were queued in shuffle while fast scrolling down the list pressing the right d-pad and pressing (B) before allowing the icons to finish loading. After having 10 themes in queue, I pressed and held (A), pressed and held d-pad (down), and let go of (A). After several seconds, Anemone3DS went back to the theme list and experienced a frozen crash with no log dump. Forced restarting the N3DS, all 10 random themes appeared and persisted in Home Menu. You guys can close this issue as we now know that this is not necessarily a problem of the app itself or SD cards with 64 KB cluster size. Add a warning in your release footnotes and on GBAtemp thread that the SD card needs sufficient amount of free space in order for Anemone3DS to work at these extremes. Edit - Wait, don't close this issue just yet. I still need to check if freeing up space on the 128 GB card makes Anemone3DS stable on the N3DSXL. Edit #2 - I failed to mention I have a second 256 GB (non-micro) SD card (with cable adapter) that is an almost identical copy from the 128 GB card for the N3DSXL. Using Anemone3DS on this card with 64 KB and 787 themes also produces the crash, even though only 117 GB is used of the available 238 GB. I'll try to troubleshoot my N3DSXL with a fresh reinstall of NTRboot and files build on its cards without borrowing any of the stuff that are on them now. Perhaps the problem stems from a minor corrupted custom firmware. For the N3DS, one last stress test I'll try is to fill up the 200 GB card with random crap until there's only 1 GB free. Check Anenome3DS again if it'll fail to shuffle install then. |
|
A separate 'crap' folder placed in the SD card root of the N3DS was filled with various winRAR archives of different 3DS games. All of these were made with the best compression setting, which produces the smallest archive file size in winRAR. (1) free space @ 620 MB - Anemone3DS installs all 10 themes in shuffle. Themes were chosen again at 160 intervals offset by +1 theme; these 10 were not the same themes from early. Again, Anemone3DS completes shuffle install and returns to theme selection with a frozen crash. (2) free space @ 8.62 MB - Added more winRAR archieves into 'crap'. The same steps and process were followed as before. The app still freezes and crash returning to theme selection after shuffle is installed. Fortunately, both scenarios produced 10 themes on shuffle working and persisting at Home Menu. At this point, I am happy to report coming to the conclusion that Anemone3DS is a solid homebrew app that gets the job done when put through its paces. However, what is astonishing and disappointing is finding two separate systems (N3DS & N3DSXL) with similar configurations have their respective Anemone3DS differ so much in stability. Both N3DSXL and N3DS had their original files first built on 128 GB micro SD cards. These cards were both formatted in FAT32 and 32 KB cluster size before being stuck in the 3DS and having any files added onto the cards by computer. The reformatting programs used were AOMEI Partition Assistant Pro Edition v6.0 -and- later, guiformat.exe .
For the N3DSXL PNY Elite Performance 256GB High Speed SDXC (P-SDX256U1H-GE) Files count and byte size were checked to match under Windows right-click properties. The Lexar card was then reformatted in FAT32 / 64 KB cluster size. Everything on the PNY standard card was copied back over onto the Lexar micro card. The N3DSXL has been testing both cards, which have been drifting in build due to other games and homebrew apps testings. For the N3DS The SanDisk micro card is an LG Mobile promo that wasn't meant for resale. [SDSDQAD-200GB-2100E] The N3DS has switched over to using only the SanDisk micro card. Its files and games library has been steadily growing ever since. Everything else on the N3DSXL appears to work and function as expected. Anemone3DS is the odd one out for all the installed homebrew apps. I will try testing the PNY micro card from the N3DS on the N3DSXL with an empty build having only Anemone3DS and the many themes. If crashes appear under those conditions, the NTRboot reinstallation will get the go ahead. |
|
YES!!! Wonderful news! I was able to recreate the bug crashing Anemone3DS and may have possibly found a simple solution to fix it. I need more time to retest the procedures in consistently producing the bug before I write the documentation here. I believe something doesn't transfer correctly in the theme Ext Data when going from a 32 KB card to a 64 KB card. Here is my log dump from the latest crash: Edit #1 - Woah! I (Black Screens of Death) BSoD bricked my emuNAND recreating the crash on Anemone3DS. Recovery Mode and battery removal & reinsert does not work in fixing this soft brick. I'm extremely fortunate that sysNAND was intact when booting without an SD card. I backed up a copy of my bricked 'Nintendo 3DS' folder for later examination and study. A new 'Nintendo 3DS' folder was recreated on the 3DS for continual testing for the phenomenon. Guys. Big warning! DO NOT use your sysNAND while on custom firmware. On GBAtemp, there are 3DS owners reporting BSoD soft bricks that are nonrecoverable despite using (Full/Safe) sysNAND restore, CTRtransfer, and Lazarus3DS. These bricks occurred from sleep mode, during a middle of game play, some time after a while going from A9LH to B9S, and out of the random blue with no warning. Their BSoD exhibited LCDs that work only in Recovery Mode and no where else; booting into Home Menu yields blank screens with or without working sound. GodMode9 and Luma Configuration may work if they have CFW installed. Booting the 3DS without an SD card does not change the prognosis. This is just my theory, but I believe my BSoD brick is somehow related to theirs with the only difference is that theirs occurred in sysNAND. To keep your systems safe, your emuNAND and SD card are your 3DS system's first line of defense/condom from catching permanent BSoD. |
|
If you find Anemone3DS crashing or failing to do a complete shuffle install after changing your SD card's cluster size, follow these instructions to correct the theme ext data. How to Properly Setup Anemone3DS when Changing Allocation Size
|
|
While we (as in we the devs) appreciate what you're doing here, I have a couple of questions - first of all, why are you suggesting that an EmuNAND be booted? EmuNANDs are outdated and unneeded in 99.9% of cases at this point, and most of those 99.9% of users don't even have one - it's most likely more to do with 64KiB clusters than the EmuNAND, but it bears mentioning. The second, and probably most important, thing here is the fact that, ultimately, 64KiB clusters are incompatible with the console itself. It breaks a fair few things, including official Nintendo software such as AGB_FIRM (aka GBA VC). Using them with Anemone is therefore unlikely to work and therefore unsupported. |
|
I wasn't finished replying about this issue. It also happens when the card is formatted 32 KB. I just took time away to reply back tomorrow. |
|
@TurdPooCharger - The 'brick' you are experiencing isn't a brick. It's due to invalid theme data being written to the home menu extdata. It can be resolved by removing the theme extdata. Please refer to the screenshot I attached below for how to do this:
Running CFW on sysNAND as long as you either have arm9loaderhax or boot9strap (ideally boot9strap) should be completely secure, as it's possible to recover from most software related bricks with it. emuNANDs should be considered obsolete for the end user. |
|
@ev1l0rd , it is good to hear that it isnt' a (real) brick. The problem has been resolved in issue #134. @Helloman892, to answer your question about auto booting emuNAND. I learned not too long ago that this option does nothing if emuNAND isn't created on SD card with 3DS Multi EmuNAND Creator, so I'm (slightly) better informed why using emuNAND won't work if it's not set up -and- that it is considered pointless because it places the workload on SD card when flash memory wasn't meant to do heavy I/O. However, due to reactional fear of bricking and what appeared as a brick in #134, i thought doing this would mitigate this risk. This doesn't pertain to Anenome3DS, but I've been following and keeping track of GBAtemp users experiencing BSoD with/without working sound on their systems. The symptoms and patterns of failures are very worrying, which lead me to believe my "brick" was somehow related to theirs. One user reports trying sysNAND restore, CTRtransfer, and Lazarus3DS to no positive effects. If this is of interest to you, here is a link of the latest brick with a list of previous cases: https://gbatemp.net/threads/black-screens-on-n3ds-xl.495357/ Back onto the main question, why use 64 KB? I explained this a bit in my GBAtemp post, but I'll do it here again. When using large capacity SD cards such as 128 GB and above, having it formatted in 32 KB has a significant effect on speed performance: ie. Home Menu loading, in-game play lag, etc. 64 KB is thought to be a solution to these but at a price... When I started my 64 KB research, I full well knew those speed gains could/would break compatibility with certain Nintendo & homebrew apps/games. As was seen here for Anenome. I was documenting my finds because there are other users who use your theme manager in 64KB, even if it's not support and you guys have every right not to troubleshoot support them/me as was explicit about the needed proper cluster size choice. Your program received extra attention and testing as it was one of the first homebrew apps to outright seemingly break on me. I went ahead trying to figure out if anything could be done to remedy this incompatible, so that all users (not just those on 32KB) can enjoy this wonderful app. I hope what was posted here will get put into good use for those "odd/incorrect" 64 KB users but also figuring out why Anenome sometimes act strange in 32 KB with that theme ext data. Perhaps an in-built theme scripting can be implement in a future release that can properly auto configure that ext data, so app stability/performance is consistent? I dunno, you guys make heads/tails out of this. If anything good (technically bad?) stems from all this, is that it lead to finding and nipping issue #134 in the bud before someone else less technically experienced ran into that pitfall and freaks out not knowing what to do. I hope that answer all the questions here. I have nothing else to add or report about this cluster size biz. Edit - Actually, I do have something to add. You guys deserve to be proud in your creation. It went into the brutal ringer and came out winning. As for other homebrew apps on my to-do list, I'm gonna need more coffee. |
|
This is an old thread however I was sent here during my research for the same problem. I eventually found an easy solution: @cherrypie287 - "I don't know why, but, I managed to resolve the issue by turning on Enable game patching in Luma3DS settings (select on boot), which i turned on for an unrelated reason. Themes are now fully working for me. Strange that this is required for the 256GB SD card, and not for the smaller one, but I'll take the little victory!" src: #210 |
My original and more detailed write-up is here at this post in GBAtemp:
https://gbatemp.net/threads/do-256gb-cards-even-work-on-3ds.469117/page-2#post-7789084
I've been stress testing several games and homebrew apps, one of which is Anemone3DS v1.3.0. The test is to check for compatibility and gain in speed performance when using regular-sized & micro SD cards with large capacities such as 128 GB and 256 GB. The control variable is that the cards are freshly FAT32 reformatted with 64 KB cluster size instead of the recommended 32 KB.
As stated in my GBAtemp post, Anemone3DS is able to navigate and install all 10 themes when the cards were in 32 KB allocation size. It may occasionally crash, but the app will eventual complete its task with a full shuffle.
When the cards are in 64 KB allocation size, Anemone3DS will only install at most approximately 4 or 5 themes before crashing. Pictures of the log dump can be seen in that post.
To remedy the problem under 64 KB allocation size, Anemone3DS can install all 10 themes when the Theme folder has a more reasonable number of themes (a count of 10 instead of the original 787 total).
The text was updated successfully, but these errors were encountered: