this depends on the custom firmware you're using, often by replacing "Ver." in System Settings. rxTools does "RX-E", ReiNand does "Rei", Gateway does "GW3D".How can I see if I'm on emuNand or sysNand?
@madridi4ever & @kiwiis we're currently trying to find out what's going wrong there with CakeHax + EmuNAND9 / Decrypt9. Maybe you can try if the simple sample application attached to this post works for you? This has the same entrypoints as Decrypt9 and EmuNAND9.And done.
You also need to copy the contents of your SD card filesystem over. Other than that, you'll be good to go.Quick question. I want to swap out my current 4gb sd card and replace it with something bigger. How can I copy my emunand over to the new one? Is it as simple as backing up the emunand to bin then inserting the new sd card creating a emunand partition and cloning from the emunand.bin?
Just tested it on my n3ds via MSET and it seems to work fine as is. As does Emunand9UI and Decrypt9UI once i change the #define BOT_SCREEN0 in both to what is in HelloEntryPoint. Otherwise (before the change) I'm greeted with black screens and no way to reboot other than forced power off.@madridi4ever & @kiwiis we're currently trying to find out what's going wrong there with CakeHax + EmuNAND9 / Decrypt9. Maybe you can try if the simple sample application attached to this post works for you? This has the same entrypoints as Decrypt9 and EmuNAND9.
Okay, thanks a ton! Duh, that will mean some extensive modifications to the Makefile now. And maybe, BootCTR will need some changes, too.Just tested it on my n3ds via MSET and it seems to work fine as is. As does Emunand9UI and Decrypt9UI once i change the #define BOT_SCREEN0 in both to what is in HelloEntryPoint. Otherwise (before the change) I'm greeted with black screens and no way to reboot other than forced power off.
Nah we should just have one version of each imo.... 3dsx only haha Would save a lot of headaches / head scratching when it doesn't work etc etc...Okay, thanks a ton! Duh, that will mean some extensive modifications to the Makefile now. And maybe, BootCTR will need some changes, too.
Well, some entrypoints are still useful for the small remainder of users who don't have SysNAND HBL access or have other reasons not to use HBL. The GW 4.x Launcher.dat should be very obsolote by now though. And you're correct, maintaining all these entrypoints is a huge pain in the ass.Nah we should just have one version of each imo.... 3dsx only haha Would save a lot of headaches / head scratching when it doesn't work etc etc...
Just tested it on my n3ds via MSET and it seems to work fine as is. As does Emunand9UI and Decrypt9UI once i change the #define BOT_SCREEN0 in both to what is in HelloEntryPoint. Otherwise (before the change) I'm greeted with black screens and no way to reboot other than forced power off.
True. Probably a very small minority who use other entry points / don't have sysnand HBL (for whatever strange reason). I only find myself using the 3dsx versions these days to be honest.Well, some entrypoints are still useful for the small remainder of users who don't have SysNAND HBL access or have other reasons not to use HBL. The GW 4.x Launcher.dat should be very obsolote by now though. And you're correct, maintaining all these entrypoints is a huge pain in the ass.
Works great! So does the Decrypt9. I am happy you were able to solve this issueAlright, new release. New in this:
* Allow specifiying the file name when dumping / restoring the SysNAND / EmuNAND
* Updated starter.bin
* CakeHax entrypoint fixed (experimental, may break the GW 4.x browser entrypoint)
Testing the CakeHax entrypoint and the GW 4.x Launcher.dat entrypoint is highly appreciated. If you can, please test this entrypoints and let me know if it works for you. Also, @kiwiis and @madridi4ever might want to give this a try.
Noooo don't give him any ideas lolNah we should just have one version of each imo.... 3dsx only haha Would save a lot of headaches / head scratching when it doesn't work etc etc...
Totally giving him ideas. The amount of entry points to cover is no doubt annoying for him and to be honest no one has an excuse to not have access to homebrew menu atm with the amount of *hax to choose from. Prove me wrong.Works great! So does the Decrypt9. I am happy you were able to solve this issue
Noooo don't give him any ideas lol
Waiting for your UI update versions
Lol I disagree! True, HBL is probably the best thing out there, the main entry point in my opinion remains the browser vuln for those on 9.2Totally giving him ideas. The amount of entry points to cover is no doubt annoying for him and to be honest no one has an excuse to not have access to homebrew menu atm with the amount of *hax to choose from. Prove me wrong.
And I'll look at updating the UI versions shortly.
Well, considering the MSET .dat file can be used with the browser without any fiddling, taking the gateway version out would just take out redundancy, since cakehax payloads are able to be run from HBL, browser and MSET so taking the GW launcher.dat out is the way to go IMOLol I disagree! True, HBL is probably the best thing out there, the main entry point in my opinion remains the browser vuln for those on 9.2
Getting to HBL is tedious with browserhax. At the very least, it does not have a 100% boot rate.
As for homemenuhax, I understand that it's the hottest thing on the scene right now and I agree with how valuable it is. However, those with linked NAND (like myself.. For multiple reasons) cannot benefit from it. We cannot launch cfw. (Unless v2 fixed that somehow). So basically, homemenuhax is out of the question for me, in which case, the browser vuln is the best out there for those who can't use homemenuhax.
So yeah I'm happy with the browser entry point please don't ruin it for me lol
Alright, but what if you are on O3DS v4.x? Does CakeHax work with that as well and is it as reliable?Well, considering the MSET .dat file can be used with the browser without any fiddling, taking the gateway version out would just take out redundancy, since cakehax payloads are able to be run from HBL, browser and MSET so taking the GW launcher.dat out is the way to go IMO
Not for those who have gateway? like me..Well, considering the MSET .dat file can be used with the browser without any fiddling, taking the gateway version out would just take out redundancy, since cakehax payloads are able to be run from HBL, browser and MSET so taking the GW launcher.dat out is the way to go IMO
If you're of 4.x you'd use MSET wouldn't you? I don't know much about that as I never was on 4.xAlright, but what if you are on O3DS v4.x? Does CakeHax work with that as well and is it as reliable?
Was the bottom framebuffer offset for GW always 0x080FFFD0? Asking because 0x080FFFD4 was used in the past for the GW 4.x browser entrypoint. I never used that entrypoint, but afaik that entrypoint worked for a lot of users, even if there was something wrong with the offset. I don't want to make my Makefile more complicated than it already is, so I'd very much prefer just changing the offset and to be done with it (only if it doesn#t break anything, though).
Yup, that's what I thought. I guess I can bring true GW compatibility back then, if I choose the bottom framebuffer depending on that value, same as I'm doing with the top framebuffer now. Maybe also just ditch that old thing. No one is using that anyways and I don't like having untested stuff in there.
Keep in mind every screen has two buffers, so in total we have 6 framebuffers. 0xD4 was the __second__ bottom framebuffer, and should be used depending on 0x080FFFDC, If I'm right (For some reason the GW launcher just always seemed to set the second bottom FB). [USER=311583]@Normmatt knows this better than myself, so tagging for confirmation.[/USER]