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

[Sono]

That'd be the most user-friendly way. IMO you could release some manual patching instructions in the meantime if it isn't a ton of values but it's your call ultimately.

The only problem with manual patching is that I have a TwlBg either from a pre-1.0.0 factory dump, or a 11.0 dump (I forgot which one), and according to Robz8 's post eariler the offset can be off. But I'll try my best to help the user to locate it.

I added the patch into the first post.

 

[DSoryu]

Yeah uh... I would release the patch, but there is a small problem: TwlBg contains copyrighted material, and it's impossible to patch compressed code without unpacking and repacking it completely.

My idea is to include a patcher homebrew which dumps TwlBg, unpacks it, patches it, then places it in /luma/sysmodules/TwlBg.cxi, and that way you can even specify your own filters.
You can do gaussian filters and double vision with this image processing matrix hardware

@Robz8 Would it be possible to implement said patcher in the Twilight++ updater in the extras section? It would be very convenient . For me, I'll be testing your patch manually @Sono when I get home, is it possible to share the offsets and the values to be changed? Or it cannot be shared for the CR reasons? Thank you very much for your findings, finally we will play NDS games visually better than before.

EDIT: Ninja'd, thanks for the patch info.

 

[Sono]

@Robz8 Would it be possible to implement said patcher in the Twilight++ updater in the extras section? It would be very convenient

It's definitely possible. I'll look into it.

For me, I'll be testing your patch manually @Sono when I get home, is it possible to share the offsets and the values to be changed? Or it cannot be shared for the CR reasons? Thank you very much for your findings, finally we will play NDS games visually better than before.

Oh, I left the patch notes in the first post. That's the best I have for now.

 

[DSoryu]

It's definitely possible. I'll look into it.



Oh, I left the patch notes in the first post. That's the best I have for now.

I see, great! And yeah, I just saw your notes, I wasn't aware before haha. Sorry for the bothering and thank you very much for your work.

 

[Ryccardo]

Not working on 11.10 N3DS - 4A7F4 is right in the middle of a block of strings, and there's no "004EFCA5" anywhere in TwlBG's executable (compressed or not)...

 

[Sono]

Not working on 11.10 N3DS - 4A7F4 is right in the middle of a block of strings, and there's no "004EFCA5" anywhere in TwlBG's executable (compressed or not)...

It's not in the middle of strings, but there are some strings around it. You don't search for "4A7F4" or "4EFCA5", you go to (CTRL-G in HxD) the address 0x4A7F4, and check if the bytes around the cursor are 00 00 00 00 00 00 00 40 00 00 00 00
Once you find that pattern, you select the pattern, and go to the end of the last zero, and then you overwrite the bytes there with
000000000000000000000000000000000000000000000000000000000020004000400040004000200000000000000000000000000000000000000000

 

[Ryccardo]

It's not in the middle of strings, but there are some strings around it. You don't search for "4A7F4"

Yeah, I knew 4A7F4 is supposed to be the address, but...

 

[Sono]

Yeah, I knew 4A7F4 is supposed to be the address, but...
View attachment 172326 View attachment 172327

Oh no, they updated the binary

Also, how did you manage to get code.bin but compressed? If you followed my tutorial then code.bin should always be decompressed

But anyway, try to find
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 40 00 00 00 20 00 40 00 40 00 20 00 00 00 40 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
instead, and count 60 (as in, 0x3C) bytes backwards from the start of this pattern. There should be only a single find for this pattern.

 

[Ryccardo]

Also, how did you manage to get code.bin but compressed? If you followed my tutorial then code.bin should always be decompressed

Actually, when you refer to ihaveamac's github, it says in point 3 of the 3dstool variant how to extract cxi > exefs.bin > exefs/code.bin (compressed) and then in step 4 to extract exefs/code.bin in ./decompressed-code.bin, but then going back to your instructions you say to open exefs/code.bin

Not knowing if it was already uncompressed inside the cxi (and too lazy to check the exheader) I simply tried both

Found that sequence at 40BD0, indeed it's the only copy of it... changed the block just before... and it's working (at least as in not crashing DS mode)

 

[Rahkeesh]

I'd actually be interested in applying a smoother scaling algorithm to GBA games, maybe even trying the DS one. Hopefully a similar process would work on AGB_FIRM.

 

[DSoryu]

Actually, when you refer to ihaveamac's github, it says in point 3 of the 3dstool variant how to extract cxi > exefs.bin > exefs/code.bin (compressed) and then in step 4 to extract exefs/code.bin in ./decompressed-code.bin, but then going back to your instructions you say to open exefs/code.bin

Not knowing if it was already uncompressed inside the cxi (and too lazy to check the exheader) I simply tried both

Found that sequence at 40BD0, indeed it's the only copy of it... changed the block just before... and it's working (at least as in not crashing DS mode)

Just to confirm, I found the code pattern at 4B090 as well, the size is 0x3C. I'm at System version 11.10.0-43U if that info helps Sono . I'm about to recompile the patched xci and I'll edit this post with my result.

EDIT: I get this error when trying to repack exfs.bin

ERROR: open file exefsheader.bin failed
ERROR: create file failed
Presione una tecla para continuar . . .

Strangely, exefsheader.bin does not exist in the directory where I unpacked the cxi in the previous step, did I miss something?

EDIT 2: I had to manually extract the headers and make the header files as 3dstool always failed, it's pretty easy so not a problem.

Finally got the patch output file, it seems that your code disables the blurry filtering and leaves the image upscaled in some type of "raw" looking way, like when you disable bilinear filtering in retroarch or various emulators. It may be not perfect but definitely is much much better than the default scaling method:



Again, thank you very much for your tutorial @Sono , looking forward to more findings and filtering methods if available!

 

[Sono]

I'd actually be interested in applying a smoother scaling algorithm to GBA games, maybe even trying the DS one. Hopefully a similar process would work on AGB_FIRM.

Sadly AGB_FIRM is already as crisp as it can be, however it's possible to do a full-on linear interpolation by searching for the pattern
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 40 00 00 00 20 00 40 00 40 00 20 00 00 00 40 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
and replacing it with
00000000000000000000000000000000000000000000000000005615AA2A00000000AA2A0040AA2A56150040561556150000000000000000AA2A0000000000000000000000000000

I didn't test this, but hopefully this shouldn't hardlock the matrix unit, and should have an even linear interpolation.

 

[botik]

I find in decompress code.bin 11.10

 

[Deleted User]

Weird... I'm not finding it at all, even with what people said and addresses... Who is using what version of a 3ds/2ds (new or old) and what firmware.

 

[Sono]

Weird... I'm not finding it at all, even with what people said and addresses... Who is using what version of a 3ds/2ds (new or old) and what firmware.

You have to search in the decompressed code. I'm using either the 11.0 TWL_FIRM, or a pre-1.0.0 TWL_FIRM, I don't know which one.

 

[Deleted User]

You have to search in the decompressed code. I'm using either the 11.0 TWL_FIRM, or a pre-1.0.0 TWL_FIRM, I don't know which one.

I'm using decompressed rn, not finding it all. Twl firm is different between old and new 3ds's if I recall correctly. I use a new system, specifically n2ds

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

You have to search in the decompressed code. I'm using either the 11.0 TWL_FIRM, or a pre-1.0.0 TWL_FIRM, I don't know which one.

never mind finally found it

 

[ahezard]

This is super nice! congratulations! When I was researching twl_firm I made some scripts to automatically patch it : https://github.com/ahezard/twl_firm_patcher
I can adapt it to includes your patches in it. Still the best would be to have these patches included in the cfw (Luma, etc).

 

[Sono]

This is super nice! congratulations! When I was researching twl_firm I made some scripts to automatically patch it : https://github.com/ahezard/twl_firm_patcher
I can adapt it to includes your patches in it. Still the best would be to have these patches included in the cfw (Luma, etc).

Sure. I'll make a few presets then, so people with different tastes can replace that awful blur filter Nintendo is using with a much higher quality blur filter.

It'll take a few days most likely though, because I don't have too much time.

 

[Alex658]

This is amazing. Great work!

One question, if we are loading TWL_FIRM externally from Luma, does this mean our original one remains safe and unpatched within the hardware firmware? Since i'm an end user i'll wait until the process is automated as to not screw it up. But this is amazing work nonetheless!!

 

[DSoryu]

This is amazing. Great work!

One question, if we are loading TWL_FIRM externally from Luma, does this mean our original one remains safe and unpatched within the hardware firmware? Since i'm an end user i'll wait until the process is automated as to not screw it up. But this is amazing work nonetheless!!

Yes, your TWL_FIRM in the NAND stays untouched, if you want to revert back you only need to disable module patching or simply delete the patch.