the black boxes ,can seem to get them to pop up no more , only the fancy GUI now?.. anyway to get them back on newer custom firmware?..
also couple questions..
I'm on sysNAND : 6.2.0
then AWS emuMMC 7.0.2
using exFAT partition right now.. -( but i heard this has many issues, or can create them?)..
I'm trying to figure which is better and smoother for playing games on the switch on the formats listed above *between FAT32 and exFAT* .. but most of all, i just want to really know which is more stable..
or does this exFAT format or both??, become more stable on higher *Custom-firmware(s)* u go on here?...
also couple questions..
I'm on sysNAND : 6.2.0
then AWS emuMMC 7.0.2
using exFAT partition right now.. -( but i heard this has many issues, or can create them?)..
I'm trying to figure which is better and smoother for playing games on the switch on the formats listed above *between FAT32 and exFAT* .. but most of all, i just want to really know which is more stable..
or does this exFAT format or both??, become more stable on higher *Custom-firmware(s)* u go on here?...
okay great, could u possibly guide me through putting back from exFAT to FAT32 so i don't accenditally brick my console , also could i just Transfer my stuff to microSD card when after i format to fat32?..
All you have to do is copy and paste the files onto something else -- a USB drive for example -- via your computer, reformat just that partition (make sure not to use something like the SD formatter that would repartition the whole drive -- a partition manager such as but not limited to MiniTool Partition Manager can do this pretty easily if you want something you can be sure won't erase that emuMMC partition) and then copy the files back over. No matter how you do this you absolutely cannot brick your console. Your worst case scenario is just if you messed up the layout of the memory card you'd lose the emuMMC and installed games -- which sucks, but isn't a brick. If you really want to be sure, you can backup your emuMMC via Hekate or any partition imager on a computer (even just dd in *nix is fine) before messing with the formatting. BTW, it's a LOT of files if you have very much installed (Nintendo splits stuff up a lot, plus a few things like RetroArch just simply use a lot of files if you have it.) Count on it taking a long time. Your mileage may vary, but you might get slightly faster results from making an archive (eg zip, rar, etc) instead of copy and paste if you set it to not compress or to compress very very little (so there is no significant CPU or memory bottleneck) and then extracting that to the new partition after formatting.
As for which is better, I don't think you'll see much of a real speed difference either way. Supposedly exFAT is more optimized towards modern flash drives, but I doubt it makes much difference on an embedded device like this. Your biggest speed advantages will come in making sure the partitions are properly aligned and that you use a 32KB cluster size (64KB may be better, but supposedly some things have problems? That may all be solved by now though. I don't think it makes a huge difference anyway, so 32KB should be fine for fairly optimal results.) The main advantage of exFAT versus FAT32 is large file (>= 4GiB) support and a supposedly better handling of improper removals (though in practice it may be about the same really.) The main disadvantage is... I don't actually know what it is in this specific context beyond that people will fuss at you if you use it.
I'm not saying FAT32 is bad and exFAT is better nor am I really saying the opposite -- in fact it really kind of feels like each has its ups and downs and overall they're closer to even. FAT32 is better supported in open source software and the like but older and more limited whereas exFAT has >=4GiB file support and is just generally more modern all around. In fact, the main evil of it is mostly just its sheer proprietary nature and the ridiculous licensing SD Association does that costs companies so much money that they do messy stuff like what Nintendo did for instance. But this is a specialized application, not your daily driver across multiple USB flash drives or something of that sort, so whatever is most optimized for the needs of the application matters more than principle here. (Plus Nintendo has already dealt with the licensing stuff and that isn't our problem. This isn't like some Kickstarter where they simply can't afford to pay it or something.) I know some early homebrew did have troubles back when it basically tried to do stuff on its own, but does any at all today? Homebrew has already come a long way since the early Switch hacking days.
If people are going to say this over and over, at least they could provide a reason.
As for which is better, I don't think you'll see much of a real speed difference either way. Supposedly exFAT is more optimized towards modern flash drives, but I doubt it makes much difference on an embedded device like this. Your biggest speed advantages will come in making sure the partitions are properly aligned and that you use a 32KB cluster size (64KB may be better, but supposedly some things have problems? That may all be solved by now though. I don't think it makes a huge difference anyway, so 32KB should be fine for fairly optimal results.) The main advantage of exFAT versus FAT32 is large file (>= 4GiB) support and a supposedly better handling of improper removals (though in practice it may be about the same really.) The main disadvantage is... I don't actually know what it is in this specific context beyond that people will fuss at you if you use it.
I keep seeing people say this, but other than a vague "exFAT is bad" I haven't really seen anyone yet say why. I've been using exFAT with my Switch since day one and I've only ever had it show up as "dirty" once which was fixed simply by running chkdsk and this was almost definitely caused by pulling out the memory card before the system was truly fully shut down (mostly back before the recent Atmosphere update when it didn't actually shut down once you hit power off.) I've been using FAT32 since the day it first came out and over the years several times I've lost entire file allocation tables with the secondary table being woefully out of date and significant portions of data being lost in the process and once I even basically lost everything as the secondary FAT was basically empty. (And yes, I know the data was still technically there and via a long, convoluted process I could have restored it all, but unless there is something just incredibly important in there it usually isn't worth it so back then I just ended up reinstalling and all.)
I'm not saying FAT32 is bad and exFAT is better nor am I really saying the opposite -- in fact it really kind of feels like each has its ups and downs and overall they're closer to even. FAT32 is better supported in open source software and the like but older and more limited whereas exFAT has >=4GiB file support and is just generally more modern all around. In fact, the main evil of it is mostly just its sheer proprietary nature and the ridiculous licensing SD Association does that costs companies so much money that they do messy stuff like what Nintendo did for instance. But this is a specialized application, not your daily driver across multiple USB flash drives or something of that sort, so whatever is most optimized for the needs of the application matters more than principle here. (Plus Nintendo has already dealt with the licensing stuff and that isn't our problem. This isn't like some Kickstarter where they simply can't afford to pay it or something.) I know some early homebrew did have troubles back when it basically tried to do stuff on its own, but does any at all today? Homebrew has already come a long way since the early Switch hacking days.
If people are going to say this over and over, at least they could provide a reason.
Last edited by Nazosan,
It's because HOS doesn't properly terminate file access or something and can leave handles hanging open when the program (homebrew, in this case) doesn't shutdown properly, or something. I'm not an expert, it's something i read a long while ago somewhere in a discussion between CTCaer and SciresM, i think.
This eventually leads to file table getting corrupted, since exFAT has only one file allocation table (insted of the two redundant ones for FAT32) and it can't be corrected from a backup table.
It's a slow and erratic process and doesn't always have to be immediately noticeable, when less-used file parts get garbled somewhere. But eventually it hits something important and errors will pop up.
This eventually leads to file table getting corrupted, since exFAT has only one file allocation table (insted of the two redundant ones for FAT32) and it can't be corrected from a backup table.
It's a slow and erratic process and doesn't always have to be immediately noticeable, when less-used file parts get garbled somewhere. But eventually it hits something important and errors will pop up.
Last edited by Krude,
I have 3 partitions on my SD card. I have setup emunand on one of the partitions. How do I setup a second emunand on the other partition? When I click 'create emummc', it says 'found applicable partition [Part 1] which is where the original emunand is. Does it automatically pick the next available partition? I don't see a way to select which partition I want it to install to.
I have no idea what an official way of doing it might be, but one trick you maybe could do is just delete the partition from the partition table then restore the partition table after it creates the new one. This would be easiest with Linux (fstab and dd can do it all in mere moments) but I'm sure there are tools for other OSes. If you're starting from the same base firmware you could simply image the second partition via the same image that went into the first instead of jumping through these hoops. Doing that on a PC would be faster than doing it through Hekate anyway.
BTW, I'm actually using FAT32 at this point just mostly so I don't have to deal with flak from all the people insisting that you shouldn't even get support for issues if you dare to run exFAT, but I have used exFAT right up until just a couple of days ago with only that one problem in all this time. I just wanted to know why people make such a big deal about it. Actually, I still don't see why people make quite that big of a deal about it even in light of this.
Well, thanks for the answer. Though I still disagree with that as I've found that the backup table in FAT32 is unreliable at best anyway. Frankly, as far as I'm concerned, that secondary FAT is virtually worthless. In an emergency you might be able to restore a few things, but generally the conditions that cause the first to fail make the second so damaged that you have to start over anyway. What we REALLY need is a proper journalizing filesystem, but I suppose there's no way that can happen. It's sort of too bad when you think about it. If Nintendo had used, oh, say, EXT4 and just simply setup a UMS connection (or even MTP or that photo protocol, whatever it was called) when plugging it into a PC or something of that sort it would have been pretty much just as effective for their intended use scenarios (which is pretty much just transferring stuff like screenshot images or videos to a PC.) Plus they wouldn't have had to pay SD Association a single dime extra beyond whatever bare minimum licensing might be (if any) involved it having a microsd slot.
BTW, I'm actually using FAT32 at this point just mostly so I don't have to deal with flak from all the people insisting that you shouldn't even get support for issues if you dare to run exFAT, but I have used exFAT right up until just a couple of days ago with only that one problem in all this time. I just wanted to know why people make such a big deal about it. Actually, I still don't see why people make quite that big of a deal about it even in light of this.
Honestly both are bad. ExFAT really should have been made more modern instead of basically just duplicating the same basic functionality of a filesystem from 1977 barely updated mostly just for large file support. I just doubt one is truly inherently worse than the other in this context.
Lol, Atmosphere and Hekate should add ext3/4 support.
Lol, Atmosphere and Hekate should add ext3/4 support.
I got excited after I received my RCMLoader One and proceeded to get to where I have NSPs installed and forgot to do a backup first
What should I do to make a backup now? Do I just do the backup as usual or do I have to delete some stuff?
What should I do to make a backup now? Do I just do the backup as usual or do I have to delete some stuff?
Yeah just take a full backup now (don't forget BOOT0/1 as well as rawnand). Any backup is good for in case anything goes wrong in future. If you ever want a "clean" nand for online etc, deleting stuff now wouldn't help, but you could use the method to build a new nand based on your backup.
Sorry if this unrelated, anyone know how to fix my time in the hbmenu? Mine shown wrong time in the homebrews.
- Joined
- Feb 23, 2015
- Messages
- 575
- Trophies
- 0
- Age
- 25
- Location
- France
- Website
- www.youtube.com
- XP
- 1,536
- Country
I have a weird issue. Because I was on vacation, I didn't have my Switch for a month. Today I booted hekate and, surprise, touch does not work ! (Actually, il works on the top menu bar but I can't launch anything). I thought my Switch was broken but in HOS everything is fine. And touch still don't work in hekate even after booting HOS before :/
Is this new or is my switch somehow broken but HOS seems to still understand the input from the display ? Is there a way to fix it, use button control at least ? Thanks
Is this new or is my switch somehow broken but HOS seems to still understand the input from the display ? Is there a way to fix it, use button control at least ? Thanks
So I seem to be having the "unable to mount" problem. (It doesn't actually say this anymore it seems, but Nyx never loads and if I go into system information and select SD card it says it's unable to mount a FAT partition.) I've tested multiple cards, rebuilding the MBR, using both FAT32 and exFAT, and reseating the memory card reader (BTW, mine had the foam material used to help hold it in place so it shouldn't come loose on its own.) My best guess is that I removed the card too soon and maybe after a while that can damage it? (It's so difficult to know exactly when it's safe to remove after shutting the system down.) Here's the thing: when I disabled autoRCM and booted stock (I'm using emuMMC for my CFW stuff so can get to stock if I disable everything) it can see the memory card fine in the stock OS. Of course I can't do any serious game testing since stock stays offline and I no longer have any cartridges (which wouldn't test the SD card anyway.) I can say it's not just Hekate because I tried booting the Atmosphere payload directly and it too said it was unable to mount.
I saw the thread about that and the discussion of the 1-bit versus 4-bit interfaces and how high speed cards officially call for the faster interface in specifications. One person showed how they had a pin broken off of the connector somehow and apparently that required falling back to 1-bit for it to work. What I'm wondering is if my card reader has somehow been damaged in such a way that only that works and the stock OS would fall back to 1-bit. It strikes me that if this is the case, shouldn't Hekate also do so if 4-bit fails to work correctly? It's better to have it working exceptionally slowly than not at all.
EDIT: I replaced the memory card reader and now it works, so I can confirm that something was definitely wrong with it.
I saw the thread about that and the discussion of the 1-bit versus 4-bit interfaces and how high speed cards officially call for the faster interface in specifications. One person showed how they had a pin broken off of the connector somehow and apparently that required falling back to 1-bit for it to work. What I'm wondering is if my card reader has somehow been damaged in such a way that only that works and the stock OS would fall back to 1-bit. It strikes me that if this is the case, shouldn't Hekate also do so if 4-bit fails to work correctly? It's better to have it working exceptionally slowly than not at all.
EDIT: I replaced the memory card reader and now it works, so I can confirm that something was definitely wrong with it.
Last edited by Nazosan,
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
A @ Aglae Pheryl:Is anyone familiar with former forum opg.life ? I missed the transition to the new forum over the week end (was scuba diving in the sticks with no internet connection). If anyone in touch with any members please pm me.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
AncientBoi:
And a part of my immediate family passed also. Sending my good suit to the cleaners for the funeral Saturday -
-
(
