Toggle sidebar

Homebrew [Re-release] BootCtr - A simple boot manager for 3DS

  • Thread starter Thread starter m45t3r
  • Start date Start date
  • Views Views 78,817
  • Replies Replies 352
  • Likes Likes 33
m45t3r said:
Probably not, unless there is something similar to CakeBrah that I could integrate in BootCtr.

Which homebrews use arm9hax anyway?
Click to expand...

Dunno. I was just thinking that it would be cool to boot into some type of home brew launcher. Obviously I don't know what i'm talking about. =(
 
3xkrazy said:
Dunno. I was just thinking that it would be cool to boot into some type of home brew launcher. Obviously I don't know what i'm talking about. =(
Click to expand...
Yeah, me too. Forget what I said above. Only yesterday I read what the hell is arm9loaderhax.

Someone already did make a version of BootCtr with arm9loaderhax support: https://github.com/hartmannaf/BootCtr9.

The changes are pretty invasive and would mean losing support for .3dsx homebrews (only binary payloads would be supported). However it seems that they're not that difficult to do, so I may upstream some modifications after I do some code clean-up from this fork.

There will be probably two versions of BootCtr, one for menuhax and another one for arm9loaderhax, with distinct funcionality (arm9loaderhax should lose support for .3dsx files like I said above and delay, since delay does not make sense for arm9loaderhax it seems). I want to readded splash screen support for arm9loaderhax version too (BootCtr9 is based in a older version of BootCtr without splash), however without ASCII boot screen because there is no easy way to write text with arm9loaderhax payloads (no ctrulib).

Or, you know, I can just be lazy and let hartmannaf do all the work. I did look at the source code of BootCtr9 and it is slightly messed up at the moment, this is why I want to upstream all the code. Actually, if hatmannaf (don't know the guy) wants, he could just made a PR and make my life easier (I would merge, eventually, after doing some clean-ups).
 
Last edited by m45t3r,
  • Like
Reactions: 3xkrazy and Februarysn0w
m45t3r said:
Yeah, me too. Forget what I said above. Only yesterday I read what the hell is arm9loaderhax.

Someone already did make a version of BootCtr with arm9loaderhax support: https://github.com/hartmannaf/BootCtr9.

The changes are pretty invasive and would mean losing support for .3dsx homebrews (only binary payloads would be supported). However it seems that they're not that difficult to do, so I may upstream some modifications after I do some code clean-up from this fork.

There will be probably two versions of BootCtr, one for menuhax and another one for arm9loaderhax, with distinct funcionality (arm9loaderhax should lose support for .3dsx files like I said above and delay, since delay does not make sense for arm9loaderhax it seems). I want to readded splash screen support for arm9loaderhax version too (BootCtr9 is based in a older version of BootCtr without splash), however without ASCII boot screen because there is no easy way to write text with arm9loaderhax payloads (no ctrulib).

Or, you know, I can just be lazy and let hartmannaf do all the work. I did look at the source code of BootCtr9 and it is slightly messed up at the moment, this is why I want to upstream all the code. Actually, if hatmannaf (don't know the guy) wants, he could just made a PR and make my life easier (I would merge, eventually, after doing some clean-ups).
Click to expand...

Looking forward to your release, should you decide to continue your work. :)
 
m45t3r said:
Yeah, me too. Forget what I said above. Only yesterday I read what the hell is arm9loaderhax.

Someone already did make a version of BootCtr with arm9loaderhax support: https://github.com/hartmannaf/BootCtr9.

The changes are pretty invasive and would mean losing support for .3dsx homebrews (only binary payloads would be supported). However it seems that they're not that difficult to do, so I may upstream some modifications after I do some code clean-up from this fork.

There will be probably two versions of BootCtr, one for menuhax and another one for arm9loaderhax, with distinct funcionality (arm9loaderhax should lose support for .3dsx files like I said above and delay, since delay does not make sense for arm9loaderhax it seems). I want to readded splash screen support for arm9loaderhax version too (BootCtr9 is based in a older version of BootCtr without splash), however without ASCII boot screen because there is no easy way to write text with arm9loaderhax payloads (no ctrulib).

Or, you know, I can just be lazy and let hartmannaf do all the work. I did look at the source code of BootCtr9 and it is slightly messed up at the moment, this is why I want to upstream all the code. Actually, if hatmannaf (don't know the guy) wants, he could just made a PR and make my life easier (I would merge, eventually, after doing some clean-ups).
Click to expand...
@RednaxelaNnamtra
 
m45t3r said:
Yeah, me too. Forget what I said above. Only yesterday I read what the hell is arm9loaderhax.

Someone already did make a version of BootCtr with arm9loaderhax support: https://github.com/hartmannaf/BootCtr9.

The changes are pretty invasive and would mean losing support for .3dsx homebrews (only binary payloads would be supported). However it seems that they're not that difficult to do, so I may upstream some modifications after I do some code clean-up from this fork.

There will be probably two versions of BootCtr, one for menuhax and another one for arm9loaderhax, with distinct funcionality (arm9loaderhax should lose support for .3dsx files like I said above and delay, since delay does not make sense for arm9loaderhax it seems). I want to readded splash screen support for arm9loaderhax version too (BootCtr9 is based in a older version of BootCtr without splash), however without ASCII boot screen because there is no easy way to write text with arm9loaderhax payloads (no ctrulib).

Or, you know, I can just be lazy and let hartmannaf do all the work. I did look at the source code of BootCtr9 and it is slightly messed up at the moment, this is why I want to upstream all the code. Actually, if hatmannaf (don't know the guy) wants, he could just made a PR and make my life easier (I would merge, eventually, after doing some clean-ups).
Click to expand...

Yeah, haven't had time to clean up the source code,but I will do it next week. And after I cleaned up the source code and included screen init fully, I will re add the splashscreen(I had to remove every graphical output, to let it work without screen init, so its not based on an old version). Also some functions did not work as expected, so Í added alternativ version of them, but I haven't rechecked if they work now again, after I modified the start.s and stub.ld for the arm9 payload.
I also I removed everything for 3dsx loading(since we need the homemenu and all services to run for them).
 
  • Like
Reactions: Michierusama and Rohul1997
RednaxelaNnamtra said:
Yeah, haven't had time to clean up the source code,but I will do it next week. And after I cleaned up the source code and included screen init fully, I will re add the splashscreen(I had to remove every graphical output, to let it work without screen init, so its not based on an old version). Also some functions did not work as expected, so Í added alternativ version of them, but I haven't rechecked if they work now again, after I modified the start.s and stub.ld for the arm9 payload.
I also I removed everything for 3dsx loading(since we need the homemenu and all services to run for them).
Click to expand...
If you can upstream the code (as a PR), I would be thankfull. Of course, only the code related to BootCtr itself (so not the part of the integrated arm9haxloader with BootCtr).

After merging, I could fix some problems with failsafe checks (some of them are not really necessary, I even changed this in the last commit from BootCtr).
 
RednaxelaNnamtra said:
Yeah, haven't had time to clean up the source code,but I will do it next week. And after I cleaned up the source code and included screen init fully, I will re add the splashscreen(I had to remove every graphical output, to let it work without screen init, so its not based on an old version). Also some functions did not work as expected, so Í added alternativ version of them, but I haven't rechecked if they work now again, after I modified the start.s and stub.ld for the arm9 payload.
I also I removed everything for 3dsx loading(since we need the homemenu and all services to run for them).
Click to expand...
can you add support for the new 3ds buttons and add an option to disable the info on the bottom screen? i tried splash = 1 like in the normal bootctr but it seems to be ignored. other than those 2 things it is great thank you
 
Last edited by pbanj,
pbanj said:
can you add support for the new 3ds buttons and add an option to disable the info on the bottom screen? i tried splash = 1 like in the normal bootctr but it seems to be ignored. other than those 2 things it is great thank you
Click to expand...
I dont know how to check them, but I could try to find it out, maybe its documented somewhere on 3dbrew.
 
  • Like
Reactions: pbanj
  • Like
Reactions: Rohul1997 and pbanj
RednaxelaNnamtra said:
This will only help if zl and zr are using the same physical address as the other buttons, but I will check it out, when I have time, but the priority is low, if its harder to implement.
Click to expand...
If all you add is zl and zr I would be happy but there is no rush
 
@RednaxelaNnamtra, I think payload option is useless: it is used in BootCtr to force HBL/payload modes, however since BootCtr9 only supports binary payloads this is useless.

The default offset in BootCtr9 should be 0. I set 0x12000 since the use-case for BootCtr9 is as a menuhax bootloader. However BootCtr9 uses another type of payloads, and they generally is separate anyway that don't include Spider payload (like AuReiNand), so the default delay should be set to 0.

Does delay make sense?

Edit: and you probably need to sync writes in log file. If the application don't boot sucessfully, the lofgile is empty, which isn't really helpful.
 
Last edited by m45t3r,
m45t3r said:
@RednaxelaNnamtra, I think payload option is useless: it is used in BootCtr to force HBL/payload modes, however since BootCtr9 only supports binary payloads this is useless.

The default offset in BootCtr9 should be 0. I set 0x12000 since the use-case for BootCtr9 is as a menuhax bootloader. However BootCtr9 uses another type of payloads, and they generally is separate anyway that don't include Spider payload (like AuReiNand), so the default delay should be set to 0.

Does delay make sense?
Click to expand...
I simply left it in in the beginnig, because I didn't know how it work, but you are rigth, one more thing I will do in the next release.

I don't know about the offset, atm every payload is seperated for arm9loaderhax, but for example aureinands Reinand.dat is working with arm9loaderhax(using a bootmamanger with offset support), and the others will in future too, maybe I will check the filetype for the default value(.dat=0x12000, .bin = 0x0). But I thougt it would be easier for people to change over from menuhax to a9lh, if they need to modify as less as possible. That's why I changed back from 0 to 0x12000.

Also what do you think, how should I handle configuration for the application, like logging to screen and logging to a file, should I use the GLOBAL section, or another section for these settings, and maybe also have a separate parsing handler for it?

Edit:
I'm using the delay to set the time to show the splash screen, and to set the time it will wait for the key, but I will try to add something like pressing a button at start, then showing the splashscreen, and wait the timeset by the config. If another button is pressed, it would reset the timer and load the other splash.
This way it would make it easier, if you don't have a key in mind for an payload you only use in certain cases.
 
Last edited by RednaxelaNnamtra,
RednaxelaNnamtra said:
I simply left it in in the beginnig, because I didn't know how it work, but you are rigth, one more thing I will do in the next release.

I don't know about the offset, atm every payload is seperated for arm9loaderhax, but for example aureinands Reinand.dat is working with arm9loaderhax(using a bootmamanger with offset support), and the others will in future too, maybe I will check the filetype for the default value(.dat=0x12000, .bin = 0x0). But I thougt it would be easier for people to change over from menuhax to a9lh, if they need to modify as less as possible. That's why I changed back from 0 to 0x12000.

Also what do you think, how should I handle configuration for the application, like logging to screen and logging to a file, should I use the GLOBAL section, or another section for these settings, and maybe also have a separate parsing handler for it?
Click to expand...

Well, sure. Maybe it is better to wait rx{Tools, CFW, whatever} and CakesFW to set their payload values. If all of them create a separate arm9loaderhax.bin like AuReiNand, with offset set to 0, I think this would be a better default, otherwise 0x12000 is still ok to use.

Hum... This is probably would be better made in another section, like [DEBUG]. This would be the first section to be loaded, before anything.
 
  • Like
Reactions: RednaxelaNnamtra
m45t3r said:
Well, sure. Maybe it is better to wait rx{Tools, CFW, whatever} and CakesFW to set their payload values. If all of them create a separate arm9loaderhax.bin like AuReiNand, with offset set to 0, I think this would be a better default, otherwise 0x12000 is still ok to use.

Hum... This is probably would be better made in another section, like [DEBUG]. This would be the first section to be loaded, before anything.
Click to expand...
I'm using cakes with a9l and its bin works with the 0 offset
 

Site & Scene News

Go to forum More news

Popular threads in this forum

Why did the price of 3ds shoot up ?

Hacking Homebrew Project  BlazerTube - a YouTube 3DS revival using the REAL app!

Problems getting Homebrew to appear outside of the Homebrew Launcher (homebrew won't appear on the HOME menu)

Homebrew app Emulator  [Release] 3DS-CLI - Run a real RISC-V Linux environment on the Nintendo 3DS

Website for finding alternative games for 3DS

Hardware  2 Broken 3DSes, need help

Gaming  any good rpgs on 3ds?

Hacking  Modding Reassurance