@mashers, could you update the post to link to version v0.3? Or better, just link to the release page on GitHub so people can always download the last version (not that I plan to add any new features to this homebrew, for me it is feature complete ;D).
And update the post mentioning that it supports configuration files now, so people does not need to search the posts to encounter the last features.
And update the post mentioning that it supports configuration files now, so people does not need to search the posts to encounter the last features.
Remember this incident? Well I can now 100% of the time replicate it and it happens with both launchers. Just not sure if it's Emergency Boot related now though...
N3DS on 10.1.0-27u
Emergency boot v0.2 (I believe that's the right version)
Mashers launcher as default boot.
Smeas launcher as secondary.
Using themehax.
Load Mashers HBL, wait a second or two for titles to load. Launch PHBank, no issue. Return to Launcher. Wait 3 seconds. Load 3DS Blackjack, which has sound. Exit back to launcher. Wait 3 seconds. Load PHBank again and during red screen/debug screen you hear a screeching, staticky beep. Then after it loads you hear staticky garbled garbage noise.
The screeching beep I mentioned also appears during the red/debug screen when launching other Homebrew titles too after having opened 3DS Blackjack.
Wish I could upload a short video showing this but I am on slow internet. (Basically dial up speed. 64kbs)
Well, first upload to the lastest version (not that will probably help).
Secondly, try to replicate this issue chainload Homebrew Launcher. How? Remove HBL-emergency and directly boot Homebrew Launcher, copy the .3dsx that is your Homebrew Launcher to the 3ds folder, from there launch Homebrew Launcher from Homebrew Launcher menu. Repeat all steps (always remembering to relaunch Homebrew Launcher first before launching the homebrew).
Why? I want to know if this issue is caused by Homebrew Launcher original source code or my modifications. If the issue is on the original code I probably can't fix.
Went ahead and skipped to testing each launcher without emergency boot involved.
Grid launcher had the noise distortion.
Smea's launcher had the noise distortion.
------------
Fortunately I had IronHax to try as well, it had the same results.
------------
But unfortunately this means it's not something you can fix.
Further testing shows that it's an issue with Blackjack 3DS itself. Somehow the sound gets stuck trying to play after the game is closed?
Well, maybe you should report this issue to the homebrew author. What it seems to been happening is that maybe he forgot to reinitialize sound after sleep, this may cause the weird issue with the sound.
Anyway, I did try something in the code to try to fix this issue that is now confirmed not done by me. In the attached version I restored the code from scanner.*, so it means it tries to detect the services that the homebrew needs before running it. It doesn't make any sense? Yeah, I don't even know if this code is actually used for something (since there is no return, however it should since there is tons of source code just to make this code useful). So I am posting those changes in the attached file, it may fix some unknown bug in the future.
Author of 3DS Blackjack here. Looking into the sound issue. The game is made with Lua Player Plus so I'm trying to figure out if I'm doing something wrong or if there is a bug in the LPP source.
When I try to run PHBank bank it tells me to select a target then only lists system settings... I don't have a pokemon game so I don't think I can use it.
Regardless, I have been able to reproduce an issue with Blackjack 3DS and another test Lua program I made. Still trying to figure out exactly what's happening but at the moment I think there is a bug when terminating the sound system in LPP.
I don't know exactly how it works in LPP, however the one thing that you may try (if it is possible in LPP) is to detect if the system is put in sleep, and finish the sound service. After the system goes out of the sleep, reinitialize the sound service.
I'm less inclined to believe it's a sleep related issue. LPP basically just wraps libctru's CSND library, so right now I think it's an issue with either the library or possible the sound channel I'm using. Changing the sound channel seems to fix it but I'm still doing testing...
New release (0.4), adding support for user-friendly (somewhat) error reports: https://github.com/m45t3r/HBL-Emergency/releases/tag/v0.4
So let's say you forgot to put the file in the correct place or did some mistake in boot_config.ini? Now instead of just showing a black/red screen, it now reports the error for the user. Since I need to initialize the GFX, this added around 100KB in the total binary size. However I only initialize the GFX if I truly need (in case of errors), so the boot should still be fast.
For the next release I am planning to add support for .bin files. Having some problems in adding CakeBrah code to my project in a clean way, however when I got it I will put the resulting file here.
So let's say you forgot to put the file in the correct place or did some mistake in boot_config.ini? Now instead of just showing a black/red screen, it now reports the error for the user. Since I need to initialize the GFX, this added around 100KB in the total binary size. However I only initialize the GFX if I truly need (in case of errors), so the boot should still be fast.
For the next release I am planning to add support for .bin files. Having some problems in adding CakeBrah code to my project in a clean way, however when I got it I will put the resulting file here.
New release (0.5), adding support for payload loading: https://github.com/m45t3r/HBL-Emergency/releases/tag/v0.5
So now you can directly load /rxTools/sys/code.bin or /Cakes.dat. See the included boot_config.ini for examples. This feature is basically a reimplementation of CtrBootManager. The code from @cpasjuste helped a lot.
While adding payload support I saw the need for a standalone version of @mid-kid's CakeBrah, that may be used as a submodule (CakeBrah itself does not allow it since there is a main() function in it, so you first would need to exclude the main.c file from the project, making everything a mess). So I created a fork called libcakebrah. It includes some modifications from @d0k3, and fixes all the warnings, so you don't need to include -w in your Makefile just because of CakeBrah. I may upstream my modifications if @mid-kid find them interesting.
So now you can directly load /rxTools/sys/code.bin or /Cakes.dat. See the included boot_config.ini for examples. This feature is basically a reimplementation of CtrBootManager. The code from @cpasjuste helped a lot.
While adding payload support I saw the need for a standalone version of @mid-kid's CakeBrah, that may be used as a submodule (CakeBrah itself does not allow it since there is a main() function in it, so you first would need to exclude the main.c file from the project, making everything a mess). So I created a fork called libcakebrah. It includes some modifications from @d0k3, and fixes all the warnings, so you don't need to include -w in your Makefile just because of CakeBrah. I may upstream my modifications if @mid-kid find them interesting.
Hi what's the difference in loading the payload, for example cakes.dat instead of cakes.3dsx?
The .3dsx file from CakesFW/rxTools (or anything that uses CakeBrah for that matter) does exactly what my code does: it prepares the memory, loads /Cakes.dat or /rxTools/sys/code.bin in memory, load the exploit and reboot the firmware. The only difference is that I include the same code from CtrBootManager that loops the GFX for a while before booting the code (@cpasjuste called this autobootfix, for me it is just a delay), so compared to directly loading .3dsx or using my code in themehax, for example, the boot rate is greatly improved. However, using my code to boot a .3dsx does the same thing and it seems to help the boot rate too, even for Cakes.3dsx/rxtools.3dsx.
Using the payload directly instead of .3dsx may be faster, since instead of themehax->HBL-Emergency->{cakes,rxtools}.3dsx->payload, you have themehax->HBL-Emergency->payload. However the difference should be marginal (a couple of milliseconds at best).
--------------------- MERGED ---------------------------
Oops, forgot to upload the file (well, you can always download from GitHub, however it seems that some people prefer to download from here).
Here we go (v0.5).
REMOVED, see below.
Last edited by m45t3r,
Nice thanks for explaining. Im really ok with old releases, really fast and almost 100% boot rate, i will probably try this later, just for the sake
Ok, I discovered severe top screen corruption when using payload mode to load rxTools. In the version attached there is a fix for that.
Since there isn't any interesting changes, I still consider this v0.5.
Since there isn't any interesting changes, I still consider this v0.5.
https://github.com/mid-kid/CakeBrah/pull/2
Same thing applies, just filter main.c in your Makefile, no need for forking.
I'll merge the warning fixes soon™, though right now I'm working on exams.
Last edited by mid-kid,
Well, I tried to find how to filter main.c out, it didn't work. I will try those instructions after you merge my fixes, though. I needed to fork it anyways to fix the warns (I will delete the fork if all works out in the end).
Anyway, since you're here @mid-kid, let me ask you something: is there any difference between load_arm9_payload() and load_arm9_payload_from_mem() (aside that the second one expects the payload in the memory already)? Because I tried to use load_arm9_payload, and while this works with /Cakes.dat it does not seem to work with /rxTools/sys/code.bin. I had to do something similar to what is included in CakeBrah's main.c to make it work with both.
If load_arm9_payload() does not work as it should, why not transform this function to do something similar in what is included in main.c already, loading the payload in memory and calling load_arm9_payload_from_mem() in the end? I could even do this if you want, and do another PR (however, it would be better to first merge the other PR so there is no conflict).
Edit: forgot to mention, I actually did not use load_arm9_payload() since it does not support offset parameter, so I included the modification from @d0k3. However, the modification should have worked. Ideally, the new function should be similar to what main.c does, however including parameters to pass both payload offset and payload size, like the modification from @d0k3. This would make this function actually useful, and I would not have to write a wrapper in my program.
Last edited by m45t3r,
Similar threads
-
- Article
