Quickest ( I think ) way to convert Atmosphere style microsd+emunand to SXOS style microsd+emunand

tivu100 · Apr 8, 2021

After spending hours (first time doing this), I finally succeeded by following this guide.

My question is, can I hook Atmosphere to ruse this same EMUNAND, without doing the same partitioning (partition to file, moving partitions) steps?

Inaki · Apr 8, 2021

tivu100 said:
After spending hours (first time doing this), I finally succeeded by following this guide.

My question is, can I hook Atmosphere to ruse this same EMUNAND, without doing the same partitioning (partition to file, moving partitions) steps?

Yes. You can add this config so that atmosphere uses that same sxos style emunand:

https://gbatemp.net/threads/how-to-setup-atmosphere-emummc.541060/

Create > emummc folder on the root of the SD

Create > emummc.ini file inside of emummc folder

Copy and paste this to emummc.ini

EDIT: I have been warned about these field names being obsolete, so I removed the emummc_ beginnings, these are now correct.

[emummc]
enabled = 1
sector = 0x2
nintendo_path = Emutendo

Erol · Apr 12, 2021

interesting thanks

DbGt · Apr 16, 2021

Mmmn as sx os will probably not be updated anymore, I want to have 2 separate emunands; one for atmos, one for sx os. Both of them resized to about 8 Gb.

I have been experimenting trying to achieve this but I still cant find an optimal way to do it. Any tips?

HalfScoper · Apr 16, 2021

DbGt said:
Mmmn as sx os will probably not be updated anymore, I want to have 2 separate emunands; one for atmos, one for sx os. Both of them resized to about 8 Gb.

I have been experimenting trying to achieve this but I still cant find an optimal way to do it. Any tips?

Here you go: How to resize your emuNAND/MMC | GBAtemp.net - The Independent Video Game Community

DbGt · Apr 16, 2021

HalfScoper said:
Here you go: How to resize your emuNAND/MMC | GBAtemp.net - The Independent Video Game Community

Nice guide, I know already how to resize my nand, but how can I have both resized emunands (one for sx os, one for atmos) on the same sd card?

HalfScoper · Apr 16, 2021

DbGt said:
Nice guide, I know already how to resize my nand, but how can I have both resized emunands (one for sx os, one for atmos) on the same sd card?

Oh sorry I misunderstood your question then, because you didn't mention that you want them on the same SD previously.
Anyway I am also lost there, I tried several things but it seems that chainloading either SX through hekate or hekate through SX is not possible out of the box, unless you fork your own ArgonNX as shady people from RR do for example, but then again it's said that they use a customized boot.dat and SX tries to replace it automatically with the correct one if you boot into SX (a couple of times).

DbGt · Apr 16, 2021

HalfScoper said:
Oh sorry I misunderstood your question then, because you didn't mention that you want them on the same SD previously.
Anyway I am also lost there, I tried several things but it seems that chainloading either SX through hekate or hekate through SX is not possible out of the box, unless you fork your own ArgonNX as shady people from RR do for example, but then again it's said that they use a customized boot.dat and SX tries to replace it automatically with the correct one if you boot into SX (a couple of times).

I don't have any problem chainloading sx through hekate or vice versa. I use payload launcher in Hb menu or reboot to payload

HalfScoper · Apr 16, 2021

DbGt said:
I don't have any problem chainloading sx through hekate or vice versa. I use payload launcher Hb menu or reboot to payload

I'd be grateful if you could share a step-by-step guide on how to achieve this.

If you talk about "Reboot to Payload" you must talk about unpatched units, because I only own a Mariko on which this (amongst other things) doesn't work.
From what I have heard you can just point Atmosphere to the Emutendo folder used by SX to share files between them (if that's what you want to achieve).

DbGt · Apr 16, 2021

HalfScoper said:
I'd be grateful if you could share a step-by-step guide on how to achieve this.

If you talk about "Reboot to Payload" you must talk about unpatched units, because I only own a Mariko on which this (amongst other things) doesn't work.
From what I have heard you can just point Atmosphere to the Emutendo folder used by SX to share files between them (if that's what you want to achieve).

That must be then, yes, i was talking about an unpatched unit. Also, "payload launcher" and "reboot to payload" are 2 different homebrews. I use both

No, i do not want to achieve that, because if I update Atmosphere to fw 12 and above, sx os will not work anymore, thats why i do not want to share them, i want to have 2 separate resized emunands on the same sd card.

I will use sx and xci for every game released till date, and atmos from now on.

HalfScoper · Apr 16, 2021

DbGt said:
That must be then, yes, i was talking about an unpatched unit.

No, i do not want to achieve that, because if I update Atmosphere to fw 12 and above, sx os will not work anymore, thats why i do not want to share them, i want to have 2 separate resized emunands on the same sd card.

I will use sx and xci for every game released till date, and atmos from now on.

Then I apparently still don't understand your question, sorry.
By the way, why use SX for XCI games only? Just install them as you would NSP games with Tinfoil or alike on AMS.

DbGt · Apr 16, 2021

HalfScoper said:
Then I apparently still don't understand your question, sorry.
By the way, why use SX for XCI games only? Just install them as you would NSP games with Tinfoil or alike on AMS.

Well, its not a difficult question i imagine, i just want to have 2 hidden resized emunand partitions, one for SX and one for atmos. I do not want to mix them. So in the end the sd card will have 3 partitions, 2 hidden with a size of about 8 gb and 1 big partition for data files.

Cause I like XCIs, have been using them since day 1, I have a big collection of them already merged with all the updates and dlcs, I dont want to install them when i can just simply mount them, and sx works with all games released till date. So I want to use the "sx emunand" with the xcis i already have, and the atmos emunand for all future releases

Inaki · Apr 16, 2021

DbGt said:
Well, its not a difficult question i imagine, i just want to have 2 hidden resized emunand partitions, one for SX and one for atmos. I do not want to mix them. So in the end the sd card will have 3 partitions, 2 hidden with a size of about 8 gb and 1 big partition for data files.

Cause I like XCIs, have been using them since day 1, I have a big collection of them already merged with all the updates and dlcs, I dont want to install them when i can just simply mount them, and sx works with all games released till date. So I want to use the "sx emunand" with the xcis i already have, and the atmos emunand for all future releases

This is easy, not that I have tried but it should ( even must ) work:

Facts:
- SX OS will only work with a fixed "start of physical space" emunand
- atmosphere can use SX OS emunands by describing it in emuemmc.ini, but forget this; it can work with its own type of emunand ( normally at the "end of physical space" ).

So:
- Format SD as FAT32
- Start with hekate+atmosphere and partition the SD, standard/default Data + 29GB emunand partition or whatever emunand size you want ( but I don't know if SX OS will accept downsized ones EDIT: it does accept them ).
- Mount SD on the computer and start Minitool Partition Wizard. Resize the FAT32 Data partition so that you change its starting point from beginning of physical space to starting at 29.22GB ( or a bit more than what you used on previous step ), so that you leave enough space for SXOS.
- Use EmuTool to save Atmosphere style hidden partition to a file ( it doesn't matter which, SXOS style or atmosphere style ).
- Use EmuTool to restore the saved file to an SXOS hidden partition style.
- Use EmuTool and press Activate emu button selecting the SD as source so that the sector 1 gets the TX NAND mark so SXOS detects and uses it.

After this you can do whatever you want in each emunand.

EDIT: please give feedback if your try

I may try it myself too, just for the sake of trying, I have done several experiments like this...

EDIT2: Since you want totally independent emunands, the Data partition should have both the emueMMC folder and the Emutendo folder and nothing in the emueMMC should reference Emutendo, this will be independent by default, just a warning so that people coming from atmos and sxos shared emunand don't screw up if they use this.

DbGt · Apr 16, 2021

Inaki said:
This is easy, not that I have tried but it should ( even must ) work:

Facts:
- SX OS will only work with a fixed "start of physical space" emunand
- atmosphere can use SX OS emunands by describing it in emuemmc.ini, but forget this; it can work with its own type of emunand ( normally at the "end of physical space" ).

So:
- Format SD as FAT32
- Start with hekate+atmosphere and partition the SD, standard/default Data + 29GB emunand partition or whatever emunand size you want ( but I don't know if SX OS will accept downsized ones ).
- Mount SD on the computer and start Minitool Partition Wizard. Resize the FAT32 Data partition so that you change its starting point from beginning of physical space to starting at 29.22GB ( or a bit more than what you used on previous step ), so that you leave enough space for SXOS.
- Use EmuTool to save Atmosphere style hidden partition to a file ( it doesn't matter which, SXOS style or atmosphere style ).
- Use EmuTool to restore the saved file to an SXOS hidden partition style.
- Use EmuTool and press Activate emu button selecting the SD as source so that the sector 1 gets the TX NAND mark so SXOS detects and uses it.

After this you can do whatever you want in each emunand.

EDIT: please give feedback if your try I may try it myself too, just for the sake of trying, I have done several experiments like this...

EDIT2: Since you want totally independent emunands, the Data partition should have both the emueMMC folder and the Emutendo folder and nothing in the emueMMC should reference Emutendo, this will be independent by default, just a warning so that people coming from atmos and sxos shared emunand don't screw up if they use this.

I made a backup of an sx emunand using nx nandmanager, then i resized it, then i created an emunand using this resized file with the same tool and sx os booted just fine, so yes, sx accepts downsized nands.

I tried your instructions but had some problems:

- Seems like emutools cannot work with resized nands, when i try to convert from hidden partition (resized) to file emunand it gives me an error when finishing "current rawnand 02/07"

-After creating the sd partition and emunand with hekate, theres 16 unallocated mbs at the start of the card in minitool partition wizard, could this create a problem or is it used by atmos/hekate?

i did not follow you completely during the 3rd step, afterresizing the fat32 partition do i need to create a new partition in the unallocated space?

Well, right now im stucked with emutools. i cannot create a file emu from the hidden partition, probably due to the resized nand???, it gives me the error "Error reading disk, start emutools in administrative mode". I started it as an administrator and tried 2 times already, everything goes fine at the beginning but then i get this error after it finishes the rawnand 02/07

EDIT: or maybe it did finished fine but due to the resized nand it thinks theres something wrong and gives me this error?? the files it created are the same size as my hidden emunand..... so probably this is the case

HalfScoper · Apr 16, 2021

DbGt said:
I made a backup of an sx emunand using nx nandmanager, then i resized it, then i created an emunand using this resized file with the same tool and sx os booted just fine, so yes, sx accepts downsized nands.

I tried your instructions but had some problems:

- Seems like emutools cannot work with resized nands, when i try to convert from hidden partition (resized) to file emunand it gives me an error when finishing "current rawnand 02/07"

-After creating the sd partition and emunand with hekate, theres 16 unallocated mbs at the start of the card in minitool partition wizard, could this create a problem or is it used by atmos/hekate?

i did not follow you completely during the 3rd step, afterresizing the fat32 partition do i need to create a new partition in the unallocated space?

Well, right now im stucked with emutools. i cannot create a file emu from the hidden partition, probably due to the resized nand???, it gives me the error "Error reading disk, start emutools in administrative mode". I started it as an administrator and tried 2 times already, everything goes fine at the beginning but then i get this error after it finishes the rawnand 02/07

EDIT: or maybe it did finished fine but due to the resized nand it thinks theres something wrong and gives me this error?? the files it created are the same size as my hidden emunand..... so probably this is the case

If you wouldn‘t use RAW but a file-based NAND, you‘d see that as an example for sizes up to 8 GB there are only 00 and 01 (full.00.bin and full.01.bin) so thats‘s most likely the explanation for the error because NANDs are split into 4GB parts due to the limitations by FAT32, and if it‘s the same size as it should then I guess you are good to go.
I originally tried resizing NANDs with EmuTool an ran into problems aswell, I‘d recommend to use NxNandManager for that aswell as it supports creating NANDs on your SD the same way.

DbGt · Apr 17, 2021

Inaki said:
This is easy, not that I have tried but it should ( even must ) work:

Facts:
- SX OS will only work with a fixed "start of physical space" emunand
- atmosphere can use SX OS emunands by describing it in emuemmc.ini, but forget this; it can work with its own type of emunand ( normally at the "end of physical space" ).

So:
- Format SD as FAT32
- Start with hekate+atmosphere and partition the SD, standard/default Data + 29GB emunand partition or whatever emunand size you want ( but I don't know if SX OS will accept downsized ones ).
- Mount SD on the computer and start Minitool Partition Wizard. Resize the FAT32 Data partition so that you change its starting point from beginning of physical space to starting at 29.22GB ( or a bit more than what you used on previous step ), so that you leave enough space for SXOS.
- Use EmuTool to save Atmosphere style hidden partition to a file ( it doesn't matter which, SXOS style or atmosphere style ).
- Use EmuTool to restore the saved file to an SXOS hidden partition style.
- Use EmuTool and press Activate emu button selecting the SD as source so that the sector 1 gets the TX NAND mark so SXOS detects and uses it.

After this you can do whatever you want in each emunand.

EDIT: please give feedback if your try I may try it myself too, just for the sake of trying, I have done several experiments like this...

EDIT2: Since you want totally independent emunands, the Data partition should have both the emueMMC folder and the Emutendo folder and nothing in the emueMMC should reference Emutendo, this will be independent by default, just a warning so that people coming from atmos and sxos shared emunand don't screw up if they use this.

After i realized that the error i was getting with emutools was probably due to the small size of the nand, i continued with your instructions, and i was able to achieve what i wanted to do. But i do not know how stable it will be, i have read posts of emummc getting corrupted when using minitool partition wizard for resizing the sd card, also for some reason 1 of the 2 games I testes did not worked, i got a message of "checking if the software can be played" when i started it in atmosphere and i just got an error message when starting it in sx os. The other game i tried played fine.

I also realized that hekate cannot do emummc backups or restores of resized nands, even when there is only one and it was created with hekate. I get this error message: "00: rawnand.bin... Failed to find a partition...#FFDD00 Failed!"

Also emutools does not work with a single rawnand.bin file, i tried to create emunands from hekate backups with emutools and it wanted the backup to be in multiple files, otherwise i get an error 10 sec after beginning the process saying it cannot find the other files. So this means that resized nands created with nxnandmanager cant be used with emutools.

Other thing i found out is that if I made a resized emunand with hekate of 8gb,when my internal sysnand had only 4.1 gb free, I will have 2.6gb "internal memory" free in my resized emummc. If I made a full sized emunand, then deleted all games so my internal memory that was copied from sysnand goes from 4.1gb to about 23gb (or 25? dont remember) free, then i made a backup of this emunand, then i resized it with nxnandmanager to 8gb, Im the end I will have 5.3gb of "internal memory" with this resized emunand.... so which is correct? and why are they different? both are 8gb in size, and all games and save data should be deleted in both when resizing the nand...... so why the different "internal memory sizes" displayed in the switch?

4 days ago I did not know anything about how atmos or emunand/emummc worked, i have been an sx os user since day 1 almost 3 years ago, and i have always used sys CFW. After reading countless threads, guides and experimenting for 3 full days (and i meant this: from early morning to late night nonstop, so much time "wasted") I just realized this setup I wanted to do is a huge pain in the ass to set up and maintain for one reason or another. I guess i will just leave sx os as sys CFW and create only 1 atmos emummc (probably not even resized) and thats it. If i want to play online i will just use another sd.

EDIT: I just found out that emutools cant convert hidden resized emunand partitions made with nx nandmanager, as its emunand is both compatible with sx and atmos, i tried selecting as source in emutools both sx and atmos hidden partition but i got the same result: a full sized nand conversion even though my resized nand is 8gb big, emutools can even see that the total blocks are 8,323,072 but for some reason it continues to make a conversion like if it was a full size nand and in the end i have a 29.1gb file emunand which i dont even know if it works as its not useful for me.
This problem does not happen with an emummc created with hekate, emutools will say theres an error at some point but the conversion is good.

HalfScoper said:
If you wouldn‘t use RAW but a file-based NAND, you‘d see that as an example for sizes up to 8 GB there are only 00 and 01 (full.00.bin and full.01.bin) so thats‘s most likely the explanation for the error because NANDs are split into 4GB parts due to the limitations by FAT32, and if it‘s the same size as it should then I guess you are good to go.
I originally tried resizing NANDs with EmuTool an ran into problems aswell, I‘d recommend to use NxNandManager for that aswell as it supports creating NANDs on your SD the same way.

Yep, that was it, the conversion was probably fine (i think?) but due to the resized nand i got this error. In the end the conversion was also the same size and it worked. Yes I have used nxnandmanager but the problem was that it only allows you to create 1 emunand but i have use it to resize multiple nands for my experiments.

Inaki · Apr 18, 2021

DbGt said:
After i realized that the error i was getting with emutools was probably due to the small size of the nand, i continued with your instructions, and i was able to achieve what i wanted to do. But i do not know how stable it will be, i have read posts of emummc getting corrupted when using minitool partition wizard for resizing the sd card, also for some reason 1 of the 2 games I testes did not worked, i got a message of "checking if the software can be played" when i started it in atmosphere and i just got an error message when starting it in sx os. The other game i tried played fine.

I also realized that hekate cannot do emummc backups or restores of resized nands, even when there is only one and it was created with hekate. I get this error message: "00: rawnand.bin... Failed to find a partition...#FFDD00 Failed!"

Also emutools does not work with a single rawnand.bin file, i tried to create emunands from hekate backups with emutools and it wanted the backup to be in multiple files, otherwise i get an error 10 sec after beginning the process saying it cannot find the other files. So this means that resized nands created with nxnandmanager cant be used with emutools.

Other thing i found out is that if I made a resized emunand with hekate of 8gb,when my internal sysnand had only 4.1 gb free, I will have 2.6gb "internal memory" free in my resized emummc. If I made a full sized emunand, then deleted all games so my internal memory that was copied from sysnand goes from 4.1gb to about 23gb (or 25? dont remember) free, then i made a backup of this emunand, then i resized it with nxnandmanager to 8gb, Im the end I will have 5.3gb of "internal memory" with this resized emunand.... so which is correct? and why are they different? both are 8gb in size, and all games and save data should be deleted in both when resizing the nand...... so why the different "internal memory sizes" displayed in the switch?

4 days ago I did not know anything about how atmos or emunand/emummc worked, i have been an sx os user since day 1 almost 3 years ago, and i have always used sys CFW. After reading countless threads, guides and experimenting for 3 full days (and i meant this: from early morning to late night nonstop, so much time "wasted") I just realized this setup I wanted to do is a huge pain in the ass to set up and maintain for one reason or another. I guess i will just leave sx os as sys CFW and create only 1 atmos emummc (probably not even resized) and thats it. If i want to play online i will just use another sd.

EDIT: I just found out that emutools cant convert hidden resized emunand partitions made with nx nandmanager, as its emunand is both compatible with sx and atmos, i tried selecting as source in emutools both sx and atmos hidden partition but i got the same result: a full sized nand conversion even though my resized nand is 8gb big, emutools can even see that the total blocks are 8,323,072 but for some reason it continues to make a conversion like if it was a full size nand and in the end i have a 29.1gb file emunand which i dont even know if it works as its not useful for me.
This problem does not happen with an emummc created with hekate, emutools will say theres an error at some point but the conversion is good.

Yep, that was it, the conversion was probably fine (i think?) but due to the resized nand i got this error. In the end the conversion was also the same size and it worked. Yes I have used nxnandmanager but the problem was that it only allows you to create 1 emunand but i have use it to resize multiple nands for my experiments.

Ok, so I decided to do this on one of my switches. I didn't do it exactly the way I told you, I had a 400GB sd card with an sx os style emunand and full of games, so I made some space by deleting some games and then I powered the switch down and put the microSD on the computer. Then:

- I used Minitool Partition Wizard to shrink the FAT32 data partition by a bit more than 29.22GB on its end, leaving 29.22GB+ of unallocated space in the end of physical space.
- I used Minitool Partition Wizard to select the newly created unallocated space and right click on it and click properties to see the starting sector information of the unallocated space.
- I used EmuTool to save the existing sx os hidden partition emunand to an atmosphere file.
- I used EmuTool to restore the created atmosphere file to an atmosphere style hidden partition but I put the starting sector number that I saw in the second step so that EmuTool restored there. NOTE: When you partition the microSD with hekate, it will create an actual partition entry for the emunand in the partiton table, but this is not needed. I just made space for the emunand and wrote a copy of the sxos emunand to that space. EmuTool will also take care of the emummc.ini file in the emummc folder and make it point to the starting sector you use in the restore operation.
- I added the hekate+atmosphere+sigpatches files to the root of the microSD. I now have the sx gear boot.dat and the sx os 3.1.0 boot.dat in the microSD. When I want to boot sx os I have the sx gear boot.dat renamed to boot.sxg and sx os boot.dat as boot.dat. When I want to boot atmosphere I have the sx os boot.dat renamed to boot.310 and sx gear boot
dat as boot.dat. I noticed that nxshell fails to rename boot.dat when in sx os, but then I remembered tinfoil has CFW update support so I thought that should be able to make boot.dat changes when you use it to update sx os... so I tried to rename boot.dat using tinfoil and it works. This means, you can use tinfooil to do the atmosphere<->sx os boot.dat change and reboot, not as handy as a menu to chainload ( I think this only works with RetroReloaded but not sure... and I don't want to use that, so... ) one or another but still quite convenient.
- I booted in atmosphere mode and did a factory reset. This is so because, since the emunand was a copy of the sx os emunand I started with, which has all the content installed in Emutendo folder, and since the atmosphere emunand has its Nintendo content folder independent from that, in emummc/RAW9/Nintendo, all the referenced content appeared with the cloud icon, as missing.
- I booted in atmosphere mode again and had the notice that the microSD card was used in another console. This is so because the emummc/RAW9/Nintendo folder that was created when booting the emunand but before factory reseting is no longer matching the emunand after factory reset. NOTE: the switch will present a delete button, I don't know if this will only delete/reset/recreate the emummc/RAW9/Nintendo folder or it will instead delete all the FAT32 data partition, but, since I didn't want to risk losing all the microSD contents and structure, I DID NOT press the delete button, I just removed the microSD and the console crashed and atmosphere fatal error screen appeared. I guess I could have long pressed power to power off the switch and that's it. ANYWAY, extract the microSD and delete the Nintendo folder from emummc/RAW9/. After this, when you boot atmosphere again, the OS won't complain about the microSD anymore and you have completelly independent ecosystems between sx os and atmosphere ( and sysnand ).

DbGt · Apr 18, 2021

Inaki said:
Ok, so I decided to do this on one of my switches. I didn't do it exactly the way I told you, I had a 400GB sd card with an sx os style emunand and full of games, so I made some space by deleting some games and then I powered the switch down and put the microSD on the computer. Then:

- I used Minitool Partition Wizard to shrink the FAT32 data partition by a bit more than 29.22GB on its end, leaving 29.22GB+ of unallocated space in the end of physical space.
- I used Minitool Partition Wizard to select the newly created unallocated space and right click on it and click properties to see the starting sector information of the unallocated space.
- I used EmuTool to save the existing sx os hidden partition emunand to an atmosphere file.
- I used EmuTool to restore the created atmosphere file to an atmosphere style hidden partition but I put the starting sector number that I saw in the second step so that EmuTool restored there. NOTE: When you partition the microSD with hekate, it will create an actual partition entry for the emunand in the partiton table, but this is not needed. I just made space for the emunand and wrote a copy of the sxos emunand to that space. EmuTool will also take care of the emummc.ini file in the emummc folder and make it point to the starting sector you use in the restore operation.
- I added the hekate+atmosphere+sigpatches files to the root of the microSD. I now have the sx gear boot.dat and the sx os 3.1.0 boot.dat in the microSD. When I want to boot sx os I have the sx gear boot.dat renamed to boot.sxg and sx os boot.dat as boot.dat. When I want to boot atmosphere I have the sx os boot.dat renamed to boot.310 and sx gear boot
dat as boot.dat. I noticed that nxshell fails to rename boot.dat when in sx os, but then I remembered tinfoil has CFW update support so I thought that should be able to make boot.dat changes when you use it to update sx os... so I tried to rename boot.dat using tinfoil and it works. This means, you can use tinfooil to do the atmosphere<->sx os boot.dat change and reboot, not as handy as a menu to chainload ( I think this only works with RetroReloaded but not sure... and I don't want to use that, so... ) one or another but still quite convenient.
- I booted in atmosphere mode and did a factory reset. This is so because, since the emunand was a copy of the sx os emunand I started with, which has all the content installed in Emutendo folder, and since the atmosphere emunand has its Nintendo content folder independent from that, in emummc/RAW9/Nintendo, all the referenced content appeared with the cloud icon, as missing.
- I booted in atmosphere mode again and had the notice that the microSD card was used in another console. This is so because the emummc/RAW9/Nintendo folder that was created when booting the emunand but before factory reseting is no longer matching the emunand after factory reset. NOTE: the switch will present a delete button, I don't know if this will only delete/reset/recreate the emummc/RAW9/Nintendo folder or it will instead delete all the FAT32 data partition, but, since I didn't want to risk losing all the microSD contents and structure, I DID NOT press the delete button, I just removed the microSD and the console crashed and atmosphere fatal error screen appeared. I guess I could have long pressed power to power off the switch and that's it. ANYWAY, extract the microSD and delete the Nintendo folder from emummc/RAW9/. After this, when you boot atmosphere again, the OS won't complain about the microSD anymore and you have completelly independent ecosystems between sx os and atmosphere ( and sysnand ).

You can boot between the two cfw and emunands with the payload launcher app, this way you can change very easily from within hbmenu. I can go from sx emu to atmos emu and viceversa without any problem, can also go correctly to hekate from sx, (cause when you chainload hekate from sx menu, some things in hekate are broken like usb mass storage, but this does not happen when using the above app)

When you get the message that the microsd was used in another console, it will simply delete the "nintendo" folder contents, not your sd.

I kept experimenting and i think i finally got it after A LOT of frustration, reading, time spent and trial and error, I prefer your previous method than this one because that way it is easier to backup and restore the partition made by hekate with nx nandmanager. I did 2x 6gb emunands (edit: one with hekate, one with minitool partition wizard), i prefer resized nands because its much quicker and easier to back them up and restore them, with this size i have 3440mb of "internal" storage in each emunand just for saves, i think more than enough. before doing all of this I was previously using only 2.4 gb of saves with sysCFW sx os. I will now use sx emunand for xcis for all games requiring fw < 11.0, and atmos emu for newer games.

What i dont completely understand of your new method is that when you shrink your FAT32 partition, what starting sector you write in emutool? the number that appears as "first physical sector" in minitool partition wizard?? and do you write only this? the whole number? its only a numeric number right?

Inaki · Apr 18, 2021

DbGt said:
You can boot between the two cfw and emunands with the payload launcher app, this way you can change very easily from within hbmenu. I can go from sx emu to atmos emu and viceversa without any problem, can also go correctly to hekate from sx, (cause when you chainload hekate from sx menu, some things in hekate are broken like usb mass storage, but this does not happen when using the above app)

When you get the message that the microsd was used in another console, it will simply delete the "nintendo" folder contents, not your sd.

I kept experimenting and i think i finally got it after A LOT of frustration, reading, time spent and trial and error, I prefer your previous method than this one because that way it is easier to backup and restore the partition made by hekate with nx nandmanager. I did 2x 6gb emunands, i prefer resized nands because its much quicker and easier to back them up and restore them, with this size i have 3440mb of "internal" storage in each emunand just for saves, i think more than enough. before doing all of this I was previously using only 2.4 gb of saves with sysCFW sx os. I will now use sx emunand for xcis for all games requiring fw < 11.0, and atmos emu for newer games.

What i dont completely understand of your new method is that when you shrink your FAT32 partition, what starting sector you write in emutool? the number that appears as "first physical sector" in minitool partition wizard?? and do you write only this? the whole number? its only a numeric number right?

Hmmm, that resized emunand thing is tempting me

a couple of GB should suffice... what's the minimum size we can use ?

Also, thank you for the info on that app, will it work on mariko switches ? I will try

About the last part, yes, I click on the unallocated space that's left to the right, the ending physical part, and see its properties and note the starting physical sector, which is a decimal number. Then I convert it to hexadecimal and put it in the sector box in EmuTool in restore to atmosphete partition. This will write to the microSD starting at that sector and will also make changes to emummc.ini; you can open it and see/confirm the same number you put in that box is set.

EDIT: How do you do those shrinked emunands ? ( me has puesto los dientes largos, quiero quiero

)

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum