Homebrew [RELEASE] CtrBootManager9 - Clean start.s

[prototech]

Sources are already given in CtrBootManager9_AlphaHighlight.zip.
I think I modified:
- For alpha highlight: menu.c, config.h and config.c
- For offset fix: config.c
- For image background crash: gfx.c

However, I should also learn to use Github if I decide to make some other changes.

EDIT: I think I manage to use GitHub, you should have received a new pull request.
I made a mistake and open a pull request directly to Cpasjuste. I just closed it before even adding a change to this pull request, I hope it leaves nothing wrong in the database...

Looks like it. I'll merge the pull and update the OP tonight after work.

 

[OperationNT]

Got me screen-init installed and I get black screen when using "arm9loaderhax.bin"

I made a new version where I insert the screeninit code (taken from Luma3DS, thanks to AuroraWright and her team!).
Now, your scenario should properly work (only tested on my New3DS XL for now). In the given archive, take the file named "CtrBootManager-1.0/build/CtrBootManager9.bin".

@prototech: I will try to create a pull request for this new feature support. However, I included code from Luma3DS. You will find in the archive that I added a folder named "screeninit" and I changed "CMakeLists.txt" to add the build of "screeninit.bin" (because this binary file is not for ARM9 but for ARM11). It must also be converted into a header file (this is why you will find a script "ConvertScreenInit.bat" which calls "bin2h.exe"). So the compilation process now is a little bit more complicated and I am not an expert of cmake. Do you think this process could be fully automatic?
About using Luma3DS screeninit code, I should maybe ask permission from AuroraWright?

 

[prototech]

v1.1 - https://github.com/Dshoe/CtrBootManager/releases/tag/v1.1
Credits:
@OperationNT

• The images which make the application crashes (the A9LH version of "gfxGetFramebuffer" doesn't check width and height pointers and NULL pointers were given by "drawBg", fix in "gfx.c")
• When the offset was saved (by "Setting" feature), it was corrupted (because it was written in decimal instead of hexadecimal, fix in "config.c")
• Transparency value can be added to the highlight
• Updated a9lh.cfg

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

I made a new version where I insert the screeninit code (taken from Luma3DS, thanks to AuroraWright and her team!).
Now, your scenario should properly work (only tested on my New3DS XL for now). In the given archive, take the file named "CtrBootManager-1.0/build/CtrBootManager9.bin".

@prototech: I will try to create a pull request for this new feature support. However, I included code from Luma3DS. You will find in the archive that I added a folder named "screeninit" and I changed "CMakeLists.txt" to add the build of "screeninit.bin" (because this binary file is not for ARM9 but for ARM11). It must also be converted into a header file (this is why you will find a script "ConvertScreenInit.bat" which calls "bin2h.exe"). So the compilation process now is a little bit more complicated and I am not an expert of cmake. Do you think this process could be fully automatic?
About using Luma3DS screeninit code, I should maybe ask permission from AuroraWright?

It looks like there are no git files in the zip file, so I won't be able to give you proper credit for the commit. Would you mind doing another pull request like last time?

 

[OperationNT]

Ok, I think I manage to create a new pull request with all those changes.
Next time, I think I will install Git (reporting all changes manually can easily bring mistakes...).

 

[prototech]

Ok, I think I manage to create a new pull request with all those changes.
Next time, I think I will install Git (reporting all changes manually can easily bring mistakes...).

If you're interested in coding AT ALL, I recommend you to learn Git, or use a GUI tool like GitKraken or Source Tree. Git has been one of my single favorite tools in all my years of programming. I do see the new pull request though, thank you very much! I also could teach you about squashing commits which will combine several of your last commits (in this case, all the ones in your pull request) into one single commit. This can be nice for cleaning up your commits once you are finished with a feature.

 

[A_Random_Guy]

Would it be possible to add BootCTR9's memory pathchanger luma to this?

 

[OperationNT]

Hello A_Random_Guy,

Can you be more specific about your use case ? I see that the feature you are talking about is referenced in those pages:
https://gbatemp.net/threads/arm9loader-technical-details-and-discussion.408537/page-200
https://github.com/AuroraWright/Luma3DS/wiki/Installation-and-Upgrade

As it is described in the second page, if this feature doesn't exist, you cannot start GBA games from Luma3DS ?
For the moment, I have tested the following case:
- arm9loaderhax.bin is Luma3DS
- I boot "/luma/payloads/start_CTRBootManager9.bin" by maintaining start button on boot
- I start Luma3DS.dat from CTRBootManager9
- When the firmware is loaded, I try to start a GBA game and it works

Maybe I should try to replace "arm9loaderhax.bin" from Luma3DS with CTRBootManager9 directly and try again to reproduce the issue ?

Once I am able to reproduce the issue, do you have any idea where I can see some sample code to fix it ? In BootCTR9 repository ?

Thanks for your help

 

[Xsze]

If you are using CBM9 as a payload of luma you don't need the pathchanger.

and if you are booting luma with CBM9 it's on luma that you need to use the pathchanger not on CBM9. you have to indicate to luma where he can find himself to continue the loading after the reboot of GBA VC games.

 

[A_Random_Guy]

Hello A_Random_Guy,

Can you be more specific about your use case ? I see that the feature you are talking about is referenced in those pages:
https://gbatemp.net/threads/arm9loader-technical-details-and-discussion.408537/page-200
https://github.com/AuroraWright/Luma3DS/wiki/Installation-and-Upgrade

As it is described in the second page, if this feature doesn't exist, you cannot start GBA games from Luma3DS ?
For the moment, I have tested the following case:
- arm9loaderhax.bin is Luma3DS
- I boot "/luma/payloads/start_CTRBootManager9.bin" by maintaining start button on boot
- I start Luma3DS.dat from CTRBootManager9
- When the firmware is loaded, I try to start a GBA game and it works

Maybe I should try to replace "arm9loaderhax.bin" from Luma3DS with CTRBootManager9 directly and try again to reproduce the issue ?

Once I am able to reproduce the issue, do you have any idea where I can see some sample code to fix it ? In BootCTR9 repository ?

Thanks for your help

Replace the arm9loaderhax.bin with the one from CTRBootManager9 and rename the arm9loaderhax.bin from Luma3DS to something else. Thats should remake the issue.

You can see the code at @Wolfvak BootAnim9 or ask @RednaxelaNnamtra

 

[OperationNT]

I was able to reproduce the issue. I renamed "arm9loaderhax.bin" to "Luma3DS.bin" then I put CtrBootManager9 as "arm9loaderhax.bin": my GBA game crashes when I start it.

By looking the following code, I think I undertand the principle:
https://github.com/hartmannaf/BootCtr9/blob/bootloader/bootloader/source/payload.c
https://github.com/Wolfvak/BootAnim9/blob/master/loader/source/main.c

When the binary file is loaded, I must look inside it before launching it for a string "sdmc:/" and replace the next characters by the file path. In my renamed "Luma3DS.bin" file, I manualy hex-edit the path "sdmc:/arm9loaderhax.bin" to "sdmc:/Luma3DS.bin" and I was able to start my GBA game again.

The code seems to be really specific for Luma3DS so I will try to find a way to code a more generic patch (something like "find and replace any string in the binary file by another one").

I was also wondering with this code: what happens if you have a path longer than "sdmc:/arm9loaderhax.bin"? The patch will start to crush other bytes of the binary file?

 

[Xsze]

I was able to reproduce the issue. I renamed "arm9loaderhax.bin" to "Luma3DS.bin" then I put CtrBootManager9 as "arm9loaderhax.bin": my GBA game crashes when I start it.

By looking the following code, I think I undertand the principle:
https://github.com/hartmannaf/BootCtr9/blob/bootloader/bootloader/source/payload.c
https://github.com/Wolfvak/BootAnim9/blob/master/loader/source/main.c

When the binary file is loaded, I must look inside it before launching it for a string "sdmc:/" and replace the next characters by the file path. In my renamed "Luma3DS.bin" file, I manualy hex-edit the path "sdmc:/arm9loaderhax.bin" to "sdmc:/Luma3DS.bin" and I was able to start my GBA game again.

The code seems to be really specific for Luma3DS so I will try to find a way to code a more generic patch (something like "find and replace any string in the binary file by another one").

I was also wondering with this code: what happens if you have a path longer than "sdmc:/arm9loaderhax.bin"? The patch will start to crush other bytes of the binary file?

Luma has already made a little program where you just have to type the new path to change it into her luma.bin has she said on her wiki that it seems nobody read...
https://github.com/AuroraWright/Lum...ng-luma3ds-work-with-an-external-boot-manager

 

[A_Random_Guy]

Luma has already made a little program where you just have to type the new path to change it into her luma.bin has she said on her wiki that it seems nobody read...
https://github.com/AuroraWright/Lum...ng-luma3ds-work-with-an-external-boot-manager

You're the one who should read actually. @OperationNT is trying to reproduce the issue and trying to implement a memory pathchanger to CTRBM9

 

[OperationNT]

You can download an update for CtrBootManager9. This update allows "binary dynamic patch": when a binary file is loaded, it will try to find a given pattern and replace it by another one.

For Luma3DS support, you can edit the "a9lh.cfg" file by adding those lines:

[entry];
title=Luma3DS;
path=/MyLuma3DSPath.bin;
offset=0;
patchMemSearch=730064006D0063003A002F00;
patchMemOverwriteWStr=sdmc:/MyLuma3DSPath.bin;
patchOccurence=1;
key=-1;

In a more general way:
- "patchMemSearch" represents the searched pattern in hexadecimal values (730064006D0063003A002F00 => sdmc:/ with null value between each letter)
- "patchMemOverwrite" represents the values which will overwrite the found pattern (in hexadecimal values)
- "patchMemOverwriteStr" represents a string which will overwrite the pattern (it replaces "patchMemOverwrite" usage)
- "patchMemOverwriteWStr" represents a string with wide characters (null value between each character) which will overwrite the pattern (it replaces "patchMemOverwrite" usage)
- "patchOccurence" represents the occurence to modify: if the pattern can be found multiple times in the loaded binary file, only the indicated occurence will be overwritten (0 means all occurences will be overwritten)
A patch of an entry MUST always end with "patchOccurence" (it is like an entry which must always end with "key").

For the moment, maximum 4 patches are supported for each entry.

I just checked this version with one patch on Luma3DS so I didn't stress this new feature. Report on this thread if you find any issue.

 

[Wolfvak]

I was also wondering with this code: what happens if you have a path longer than "sdmc:/arm9loaderhax.bin"? The patch will start to crush other bytes of the binary file?

In Luma3DS' case the string is actually hardcoded to have 38 chars at maximum (37 regular + '\0').
https://github.com/AuroraWright/Luma3DS/blob/master/patches/reboot.s#L85

I just checked this version with one patch on Luma3DS so I didn't stress this new feature. Report on this thread if you find any issue.

Now try using a smaller string that "sdmc:/arm9loaderhax.bin", like "sdmc:/luma.bin" <- if you don't zero out the rest of the path it won't work.

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

The code seems to be really specific for Luma3DS so I will try to find a way to code a more generic patch (something like "find and replace any string in the binary file by another one").

Fortunately this is the only payload that requires it right now - I doubt anyone else will go this way. It may seem cleaner but IMHO it just makes everything worse.

 

[OperationNT]

Thank you for your return.

Now try using a smaller string that "sdmc:/arm9loaderhax.bin", like "sdmc:/luma.bin" <- if you don't zero out the rest of the path it won't work.

I just modify my "a9lh.bin" file to fit your scenario and it seems to work just fine (Luma3DS is started and allow me to start GBA game):

[entry];
title=Luma3DS;
path=/luma.bin;
offset=0;
patchMemSearch=730064006D0063003A002F00;
patchMemOverwriteWStr=sdmc:/luma.bin;
patchOccurence=1;
key=-1;

In the code of "config.c", I willingly take the "string size+1" to include the '\0' character at the end (no need to fill all the rest of the path with '\0', only one will end the string).

Spoiler: config.c code

} else if (MATCH("entry", "patchMemOverwriteWStr")) {
binary_patch* curPatch = &config->entries[config->count].patches[config->entries[config->count].patchesCount];
int strSize = strlen(item)+1;
curPatch->memOverwriteSize = strSize*2;
for (int i = 0; i < strSize; i++)
{
curPatch->memOverwrite[2*i] = item;
curPatch->memOverwrite[2*i+1] = '\0';
}

Did I make a mistake to reproduce your scenario?

I also try to put another patch to Luma3DS:

patchMemSearch=4C756D613344532076;
patchMemOverwriteStr=Welcome to Luma3DS !;
patchOccurence=1;

It worked too when I entered in Luma3DS configuration menu.

 

[OperationNT]

I just update CtrBootManager9 with support of transparency on all revelant config parameters.
You can see the changelog in "UnofficialRelease_V4" archive for more details and look inside "a9lh.cfg" file for usage.

@prototech : I published all those modifications through GitHub, did you receive the pull request ?

There is still an issue I wasn't able to fix: with some configurations (the default one for example), "File browser" crashes. The issue seems to be inside "void get_dir(const char *path)" function (while loop).

 

[OperationNT]

A new update, again !

I found a way to fix File Browser issues. In fact, the used "fatfs" library was an old one: a "simple" update has corrected the issue. In addition, now, we get full names in File Browser.
I also added a little change when a ".dat" file is inserted in entries: by default, it gets an offset at 0x12000.

Have fun !

@prototech : For the moment, I didn't have time to update my Github repository with those last changes. I will do it tomorrow.

 

[OperationNT]

A new small update (which can fix a potential crash if a path for a background image was given without image).
It also add an automatic offset at 0x12000 if a "dat" file is directly started throught File Browser (not only if the file is added to entry).

@prototech : All those changes are now available in the latest pull request from: https://github.com/OperationNT414C/CtrBootManager/tree/a9lh

 

[prototech]

A new small update (which can fix a potential crash if a path for a background image was given without image).
It also add an automatic offset at 0x12000 if a "dat" file is directly started throught File Browser (not only if the file is added to entry).

@prototech : All those changes are now available in the latest pull request from: https://github.com/OperationNT414C/CtrBootManager/tree/a9lh

Thanks for your continued work! With several other things in my life right now it has become apparent that I do not have time to maintain this, and you are obviously more motivated to improve on the project so kudos to you. If you'd like to go ahead and start a new thread and fork my project then by all means go for it.

If you have any trouble with Git or Github then feel free to PM me and I will be more than happy to help.

 

[OperationNT]

Ok, no problem, I will continue to maintain the project in my forked Github repository. Thank you for your help and your support!

Currently, I am working on a feature to support animated colors. Then I will see if I can put video support as background.