Views: 1,613,055 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 12-12-24 05:01 PM |
Guest: |
0 users reading Using Brahma as a library / loader | 1 bot |
Main - Homebrew discussion - Using Brahma as a library / loader | Hide post layouts | New reply |
d0k3 |
| ||
Member Normal user Level: 20 Posts: 14/75 EXP: 38311 Next: 4128 Since: 06-04-15 Last post: 3272 days ago Last view: 3019 days ago |
I'm currently working on a derivative of Decrypt9 and for that to load on my N3DS / FW 9.0.0 I need to use Brahma by patois:
https://github.com/patois/Brahma Everything works fine when I run Brahma first, then use the internal menu to run the Decrypt9 payload. However, I don't want to require myself / future users to go through the Brahma menu each and every time, so I just coded a small loader that loads the payload without user interaction. This is my code: #include <3ds.h>
#include "brahma.h" s32 main (void) { srvInit(); aptInit(); hidInit(NULL); gfxInitDefault(); fsInit(); sdmcInit(); hbInit(); qtmInit(); consoleInit(GFX_BOTTOM, NULL); if (brahma_init()) { load_arm9_payload(PAYLOAD); firm_reboot(); brahma_exit(); } hbExit(); sdmcExit(); fsExit(); gfxExit(); hidExit(); aptExit(); srvExit(); return 0; } Using Brahma as a library in the way above is intended by patois:
I'm also pretty sure half of the inits in the code above are completely useless, however, as I'm getting desperate, I'm trying to do it exactly the way patois does. In fact, save for a few hid input functions, this does exactly the same as Brahmas quick boot feature. I also tried to leave out part of the inits, but that lead to bad results (crashes). I haven't changed anything else in the Brahma source code. Now, if I use my loader to load the Decrypt9.bin payload, this is what I get: The above is actually using Shadowtrances bootstrap-mod code. The rectangles should be purple and the text should be green. The image above looks like some offset is wrong, but, again, it works fine if I go through untouched Brahma instead of using my loader. The problem also persists with other payloads, including patois' own example projects: https://github.com/patois/3DSProjects/tree/master/Brahma/ It's best seen with Shadowtrances Ui design, therefore I'm showing it as an example. Other functionality (besides screen output) seem to work. It even gets worse. I asked Shadowtrance to compile for me, assuming my ctrulib is too recent / something else is wrong in my toolchain. Download the binaries here if interested. Now, even with that, I got the same problems, while it works fine for Shadowtrance. My best bet so far is that it is something similar as with NTR CFW, where it fails more often for some users and waiting a few seconds helps. In fact, the OSKA project (which shares code with Brahma) has a delay function in their loader. I did try to implement a delay function in C, but to no avail so far. So... any ideas? My project is found here if you are interested. EDIT: Because this problem persists, as I wrote, even when following patois instructions and using only his code, I'd just open an issue on Github, but patois has disabled that option, and there's no way to get in touch other than a pull request (which I can't do, because I don't know any solution). |
Steveice10 |
| ||
Newcomer Normal user Level: 7 Posts: 2/7 EXP: 1107 Next: 341 Since: 02-25-15 Last post: 3245 days ago Last view: 2476 days ago |
consoleInit changes the screen format to RGB565, and the payload uses RGB8, so that could be an issue. I don't know why it would affect the top screen though, since it's only being initialized for the bottom screen.
Whether or not it's the cause, you can probably get rid of it since you aren't using the console. |
profi200 |
| ||
Member Who knows? Level: 19 Posts: 16/70 EXP: 34612 Next: 1165 Since: 05-21-15 From: Germany Last post: 3014 days ago Last view: 2882 days ago |
consoleInit() changes stuff only for the selected screen iirc. So you could have a console on 1 screen and just RGB8 graphics on another screen. |
d0k3 |
| ||
Member Normal user Level: 20 Posts: 15/75 EXP: 38311 Next: 4128 Since: 06-04-15 Last post: 3272 days ago Last view: 3019 days ago |
Yes, initially I didn't have the consoleInit() function in there, but I got desperate and untouched Brahma initializes the console before the exploit.
So, that function is not the reason behind the problem, it lies somewhere else. And, I'm actually only using the topscreen. However, the thing about RGB565 instead of RGB8, if I look at it now, somehow sounds plausible. I'll try and see if I can set the RGB mode manually before the exploit. |
mid-kid |
| ||
Newcomer Normal user Level: 5 Posts: 1/3 EXP: 307 Next: 222 Since: 05-22-15 Last post: 3452 days ago Last view: 3220 days ago |
Posted by d0k3 https://github.com/patois/Brahma/pull/3 I made a pull request for switching to RGB8 mode. Maybe you can use the same function calls to switch to your preferred mode. |
d0k3 |
| ||
Member Normal user Level: 20 Posts: 16/75 EXP: 38311 Next: 4128 Since: 06-04-15 Last post: 3272 days ago Last view: 3019 days ago |
Alright, look at my fixed code:
#include <3ds.h>
#include "brahma.h" s32 main (void) { srvInit(); aptInit(); hidInit(NULL); gfxInitDefault(); fsInit(); sdmcInit(); hbInit(); qtmInit(); gfxSwapBuffers(); if (brahma_init()) { load_arm9_payload(PAYLOAD); firm_reboot(); brahma_exit(); } hbExit(); sdmcExit(); fsExit(); gfxExit(); hidExit(); aptExit(); srvExit(); return 0; } Meaning, if I run gfxSwapBuffers() once, the problem goes away for me. Also, patois is aware of the problem now as well. Thanks mid-kid! I guess on GBAtemp I would never have gotten near any solution for this problem. Now, the question remains as to how to make using Brahma as a library easier for future developers? I hope we'll find a good solution. |
Main - Homebrew discussion - Using Brahma as a library / loader | Hide post layouts | New reply |
Page rendered in 0.018 seconds. (2048KB of memory used) MySQL - queries: 26, rows: 73/73, time: 0.005 seconds. Acmlmboard 2.064 (2018-07-20) © 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |