Just a fix for N3DS users, reported by @Aurora Wright. It seems that binary payloads was not working with N3DS.
If you're getting white screens, this is not a fault of BootCtr. White screens is signal of failure from homemenuhax.
Just a fix for N3DS users, reported by @Aurora Wright. It seems that binary payloads was not working with N3DS.
If you're getting white screens, this is not a fault of BootCtr. White screens is signal of failure from homemenuhax.
so is there a way to reduce the risk of having white screen?
and another one, if white screen are homemenuhax failure... it means even i test using ctrbootmanager, i will also experience white screens... am i right?
I don't know. And yeah, does not matter if you're using CtrBootManager or BootCtr in this case.
i just thaught before that other boot manager might fix the white screen, but now that i know that homemenuhax is the suspect...
im going to stick on your bootctr, its more user friendly...
Unless you're getting a white screen after the debug text screen from homemenuhax (this is when boot.3dsx file is loaded), this white screen is from homemenuhax. However, I find really strange for you to get a white screen from BootCtr anyway, since there is no code that should generate this kind of screen (you can get a black or red screen from BootCtr in case of failure, just FYI).
why does mine keep saying missing boot_default? I want to set it up to have a higher boot rate for rxtools
--------------------- MERGED ---------------------------
Now I get a flashing red screen any idea what it means?
--------------------- MERGED ---------------------------
Now I get a flashing red screen any idea what it means?
Strange, this means that something went wrong with BootCtr. just to check, set-up a boot_config.ini file according to below:
Code:
[DEFAULT]
path = /rxTools/sys/code.binAnyway, time to break things for fun.
An experimental build for those feeling adventurous (in attachment). This is commit d564b21, btw, for those who like to compile.
What did it changed? I removed all code related to metadata scanning from Homebrew Launcher. This should be similar to release v0.2 (when this homebrew was still called HBL-emergency). I did added all of those code back after someone reported that something wasn't working (I think it was network support?), however after sometime it was confirmed that it wasn't really a problem. Never reverted the code afterwards since I think this metadata code does something, I was simple not sure what exactly it does.
Does it mean I know what it does now? No, this is why this is a experimental buid. However, I never had any problems, and I don't remember anyone reporting problems back in the days of v0.2 too. Nowadays it seems that BootCtr is much more used than before, though, so I think this is a good time to just release a experimental build, see if it breaks anything, and if so I can just revert some commits and call it a day.
If you want to help, I ask you to just test any homebrews (.3dsx files, NOT binary payloads, since they're not affect by this change) directing booting them from BootCtr. It may be your favorite CFW, FTPBrony, Homebrew Launcher, etc. If anything does not work that used to work before (like connecting to network in FTPBrony), just report.
Btw, with these changes BootCtr looks very fast, at least for me. Or maybe this is thanks to me changing from rxTools to CakesFW.
Last edited by m45t3r,
I just wanted to drop by and leave some thanks to you, OP. I've been using this ever since I got my n3ds some days ago and it's got that highly configurable simplicity I tend to favor. It just works! So, thank you a lot @m45t3r.
Also, fun(?) coincidence: When I was set to change my avatar to the current one I was considering this one and another framed exactly like yours, both freshly screencaped. And that's to say nothing of our shared homeland haha.
Also, fun(?) coincidence: When I was set to change my avatar to the current one I was considering this one and another framed exactly like yours, both freshly screencaped. And that's to say nothing of our shared homeland haha.
Well, I was amazed by the world of Haruhi Suzumiya when I created this account. It is still one of my favorite light novels ever, even if it isn't my favorite anime series nowadays. Btw, Kyon is still one of my favorite male characters. I miss his unique characteristics nowadays, when every male character seems to be bland and generic.
@d0k3, I don't know if you're still interested, however I discovered a way to make FTBrony to have a valid IP address almost everytime. Just set delay to 300 (or 5 seconds). I updated the documentation to make this clear.
Code:
;Comments starts with ";" or "#", so you need to remove it first to the
;line actually do something.
;[DEFAULT] is the option that is used if you don't press anything.
;This section is actually special, since what is defined in here will be
;the default for any other section (except for "payload" option, that is
;only valid per section).
;The options below are the defaults used internally in the application
;if you don't override them first. So even if you don't set those options
;(or if you forget to include this file in the root of your SD card), the
;options below are used.
;[DEFAULT]
;path = /boot_default.3dsx
;delay = 90
;offset = 0x12000
;payload = -1
;Each key can be defined using a section, like the example below. Section
;names may have arbitrary caps. Valid keys (both O3DS and N3DS):
;KEY_A, KEY_B, KEY_SELECT, KEY_START, KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT,
;KEY_R, KEY_L.
;Valid keys (N3DS only):
;KEY_ZL, KEY_ZR, KEY_CSTICK_RIGHT, KEY_CSTICK_LEFT, KEY_CSTICK_UP,
;KEY_CSTICK_DOWN.
;Directional keys (like KEY_UP) counts to both D-pad and circle pad.
;[key_L]
;path = /boot_something.3dsx
;The only option you need to set in the majority of the cases is 'path'.
;You may pass a .3dsx file or a .dat/.bin payload, the file type is detect
;automatically based on extension. Double check the path, since it must be
;correct (including caps).
;All the other ones are COMPLETELY OPTIONAL, since BootCtr uses SANE defaults
;when the option is not provided. So unless you know what you're doing, use
;the model below for the rest of the entries and ignore the rest of this
;file.
[KEY_R]
path = /boot_1.3dsx
;Now I will start explaining the advanced options, starting with delay. Delay
;is a number to delay the application boot.
;It is related to the number of frames that the BootCtr will wait before
;running your application. Since 3DS renders at 60FPS, if you set your delay
;to 60, for example, the application will be delayed for 1 second.
;Why this is important? It may improve the booting of some homebrews and CFWs.
;For example, O3DS autobooting with themehax, using either rxTools or
;CakesFW with Brahma2 loaders will have increased boot rate chance with 100
;ms of delay. For Homebrew Launcher (and other homebrews) the delay may be
;set to 0, unless your homebrew needs network connection during boot (such as
;FTBrony). In this case you may increase the delay (for example to 300 or 5
;seconds) to makes sure that you have a valid network connection.
;By default delay is set to 90, or 1.5s. This is a value that seems to work
;well with CFWs, without delaying the boot of homebrews by too much. You
;should not set a delay, unless you're having difficult to boot something
;(i.e. FTBrony).
;[KEY_A]
;path = /boot_hbl.3dsx
;delay = 0
;[KEY_B]
;path = /3ds/ftbrony/ftbrony.3dsx
;delay = 300
;Instead of loading .3dsx files, you can use ARM9 payloads like rxTools'
;code.bin or CakesFW's Cakes.dat. By default it will try to detect if the
;file is a payload by checking the extension (.bin or .dat), however you can
;force by passing "payload = 1" (passing "payload = 0" forces homebrew mode,
;while "payload = -1" forces autodetect).
;You may need to change the default payload offset depending of the binary
;you're loading. Offset of 0x12000 is the default for RxTools/CakesFW.
;Don't worry about setting offset option in .3dsx files, it is ignored.
;[KEY_START]
;path = /rxTools/sys/code.bin
;payload = 1
;offset = 0x12000Btw, this should work with CtrBootManager too nowadays. The problem seems that FTBrony only checks if there is a valid connection after it starts to run. If there is not valid IP, it throws a error and waits to exit. Waiting for about 5 seconds is sufficient to allow a connection, and FTBrony works almost everytime.
Ok, another experimental release (I am on a roll now). This time, I bring back the old delay method (from HBL-Emergency v0.4 and below), instead of the code used by CtrBootManager.
Why? The code from @cpasjuste used to work better than mine when I originally implemented binary payloads in HBL-Emergency. I wondered why. I used to think that, since CtrBootManager used to clean GFX buffers and CakeBrah is all about manipulating GFX, this was the motive. However I know understand why (and it is kinda silly).
Since the code from CtrBootManager used a loop of waiting frames, it means that setting up a delay of 100, for example, is equals to 1.6667 seconds. Why? Since 3DS runs at 60FPS, and you wait 100 frames, you have 100 / 60 (FPS) = 1.6667 seconds! However the default delay I set for HBL-emergency was 100 (the same as today). My old code waited for microseconds, so 100 is 100ms, or 0.1 seconds!
This is what I discovered today, so I decided to return to my old code and set a proper delay by default (1500 = 1500ms, or 1.5 seconds; I could set to 1.6667 seconds too, however even numbers win). The advantage of my (old) new method is that you don't need to do any math to get the exactly delay you want. You can set delays as low a 0.001 too (instead of 0.0167s from before), or something really silly like 6969. Not that this would be useful anyway.
For those of you who boot CFWs using .3dsx files instead of binary payloads, you can set to a value as low as 100-150, it worked before. However the default is not too bad (1.5s), so I still recommend the default value unless you're having a low boot rate or you're using a homebrew that needs network access early on boot (i.e. FTBrony). The new value recommended for FTBrony is 5000, btw (instead of the old 300, since 300 / 60 (FPS) = 5s).
And anyway, for everyone testing this new build: check any delay value that you set up manually and change it accordingly. If you want the exactly the same delay time, get the old value you set up and divide by 60 and multiply by 1000, this will get the new value to set up. For example, let's say you set up an entry to use 120 of delay: 120 / 60 / 1000 = 2000. So you need to set your new delay to 2000.
Or even better, just remove any delay value and accept the 1500 that is the default. It works very well, unless you're using a FTBrony-like homebrew.
Why? The code from @cpasjuste used to work better than mine when I originally implemented binary payloads in HBL-Emergency. I wondered why. I used to think that, since CtrBootManager used to clean GFX buffers and CakeBrah is all about manipulating GFX, this was the motive. However I know understand why (and it is kinda silly).
Since the code from CtrBootManager used a loop of waiting frames, it means that setting up a delay of 100, for example, is equals to 1.6667 seconds. Why? Since 3DS runs at 60FPS, and you wait 100 frames, you have 100 / 60 (FPS) = 1.6667 seconds! However the default delay I set for HBL-emergency was 100 (the same as today). My old code waited for microseconds, so 100 is 100ms, or 0.1 seconds!
This is what I discovered today, so I decided to return to my old code and set a proper delay by default (1500 = 1500ms, or 1.5 seconds; I could set to 1.6667 seconds too, however even numbers win). The advantage of my (old) new method is that you don't need to do any math to get the exactly delay you want. You can set delays as low a 0.001 too (instead of 0.0167s from before), or something really silly like 6969. Not that this would be useful anyway.
For those of you who boot CFWs using .3dsx files instead of binary payloads, you can set to a value as low as 100-150, it worked before. However the default is not too bad (1.5s), so I still recommend the default value unless you're having a low boot rate or you're using a homebrew that needs network access early on boot (i.e. FTBrony). The new value recommended for FTBrony is 5000, btw (instead of the old 300, since 300 / 60 (FPS) = 5s).
And anyway, for everyone testing this new build: check any delay value that you set up manually and change it accordingly. If you want the exactly the same delay time, get the old value you set up and divide by 60 and multiply by 1000, this will get the new value to set up. For example, let's say you set up an entry to use 120 of delay: 120 / 60 / 1000 = 2000. So you need to set your new delay to 2000.
Or even better, just remove any delay value and accept the 1500 that is the default. It works very well, unless you're using a FTBrony-like homebrew.
Last edited by m45t3r,
The first new (exciting) release after sometime. Tons of (possibly) breaking changes for the sake of reducing binary size (ok, actually is just because I like clean code).
Here we comes: release v1.3
This release probably has the simplest code ever.
For those of you who like to compile directly from Git, you may better deleting the old files and make a full clone again (unless you know how to use Git). I reorganized some repository files so maybe you will have building failures if you build using the old files.
Here we comes: release v1.3
This release probably has the simplest code ever.
For those of you who like to compile directly from Git, you may better deleting the old files and make a full clone again (unless you know how to use Git). I reorganized some repository files so maybe you will have building failures if you build using the old files.
Last edited by m45t3r,
You mentioned how booting a cfw from a .3dsx will allow you to use a small delay with high success, is booting from the .dat (reinand.dat) warranting an even lower delay or higher than if booting with a .3dsx?
You may set (however don't need too) a small delay (like 100-150) instead of 1500 when using .3dsx files. This will make your boot slightly faster, however it does not mean it will be faster than simple using the binary payload directly.
Binary payloads (.dat, .bin) needs a higher delay (the 1500 that is the default is ok) to have reliable boot.
Using .3dsx files with small (100-150) or high (1500) delay should have a similar boot rate than using a binary payload with high delay.
Of course, this is in my experience. Maybe you will have a better boot rate with one or another. There is the fact too that I don't have a N3DS, all these that I said above is for a O3DS (however, some N3DS users reported similar findings than the described above).
TL;DR: the default delay (1500) is ok for both .3dsx and binary payloads (.dat, .bin), you shouldn't need to change.
Just FYI, I did not have a boot failure using CakesFW and the new modifications of BootCtr yet (of course, this is excluding the failures of homemenuhax, that are pretty frequently).
Last edited by m45t3r,
O3DS or N3DS? Homebrew or CFW (and which CFW you're using)? If CFW, .3dsx file or binary payload? Which firmware version (sysNAND)? Which *hax you're using (homemenuhax, browserhax)?
And btw, are you sure that the problem is in BootCtr and not *hax? Remember that BootCtr is only loaded after the debug screen from *hax.
Without these info I can only make blind guesses. Maybe trying to set delay to 2000 may solve your problem.
Edit: I am assuming you're running the lastest version of BootCtr too (v1.3), right?
Last edited by m45t3r,
2DS
CFW RxTools
Sysnand 9.2
Homemenuhax
Menuhax loads shows all the colors on the bottom screen and all the words pop up. Then it just stays on a black screen.
--------------------- MERGED ---------------------------
RxTools logo fails to popup when ever it does this
Are you running the lastest version (v1.3)? If yeah, can you test version v1.2.1?
Similar threads
-
@
Sicklyboy:
@SylverReZ, Oh yeah, arguably doing better than ever. They're releasing new sets constantly for it+1 -
-
-
@
SylverReZ:
Nice. I wish they bought back collectable figurines in blind bags, which I had as a kid. -
@
Sicklyboy:
I like buying the Halo Megablox blind bags every once in a while when I see them. Scratches that itch
-
-
-
@
hitorikuroi:
i have a question currently my atmos switch isnt picked up by pc on HOS but the cable and port do work with apx and tegra so i know the hardware is good, any clue? -
-
-
-
-
-
-
@
Psionic Roshambo:
Well on a good day life does suck... lol on a bad day it just sucks differently lol+3
-
-
-
-
-
-
@
BakerMan:
it's just in an empty open space, like outside at night or the backrooms, depending on the branch of the hypothetical you either feel unsafe, but you actually are safe, or you feel safe, but are unsafe, also you don't actually know the truth about your safety either way -
-
-
-