Hacking [Release] rxTools - Roxas75 3DS Toolkit [fw 2.0 - 9.2]

[mlinares]

@urherenow
Thanks for your report, now the N3DS firmware filename is fixed in GDocs manual.

 

[m45t3r]

Yeah, it was downgraded with gateway. I believe it was actually on 6.X, and I noticed rxTools had some 6.X options. If I restored to 6.X, would I be able to just use 6.X as is? And I suppose I could downgrade mset to 4.X if necessary.

You don't need to downgrade mset in 6.x, actually it is better to have your mset in 6.x (since you can, for example, set mset using browser instead only with a DS flashcard).

The best route would probably to restore your backup, and just use mset exploit for 6.x

 

[honyo29]

hello.

i just updated rx to cbec77e build. i couldn't find devmode on rx menu advanced tab, is pasta mode a new name for devmode? or is it something different? i kinda want to update my sysnand (currently o3ds with 4.4 fw) to be able to use themehax. is this pasta mode safe to use with sysupdater? or should i use older build that has devmode? (my previous rx was still using single firmware.bin in rxtools/sys/ but has devmode, i just updated because i'm interested in themehax)

also i have cubic ninja installed as .cia to run hbl, only use it for screenshot (i prefer hans home button than using ntr button combination to take screenshots). i take it since rxtools coldboot with themehax involving replacing hbl's boot.3dsx with rxtools' boot.3dsx, i wont be able to boot into hbl on emunand anymore (or sysnand if i'm still using the same sdcard) not really a problem since there's ntr but if there's solution to this i'd be more convinced to upgrade and join the coldboot rx.

thank you and i hope i didn't ask boring questions.

 

[urherenow]

So... I just updated my N3DS to the latest build (built myself). I initially had trouble with a bottom black screen using CN and Ninjhax 1.1b, so I then used browserhax and ctrbootmanager to load it. It immediately booted into emunand. Since then, I've updated everything. Ninjhax 2.5, homemenu_rop.bin, menuhax 2.0... it loads every way I try now. Haven't tried pasta mode yet and it's way past time for me to sleep, but sys/emunand both work and so does region-free (but BootNTR with language plugin still required for DLC in other languages).

Without testing the extra features, I'd say this latest build is pretty stable. I'll find out tomorrow if not having the decrypted firmware created in the /data folder will give me the black screen error again when launching from Ninjhax.

EDIT: @honyo yes, pasta mode is devmode, and it should be ok to use sysupdater with it. You can launch rxtools with HBL and launch HBL through Themehax. You can also launch ctrbootmanager, I think. ctrbootmanager can be configured to autoboot rxtools, I think, and you should be able to launch it through ninjhax 2.5 on emunand, only there you would hold the recue button ("select" is the default) to stop the auto boot and choose HBL (rename the HBL to boot_hb.3dsx)

 

[goncalodoom]

The newest builds dont seem to let me boot GBA vc titles, i get black screen with an error to turn off my system, maybe the AGB_FIRM isn't patched with these releases

 

[noctis90210]

does the cbec77e bulild works on n3ds? emu/sys/and psta mode?
how bout boot rate?

thanks...

 

[Ziefer846]

hello.

i just updated rx to cbec77e build. i couldn't find devmode on rx menu advanced tab, is pasta mode a new name for devmode? or is it something different? i kinda want to update my sysnand (currently o3ds with 4.4 fw) to be able to use themehax. is this pasta mode safe to use with sysupdater? or should i use older build that has devmode? (my previous rx was still using single firmware.bin in rxtools/sys/ but has devmode, i just updated because i'm interested in themehax)

also i have cubic ninja installed as .cia to run hbl, only use it for screenshot (i prefer hans home button than using ntr button combination to take screenshots). i take it since rxtools coldboot with themehax involving replacing hbl's boot.3dsx with rxtools' boot.3dsx, i wont be able to boot into hbl on emunand anymore (or sysnand if i'm still using the same sdcard) not really a problem since there's ntr but if there's solution to this i'd be more convinced to upgrade and join the coldboot rx.

thank you and i hope i didn't ask boring questions.

Just use rxTools 2.6 or the 10-2 nightly for devmode. I wouldn't risk running sysupdater on pasta mode or whatever that is.

 

[tivu100]

Just use rxTools 2.6 or the 10-2 nightly for devmode. I wouldn't risk running sysupdater on pasta mode or whatever that is.

2.6 doesn't support devmode!. Use alpha, 2.5.2, nightly build.

For Pasta: use mini Pasta only because it's equivalent to Devmode. Other Pasta CFW may be a full version which supports & enables firm-launch.

Mini Pasta is in this post https://gbatemp.net/threads/need-hax-2-x-pasta-loader.400752/#post-5756850

 

[Ziefer846]

2.6 doesn't support devmode!. Use alpha, 2.5.2, nightly build.

Right, that's what I meant. Thanks.

 

[ccfman2004]

The newest builds dont seem to let me boot GBA vc titles, i get black screen with an error to turn off my system, maybe the AGB_FIRM isn't patched with these releases

Are you using an O3DS or N3DS? AGB patching doesn't work on the N3DS yet.

 

[Drak0rex]

Are you using an O3DS or N3DS? AGB patching doesn't work on the N3DS yet.

Is there any way to patch it manually or some other work around? This shouldn't effect the GBA emulators, right?

 

[Yoshimashin]

Sorry if this has been asked before but did that screenshot function ever get implemented?

 

[honyo29]

So... I just updated my N3DS to the latest build (built myself). I initially had trouble with a bottom black screen using CN and Ninjhax 1.1b, so I then used browserhax and ctrbootmanager to load it. It immediately booted into emunand. Since then, I've updated everything. Ninjhax 2.5, homemenu_rop.bin, menuhax 2.0... it loads every way I try now. Haven't tried pasta mode yet and it's way past time for me to sleep, but sys/emunand both work and so does region-free (but BootNTR with language plugin still required for DLC in other languages).

Without testing the extra features, I'd say this latest build is pretty stable. I'll find out tomorrow if not having the decrypted firmware created in the /data folder will give me the black screen error again when launching from Ninjhax.

EDIT: @honyo yes, pasta mode is devmode, and it should be ok to use sysupdater with it. You can launch rxtools with HBL and launch HBL through Themehax. You can also launch ctrbootmanager, I think. ctrbootmanager can be configured to autoboot rxtools, I think, and you should be able to launch it through ninjhax 2.5 on emunand, only there you would hold the recue button ("select" is the default) to stop the auto boot and choose HBL (rename the HBL to boot_hb.3dsx)

thanks a lot. especially for ctrbootmanager. for sysupdater, i figured i'd use mini pasta. you'll never know if it's broken in disabling firmlaunch, better be safe than sorry.

2.6 doesn't support devmode!. Use alpha, 2.5.2, nightly build.

For Pasta: use mini Pasta only because it's equivalent to Devmode. Other Pasta CFW may be a full version which supports & enables firm-launch.

Mini Pasta is in this post https://gbatemp.net/threads/need-hax-2-x-pasta-loader.400752/#post-5756850

thanks for mini pasta.

Sorry if this has been asked before but did that screenshot function ever get implemented?

because you can use ntr or hans for this, i think it's on the lowest priority to add.

 

[Aroth]

Ugh

Tried making sense of this thread and the documentation to figure wtf I am supposed to do, but I am about ready to give up.

Comments made in the last five pages of the thread all contradict both the documentation AND each other.

Like, what firmware.bin file I am supposed to be using? I have seen that I should be using a specific file with a specific name from reinand's pastebin. Elsewhere it says that I should rename a file to match the name I need. I see no less than THREE places said file should be put, as well as two or more places for other files.

Everybody and their mother says that rxTools is stable and easy to set up and the only thing you should use, and half of the prelim work needed to make my own dumps work on any system/cfw requires tools that seem to only be available here. But this is FAR from stable imo. If nothing else things need to be properly documented.

Rather than just pushing new nightly builds every day and calling them "beta", you guys should be flagging specific builds that are particularly stable as "Beta" and treat nightly builds as what they really are, which is Alpha builds.

 

[Darktalon]

does the cbec77e bulild works on n3ds? emu/sys/and psta mode?
how bout boot rate?

thanks...

I'm using it on my New 3DS AUS 9.0. Using Menuhax 2.0, and CTR Boot Manager, I can autoboot 90% of the time. Sits a little while at black screen but it will work. BUT if i try to use the rxTools menu, it does not display the bottom screen, but still works if you remember exactly what to press for what you want to do.

 

[WhoAmI?]

Ugh

Tried making sense of this thread and the documentation to figure wtf I am supposed to do, but I am about ready to give up.

Comments made in the last five pages of the thread all contradict both the documentation AND each other.

Like, what firmware.bin file I am supposed to be using? I have seen that I should be using a specific file with a specific name from reinand's pastebin. Elsewhere it says that I should rename a file to match the name I need. I see no less than THREE places said file should be put, as well as two or more places for other files.

Everybody and their mother says that rxTools is stable and easy to set up and the only thing you should use, and half of the prelim work needed to make my own dumps work on any system/cfw requires tools that seem to only be available here. But this is FAR from stable imo. If nothing else things need to be properly documented.

Rather than just pushing new nightly builds every day and calling them "beta", you guys should be flagging specific builds that are particularly stable as "Beta" and treat nightly builds as what they really are, which is Alpha builds.

There is a link on the nightlies page. Go to instructions and click the link which directs to a tutorial that is on GBATemp. That tutorial gives everything you need to know and it even link's to the most "stable" nightly build. The build that it links to, is the one I recommend. I'd give you more info but I'm on mobile.

Documents are also being worked on, to help you with the setup process.

Hopefully we'll be able to straighten things out in the future

Edit: https://www.dropbox.com/sh/blmecish...v4F5a/rxTools_10-02-15_19-07.9f48bb8.zip?dl=0

 

[Ziefer846]

Ugh

Tried making sense of this thread and the documentation to figure wtf I am supposed to do, but I am about ready to give up.

Comments made in the last five pages of the thread all contradict both the documentation AND each other.

Like, what firmware.bin file I am supposed to be using? I have seen that I should be using a specific file with a specific name from reinand's pastebin. Elsewhere it says that I should rename a file to match the name I need. I see no less than THREE places said file should be put, as well as two or more places for other files.

Everybody and their mother says that rxTools is stable and easy to set up and the only thing you should use, and half of the prelim work needed to make my own dumps work on any system/cfw requires tools that seem to only be available here. But this is FAR from stable imo. If nothing else things need to be properly documented.

Rather than just pushing new nightly builds every day and calling them "beta", you guys should be flagging specific builds that are particularly stable as "Beta" and treat nightly builds as what they really are, which is Alpha builds.

Personally, I think rxTools 2.6 is the way to go as it is the last stable release. If you really want to use one of the nightlies, go with the 10-2-15 one. In each of the "release" folders, there is a guide telling you where to place your files. Just follow that and you should be good to go.

--------------------- MERGED ---------------------------

Like, what firmware.bin file I am supposed to be using? I have seen that I should be using a specific file with a specific name from reinand's pastebin. Elsewhere it says that I should rename a file to match the name I need. I see no less than THREE places said file should be put, as well as two or more places for other files.

Also, always create a new firmware.bin file every time you update rxTools. The python file can be found in "tools" folder.

 

[Aroth]

There is a link on the nightlies page. Go to instructions and click the link which directs to a tutorial that is on GBATemp. That tutorial gives everything you need to know and it even link's to the most "stable" nightly build. The build that it links to, is the one I recommend. I'd give you more info but I'm on mobile.

Documents are also being worked on, to help you with the setup process.

Hopefully we'll be able to straighten things out in the future

A quick look suggestions it will be able to help me, so thanks.

A large part of the issue I take is with the general attitude I am seeing from the contributors, especially in the comments on the git bug notices and pull requests. I used to work with an android dev team back with the Droid2Global and its locked bootloader (screw you Motorola >_< ) and as irritated as I got with the state of the git and release channels for our stuff, it was miles ahead of what I see here.

First and foremost, nightly builds should be treated as experimental (borderline alpha) builds, and there should be a separate track for beta releases where you move builds that have high levels of stability (like the 10-2 build?). Markers should be set for stages of development. Stuff like "focus on stable N3DS support" and then work only towards that, rather than trying to make new features work and stabilize n3ds support at the same time.. Also, there is no reason to wait for N3DS to have identical support to the O3DS to consider it stable. It is a new platform, work on getting it stable, then work on adding things like TWL and AGB patches.

>_> ok rant over lol.

Personally, I think rxTools 2.6 is the way to go as it is the last stable release. If you really want to use one of the nightlies, go with the 10-2-15 one. In each of the "release" folders, there is a guide telling you where to place your files. Just follow that and you should be good to go.

Also, always create a new firmware.bin file every time you update rxTools. The python file can be found in "tools" folder.

2.6 is not a viable option for me, and unless I missed something neither is using the python script, because I have a N3DS.


edit:

Don't think I can use your build since I have a N3DS, from what I was able to make out N3DS support for the menu was already borked by then.

 

[WhoAmI?]

A quick look suggestions it will be able to help me, so thanks.

A large part of the issue I take is with the general attitude I am seeing from the contributors, especially in the comments on the git bug notices and pull requests. I used to work with an android dev team back with the Droid2Global and its locked bootloader (screw you Motorola >_< ) and as irritated as I got with the state of the git and release channels for our stuff, it was miles ahead of what I see here.

First and foremost, nightly builds should be treated as experimental (borderline alpha) builds, and there should be a separate track for beta releases where you move builds that have high levels of stability (like the 10-2 build?). Markers should be set for stages of development. Stuff like "focus on stable N3DS support" and then work only towards that, rather than trying to make new features work and stabilize n3ds support at the same time.. Also, there is no reason to wait for N3DS to have identical support to the O3DS to consider it stable. It is a new platform, work on getting it stable, then work on adding things like TWL and AGB patches.

>_> ok rant over lol.



2.6 is not a viable option for me, and unless I missed something neither is using the python script, because I have a N3DS.

I like your thinking. Although the way the devs handle things on Github, can't be changed, I'll try to do some "cleanup" on what I can. The sectioning for BETA releases, is a good idea. I'll probably add categories to the site, when I get my finger out my ass

(I only work on things such as the web design, robot and file bug reports tho I am a member of the PASTA Team, now)

As for markers, again I guess I could add a section to the website which states the current development progress. If you have any other suggestions, please share

 

[Aroth]

I like your thinking. Although the way the devs handle things on Github, can't be changed, I'll try to do some "cleanup" on what I can. The sectioning for BETA releases, is a good idea. I'll probably add categories to the site, when I get my finger out my ass

(I only work on things such as the web design, robot and file bug reports tho I am a member of the PASTA Team, now)

As for markers, again I guess I could add a section to the website which states the current development progress. If you have any other suggestions, please share

Well for starters the team needs to decide what is the most important feature atm.

I understand part of the problem with things breaking randomly stems from the nearly nightly nature of smealum's and yellow8's updates to the *hax entry points, so I would strongly suggest that for stability reasons beta builds should focus on booting from an entry point that is not outside of your control, like MSET. Anyone able to use rxTools will be able to use MSET and it won't change randomly on you like *hax will, so it should be the "standard" boot method. Users would be welcome to use other entrypoints if they want, as long as they understand that due to the constantly evolving nature of *hax (and the fact that it is outside of the development team's control) the team cannot ensure full stability when using those methods.

After that I personally think stabilizing N3DS support while maintaining stability with existing features on the O3DS should be priority. From what I understand at one point you had everything working on the N3DS except TWL/AGB patches, DevMode, RegionFree and something about the initial configuration. If I were heading the project, I would focus on getting back to that and push it as a 3.0 Beta-1.

In all fairness, once you get the initial configuration working properly (I assume that refers to some setup options that N3DS users don't get to customize atm?) and everything works with MSET, I would personally release that as 3.0 Stable. DevMode would be nice to have in 3.0, but nothing says it can't wait till 3.1, same for TWL/AGB patches for the N3DS. Like I said, the N3DS IS a different system and there is no reason not to treat it as such and make beta/stable releases with differing levels of feature support.