Homebrew TWPatcher - DS(i) mode screen filters and patches

[Sono]

Welp... it seems like TWPatcher is useless now, as it's possible to replace it with DS-side code using DS-->3DS code upload

With @Gericom, we ironed out the initial idea, and now it's possible to super reliably do DS<-->3DS communication, and do arbitrary code execution on the ARM11, allowing for very cool things, such as remaking TWPatcher's features entirely in DS mode, and upload the patches as needed... or even a hybrid DS-3DS mini-homebrew, if that would suit your taste better.

There might be still some issues and edge cases, but the testing we have done shows huge success

And yes, this means that it's possible to integrate TWPatch goodies into TWiLightMenu++ now, so you won't need to wait 6 whole minutes on the old3DS to be able to play your games I'm sure @Robz8 will love my spagetti code.

Here is the DS-side project if you're interested in tinkering with what we have now: https://github.com/Gericom/Rtc3DS
And here is the 3DS-side rtcom bootloader's source; it's tiny: https://github.com/SonoSooS/TWPatch_a/blob/master/data/trainer.S

The patcher is 32bit this time, so everyone can run it (hopefully). I'm using a 64bit wineprefix, and the 32bit build works just fine there.
For "release" rtcom build, run mkpatch_b asd 11010100
For "debug" rtcom build, run mkpatch_b asd 11010110

Note: this patcher is NOT USEFUL, it's basically the same as the previous one, except this one includes the rtcom bootloader. As usual, sleep mode still doesn't work...

 

[aisac]

i ment erorr on the right top screen

 

[Wuigi]

I get a guru meditation error when using this patch, does nds-bootstrap need to be updated first?
Edit:
Ok I get the error with the old patcher as well so my exefs dump is probably bad.

 

[Vague Rant]

Welp... it seems like TWPatcher is useless now, as it's possible to replace it with DS-side code using DS-->3DS code upload

I don't think that makes TWPatcher useless since you still need a way to get that DS-side code running, right? And things like your purchased cartridges, DSiWare, flash cards, etc. won't be running that way? Certainly, you can include a patch like that in nds-bootstrap, but then (meaning no disrespect to nds-bootstrap and its authors) you're limited to whatever you can do via nds-bootstrap, which means a lower compatibility rate than retail games/DSiWare games/flash cards. I think something that runs across all of DS mode still has a place since there's plenty of things you can do in DS mode that don't involve TWLMenu++ or nds-bootstrap.

 

[Rahkeesh]

Oh come on, people don't pay for their games here!!!!

More seriously, I don't blame devs for focusing on TWilight menu. I finally got gericom's GBArunner2 working with that and its just night and day in both compatibility and performance compared to running from my Acekard 2i. Its not a huge step for people here to dump their carts or convert DSIware if they have to.

Although it sounds like this new method would probably mean abandoning AGB_FIRM? That's not too bad if we can get Gbarunner2 properly scaled though, which isn't clear to me.

 

[DSoryu]

Oh come on, people don't pay for their games here!!!!

More seriously, I don't blame devs for focusing on TWilight menu. I finally got gericom's GBArunner2 working with that and its just night and day in both compatibility and performance compared to running from my Acekard 2i. Its not a huge step for people here to dump their carts or convert DSIware if they have to.

Although it sounds like this new method would probably mean abandoning AGB_FIRM? That's not too bad if we can get Gbarunner2 properly scaled though, which isn't clear to me.

There's the sound lag limitation still present in GBAR2, but a workaround is being researched but is a hard task and will take time, untill that happens, AGB_FIRM is still superior (On 3DS side). I believe that some patches could be done for AGB_FIRM that wil let custom folders for savegames (a direct save to a SD card location instead of NAND) and gyro support as well.

 

[Vague Rant]

My point is that not everything runs (or runs well) with nds-bootstrap. It's always improving, so that may not be the case forever, but right now if you want to play games like Golden Sun: Dark Dawn or Sideswiped, it's retail cards, flash cards, or nothing. If you want to use Download Play in many games, or if a game uses the soft-reset function (e.g. Star Fox Command when exiting from a menu), or if you want to use any number of incompatible Action Replay codes, again, nds-bootstrap isn't going to serve your purposes.

I want to be super clear, I'm not criticizing nds-bootstrap in any way, it's an incredible achievement, but in its current state there's a lot of things it just doesn't do, that you can do using other methods.

 

[Rahkeesh]

I'm just guessing that patching AGB_FIRM got significantly harder than with the previous setup because we are doing way more involved things than playing with matricies and you'd have to duplicate that effort. This did start as a DS project after all. I mean if we're shooting for the stars, maybe we can get TWlight or a 3DS homebrew browser to launch any arbitrary rom using AGB_FIRM too, but that sounds like a lot of work.

 

[DSoryu]

I'm just guessing that patching AGB_FIRM got significantly harder than with the previous setup because we are doing way more involved things than playing with matricies and you'd have to duplicate that effort. This did start as a DS project after all. I mean if we're shooting for the stars, maybe we can get TWlight to launch any arbitrary rom using AGB_FIRM too, but that sounds like a lot of work.

AGB_FIRM doesn't have SD access (there are code leftovers for that but it hasn't been reversed yet) so the only possible way to do that that comes to my mind, is to make a temporary on-the-fly GBA inject and pass it thorugh ARM11 from DS mode, which could be pretty slow if the bandwith is not enough or limited. Is a wild idea but could be made, and like you said, it could involve a lot of work.

Another feature I would like to see is what I mentioned above, custom folders for your save files in AGB_FIRM, will save a lot of not-friendly procedures, and would coexists with emulator and GBARunner2 saves.

Take my ideas with a grain of salt, I'm only making those based on the very little knowledge I currently have on the 3/DS/i scene, but my programing experience tells me that this could be possible, if there's no limitations whatsoever of course.

 

[Valery0p]

If you want to use Download Play in many games,

Since you are bringing that up, I would like to remember to you guys that a workaround exists for playing single cart multiplayer with nds bootstrap, and it's a shame that this patch isn't bundled with TWiLight Menu or a CFW like Hiya/Luma:
https://gbatemp.net/threads/rsa-patch-for-dsi-download-play.538078/
What do you think about it @Robz8 ?

 

[Wuigi]

I downloaded a clean 0004013800000102 from nintendo cdn, installed it with citra that has decryption keys and got the section0.bin via ctrtool and firmtool.
If I launch a widescreen game it switches to 16:10 but still boots to the guru meditation error, did it break with the latest twilightmenu or is a sector size of 64KB too much?
When I use it in luma/sysmodules it applies the widescreen without the error so I guess the current nds-bootstrap that is bundled with twilightmenu is at fault.
Edit:
Yep, the latest nds-bootstrap release from github doesn't let the guru meditate, the stretching part doesn't get applied though so everything looks squished together.

 

[RocketRobz]

Since you are bringing that up, I would like to remember to you guys that a workaround exists for playing single cart multiplayer with nds bootstrap, and it's a shame that this patch isn't bundled with TWiLight Menu or a CFW like Hiya/Luma:
https://gbatemp.net/threads/rsa-patch-for-dsi-download-play.538078/
What do you think about it @Robz8 ?

This fixes the crash on the Nintendo logo, which makes homebrew boot from DLP (outside of Haxxstation), but then just crashes on a white screen.

 

[Sono]

i ment erorr on the right top screen

That's not error, that's just debug state.

I don't think that makes TWPatcher useless since you still need a way to get that DS-side code running, right? And things like your purchased cartridges, DSiWare, flash cards, etc. won't be running that way? Certainly, you can include a patch like that in nds-bootstrap, but then (meaning no disrespect to nds-bootstrap and its authors) you're limited to whatever you can do via nds-bootstrap, which means a lower compatibility rate than retail games/DSiWare games/flash cards. I think something that runs across all of DS mode still has a place since there's plenty of things you can do in DS mode that don't involve TWLMenu++ or nds-bootstrap.

I'd make a dummy patcher which only adds rtcom to TwlBg.

Also, can't you launch patched cartridges from TWiLightMenu++ ?

Oh come on, people don't pay for their games here!!!!

More seriously, I don't blame devs for focusing on TWilight menu. I finally got gericom's GBArunner2 working with that and its just night and day in both compatibility and performance compared to running from my Acekard 2i. Its not a huge step for people here to dump their carts or convert DSIware if they have to.

Although it sounds like this new method would probably mean abandoning AGB_FIRM? That's not too bad if we can get Gbarunner2 properly scaled though, which isn't clear to me.

Sadly GBARunner2 doesn't have 100% compat, so I'd still need to find a way to be able to play Hardvest Moon, because it crashes in GBARunner2.

There's the sound lag limitation still present in GBAR2, but a workaround is being researched but is a hard task and will take time, untill that happens, AGB_FIRM is still superior (On 3DS side). I believe that some patches could be done for AGB_FIRM that wil let custom folders for savegames (a direct save to a SD card location instead of NAND) and gyro support as well.

I don't know yet the state of the ARM9, but if ARM9 is still alive and in 3DS mode, then homebrew SD support is definitely possible. It just requires more research.

As for GBA<-->3DS, it might not be possible. We still need to do a lot of experiments.

I'm just guessing that patching AGB_FIRM got significantly harder than with the previous setup because we are doing way more involved things than playing with matricies and you'd have to duplicate that effort. This did start as a DS project after all. I mean if we're shooting for the stars, maybe we can get TWlight or a 3DS homebrew browser to launch any arbitrary rom using AGB_FIRM too, but that sounds like a lot of work.

It's not really more difficult (other than space limitations ofc), because there is still some shared codespace between the two. The only difference is that AgbBg is very, VERY trimmed down, and it's really small, because it doesn't have to setup an entire DSi environment.

As for ROM launching, I have no idea.

AGB_FIRM doesn't have SD access (there are code leftovers for that but it hasn't been reversed yet) so the only possible way to do that that comes to my mind, is to make a temporary on-the-fly GBA inject and pass it thorugh ARM11 from DS mode, which could be pretty slow if the bandwith is not enough or limited. Is a wild idea but could be made, and like you said, it could involve a lot of work.

Another feature I would like to see is what I mentioned above, custom folders for your save files in AGB_FIRM, will save a lot of not-friendly procedures, and would coexists with emulator and GBARunner2 saves.

Take my ideas with a grain of salt, I'm only making those based on the very little knowledge I currently have on the 3/DS/i scene, but my programing experience tells me that this could be possible, if there's no limitations whatsoever of course.

On-the-fly is not possible due to how awfully slow NAND/SD IO is, even though Ninty are squeezing almost every bit of IO performance ouf of the DMA process.

Don't know about folder saves tho'. I'd say it's not worth it due to how many things could go wrong.

 

[Deleted User]

@Sono, Both Harvest Moon games for the gba work really well in the latest mgba build on a New 3DS.

 

[DSoryu]

That's not error, that's just debug state.



I'd make a dummy patcher which only adds rtcom to TwlBg.

Also, can't you launch patched cartridges from TWiLightMenu++ ?



Sadly GBARunner2 doesn't have 100% compat, so I'd still need to find a way to be able to play Hardvest Moon, because it crashes in GBARunner2.



I don't know yet the state of the ARM9, but if ARM9 is still alive and in 3DS mode, then homebrew SD support is definitely possible. It just requires more research.

As for GBA<-->3DS, it might not be possible. We still need to do a lot of experiments.



It's not really more difficult (other than space limitations ofc), because there is still some shared codespace between the two. The only difference is that AgbBg is very, VERY trimmed down, and it's really small, because it doesn't have to setup an entire DSi environment.

As for ROM launching, I have no idea.



On-the-fly is not possible due to how awfully slow NAND/SD IO is, even though Ninty are squeezing almost every bit of IO performance ouf of the DMA process.

Don't know about folder saves tho'. I'd say it's not worth it due to how many things could go wrong.

Thank you for the explanation @Sono, keep it up with your research and I really hope you to find even more cool stuff that may be still hidden, it is pretty interesting

 

[Stellar]

it's a shame that this patch isn't bundled with TWiLight Menu or a CFW like Hiya/Lum

100% agreed. This is a godsend but fairly cumbersome for the average person to use.

 

[aisac]

how to fix the debug state

 

[DSoryu]

how to fix the debug state

Read and follow the instructions again, you made a patch with debug info enabled.

100% agreed. This is a godsend but fairly cumbersome for the average person to use.

It will, but there's not ETA currently as it involves much work to be polished and finished.

 

[Stellar]

It will, but there's not ETA currently as it involves much work to be polished and finished.

That's great news! I don't mind waiting.

 

[Stellar]

Also, could something like this ever be used for GBA VC injects? I really hate the interpolation used.