Hacking Understanding and changing Snes VC RPX settings

[xavix]

Anyway, here's a basic guide:
Run rpl2elf on the dumped .rpx.
Open the elf in a hex editor and search for 392003563860(hex)
Replace the 0356 part with 0280
Search again for 043838E0078090(hex) and replace the 0438 with 01E0 and the 0780 with 0280
Convert back to rpx by running in the sdk tools folder:
set CAFE_ROOT=../../../
makerpl64 -f -z8 -old -s name.elf

Copy back to sd card and run with loadiine.
Done!

great even the NES are working on full screen.

Spoiler

 

[the_randomizer]

great even the NES are working on full screen.

Spoiler

Did you edit the same offsets as Snes games (as in, do they share the same ones)? I wonder though, if Snes filtering can be altered, as NES games have a filter for some reason.

 

[xavix]

yep same offsets like the snes.elf

 

[the_randomizer]

yep same offsets like the snes.elf

Wow, that's good to know, man, I honestly never thought this thread would take off this quick, but I'm glad I was wrong, getting these results, so freaking awesome Now, I assume that I can dump NES games with DDD as well?

 

[ShadowOne333]

great even the NES are working on full screen.

Spoiler

Wow, thanks for the heads up!
So the same addresses are being used for both the NES and SNES emulators.
It might be worth adding to the OP alongside the steps for the change of aspect ratio.

If @shutterbug2000 manages to get the N64 full screen working, perhaps the changes could be applied to GBA RPX files too.
Who knows?!

 

[the_randomizer]

Wow, thanks for the heads up!
So the same addresses are being used for both the NES and SNES emulators.
It might be worth adding to the OP alongside the steps for the change of aspect ratio.

If @shutterbug2000 manages to get the N64 full screen working, perhaps the changes could be applied to GBA RPX files too.
Who knows?!

Yeah, gonna do a meticulous overhaul of the OP

 

[VinsCool]

Do they also work for n64?

 

[the_randomizer]

Do they also work for n64?

Not yet, we'll need to find out which offsets actually control the screen size, a couple of pages back, Shutterbug found out how to control it somewhat, but will need to look more into. The same offsets are shared with NES and Snes though.

 

[ShadowOne333]

Do they also work for n64?

@shutterbug2000 found the part of the ELf that changes the aspect ratio.
However, it seems that the N64 VC uses something similar to the DS in terms of display.
It positions the image with an offset in X, like the Screen positions in the DS configuration file.
Once he manages to find the part of the ELF that deals with the X position, full screen N64 VC should be possible.

 

[shutterbug2000]

Yeah, gonna do a meticulous overhaul of the OP

Looks nice .

 

[the_randomizer]

Looks nice .

Thanks I've been meaning, have you had any luck looking into the filters by chance?
GX2InitSamplerXYFilter and GX2InitSamplerZMFilter would be the GX2 commands for that I believe? Curious mostly, as they could use a bit more filtering

 

[shutterbug2000]

Thanks I've been meaning, have you had any luck looking into the filters by chance?
GX2InitSamplerXYFilter and GX2InitSamplerZMFilter would be the GX2 commands for that I believe? Curious mostly, as they could use a bit more filtering

Not yet, been focusing mostly on N64.

 

[the_randomizer]

Not yet, been focusing mostly on N64.

Fair enough, take your time, man, and thank you.

 

[QuarkTheAwesome]

For those of you curious about how exactly @shutterbug2000's mods work, I thought I'd see what this does in IDA. This was against a copy of Super Mario Kart.

Here's the first section (0x392003563860) unmodified in IDA. I've renamed some of the functions so we know what they do.
Don't worry too much about exactly what's happening, the function calls are what's interesting here.

That second line (li r9, 0x356) is the one shutterbug modifies. Right now, the program is loading r8 with 0x1E0 (480) and r9 with 0x356 (854). 854x480 is the resolution of the gamepad, and you can see from the code snippet above that this is where it's setting up the framebuffers (places to store the images).

Anyway, as you've probably guessed, swapping out that 0x356 for 0x280 (640) changes the size of the gamepad's framebuffer from 854x480 to 640x480, essentially turning the gamepad into a 4:3 screen. However, somewhere along the line the graphics card stretches the small framebuffer to the actual resolution of the gamepad, thus leaving us with a stretched 16:9 image!

Here's the modified code in IDA if you're interested (not much to look at):

See how the second line is different? Anyway, now onto the TV. This is the code snippet that needs modifying:

Shutterbug's changing the 0x438 (1080) on line 1 and the 0x780 (1920) on line 2 to 0x1E0 (480) and 0x280 (640), or 640x480. You may recognise this as the same resolution the Gamepad was modified to - theoretically the TV can be spoofed to any resolution with this method, but it's just simpler if they're both the same. Again, this image is stretched to the resolution chosen in System Settings.

Interestingly, people who aren't using 1080p as an output resolution will still have the 4:3 image on the TV (although the gamepad mod will work), although this can easily be fixed by changing a couple more values.

Spoiler: Fixing other resolutions

Here's where my copy of Mario Kart picks which resolution it's going to run at:

(setTvResolution is the 1080p setting I took a screenshot of above.) "un know" takes best misspelling in a commercial product of the week btw.
All the setTvResolution functions jump to the DRC init stuff and never return so that OSReport shouldn't be called under normal circumstances.

findTvResolution is called from a strangely familiar location (guess you were right to look there, sorry):

(I suspect setTvResolution480p is there in case the TV is in 576i mode which GX2 doesn't seem to support, instead upscaling 480p stuff).
(Also worth noting that GX2 won't render in 1080i, only 1080p. That means we only need to worry about 1080p, 720p and 480p).

Anyway, the real meat of this is the setTvResolution720p and setTvResolution480p functions. Here they are:

Note the first two instructions of each function - setting the resolution.

You can find the 0x1E0 from setTvResolution480p at offset 0x1BB6A in my copy of Mario Kart, while the 0x300 is at 0x1BB6E.
Here's an image of that in HxD if you want the surrounding values (check the 0A and 0E columns of the first line for values):

As for setTvResolution720p, 0x2D0 is at 0x1BC2A and 0x500 is at 0x1BC2E. Here's another image (again, 0A and 0E in the first line):

So there you go, some nice offsets showing how this could be fixed for non-1080p users. As I mentioned before, you don't have to worry about 576i (or 1080i for that matter) since GX2 doesn't support those resolutions.
Enjoy! I'm curious to know whether this could be done as a cheat code.

 

[ShadowOne333]

For those of you curious about how exactly @shutterbug2000's mods work, I thought I'd see what this does in IDA. This was against a copy of Super Mario Kart.

Here's the first section (0x392003563860) unmodified in IDA. I've renamed some of the functions so we know what they do.
Don't worry too much about exactly what's happening, the function calls are what's interesting here.

That second line (li r9, 0x356) is the one shutterbug modifies. Right now, the program is loading r8 with 0x1E0 (480) and r9 with 0x356 (854). 854x480 is the resolution of the gamepad, and you can see from the code snippet above that this is where it's setting up the framebuffers (places to store the images).

Anyway, as you've probably guessed, swapping out that 0x356 for 0x280 (640) changes the size of the gamepad's framebuffer from 854x480 to 640x480, essentially turning the gamepad into a 4:3 screen. However, somewhere along the line the graphics card stretches the small framebuffer to the actual resolution of the gamepad, thus leaving us with a stretched 16:9 image!

Here's the modified code in IDA if you're interested (not much to look at):

See how the second line is different? Anyway, now onto the TV. This is the code snippet that needs modifying:

Shutterbug's changing the 0x438 (1080) on line 1 and the 0x780 (1920) on line 2 to 0x1E0 (480) and 0x280 (640), or 640x480. You may recognise this as the same resolution the Gamepad was modified to - theoretically the TV can be spoofed to any resolution with this method, but it's just simpler if they're both the same. Again, this image is stretched to the resolution chosen in System Settings.

Interestingly, people who aren't using 1080p as an output resolution will still have the 4:3 image on the TV (although the gamepad mod will work), although this can easily be fixed by changing a couple more values.

Spoiler: Fixing other resolutions

Here's where my copy of Mario Kart picks which resolution it's going to run at:

(setTvResolution is the 1080p setting I took a screenshot of above.) "un know" takes best misspelling in a commercial product of the week btw.
All the setTvResolution functions jump to the DRC init stuff and never return so that OSReport shouldn't be called under normal circumstances.

findTvResolution is called from a strangely familiar location (guess you were right to look there, sorry):

(I suspect setTvResolution480p is there in case the TV is in 576i mode which GX2 doesn't seem to support, instead upscaling 480p stuff).
(Also worth noting that GX2 won't render in 1080i, only 1080p. That means we only need to worry about 1080p, 720p and 480p).

Anyway, the real meat of this is the setTvResolution720p and setTvResolution480p functions. Here they are:

Note the first two instructions of each function - setting the resolution.

You can find the 0x1E0 from setTvResolution480p at offset 0x1BB6A in my copy of Mario Kart, while the 0x300 is at 0x1BB6E.
Here's an image of that in HxD if you want the surrounding values (check the 0A and 0E columns of the first line for values):

As for setTvResolution720p, 0x2D0 is at 0x1BC2A and 0x500 is at 0x1BC2E. Here's another image (again, 0A and 0E in the first line):

So there you go, some nice offsets showing how this could be fixed for non-1080p users. As I mentioned before, you don't have to worry about 576i (or 1080i for that matter) since GX2 doesn't support those resolutions.
Enjoy! I'm curious to know whether this could be done as a cheat code.

Many thanks for that explanation!
It certainly gave a much clear idea of how the ARM code for the functions of the emulator work, and could be really helpful to debug and find other functions and also modify other VC titles.
So far this method workds for both SNES and NES games, and with that explanation I'll give N64 and GBA another try to see what else I can find.

As for turning it into a cheat code, I'm not sure, I always thought cheat codes modified RAM directly, don't they?
Perhaps @dimok could tell if this could be implemented as some sort of cheat code with Loadiine.

 

[the_randomizer]

So @QuarkTheAwesome what would you suggest we do as an alternative solution? Keep this hacking method as is or change them to another resolution? Personally, I don't like the black borders, even if this method isn't 100% ideal, I do like how it looks. Have you had a chance to look at how the VC handles the filtering? That being said, I believe it to be a big step in the right direction, that fact we can alter how games look and behave is pretty cool I believe GX2InitSamplerXYFilter and GX2InitSamplerZMFilter control the filtering itself, wonder in what way it could be altered, as NES games are really filtered.

Edit: If we wanted to change the TV output to 720p, what do we need to change?

Now, obviously we change the TV resolution at offset
043838E0078090

0x438 changes to 0x1E0 = 640
0x780 changes to 0x280 = 480

To make it 1280 x 720p

0x438 changes to 0x2D0
0x780 changes to 0x500

I hope I got that right

 

[deshayzilla]

This threat has gotten me more excited about Wii U hacking than anything else. Giving us better options for Wii U Virtual Console games is amazing! I can't wait to see a day where GBA games didn't look so discolored, N64 games aren't so dark, and NES games didn't look so dark and discolored.

 

[ShadowOne333]

This threat has gotten me more excited about Wii U hacking than anything else. Giving us better options for Wii U Virtual Console games is amazing! I can't wait to see a day where GBA games didn't look so discolored, N64 games aren't so dark, and NES games didn't look so dark and discolored.

That'd be gamma correction.
Although, I think the decoloration in some GBA games helps.
The earlier GBA games have a huge amount of oversaturation which made them too bright and coloured, it wasn't until the GBA SP came out that games adopted "human" palettes for their games.
If we end up having control over the Gamma correction for the Virtual Console games, we could choose which games should have gamma correction and which don't. For example, let's say you inject SMA2 with gamma correction to make it closer to the original SNES title in terms of colour, and SMA4 but with NO gamma correction since that game came out after the SP.

 

[the_randomizer]

This threat has gotten me more excited about Wii U hacking than anything else. Giving us better options for Wii U Virtual Console games is amazing! I can't wait to see a day where GBA games didn't look so discolored, N64 games aren't so dark, and NES games didn't look so dark and discolored.

I was sick of Snes games looking so weird with the black borders, I had to start something, I never thought others would jump on board but sure enough, people are and I couldn't be more grateful; we now know that Snes and NES games share the same offsets when it comes to changing the aspect/resolution. The next things would be to check out the filtering and gamma, which are also controlled via GX2 rendering.

That'd be gamma correction.
Although, I think the decoloration in some GBA games helps.
The earlier GBA games have a huge amount of oversaturation which made them too bright and coloured, it wasn't until the GBA SP came out that games adopted "human" palettes for their games.
If we end up having control over the Gamma correction for the Virtual Console games, we could choose which games should have gamma correction and which don't. For example, let's say you inject SMA2 with gamma correction to make it closer to the original SNES title in terms of colour, and SMA4 but with NO gamma correction since that game came out after the SP.

Actually, M2 handled the GBA emulator (same people programmed the Megadrive emulator on Wii) and some games do look a bit better, but you are right in that many games have over-saturation and need to be adjusted somehow, I haven't looked too much into GBA games yet

 

[deshayzilla]

That'd be gamma correction.
Although, I think the decoloration in some GBA games helps.
The earlier GBA games have a huge amount of oversaturation which made them too bright and coloured, it wasn't until the GBA SP came out that games adopted "human" palettes for their games.
If we end up having control over the Gamma correction for the Virtual Console games, we could choose which games should have gamma correction and which don't. For example, let's say you inject SMA2 with gamma correction to make it closer to the original SNES title in terms of colour, and SMA4 but with NO gamma correction since that game came out after the SP.

This is why I think Nintendo should give us the option to switch this. I love the way these games look through an Emulator and it's a shame that the version you pay for on the Wii U has almost little to no options for customization (I am happy that they include 1:1 mode for GBA games). Advanced Wars was an early GBA game that might have been oversaturated due to the SP not being at thing yet, but it still doesn't look right to me on the Wii U. The correction they do makes everything look way too green and it turns white into grey. In my opinion SNES games look the best out of all the virtual console systems. Of course everyone has their own opinion on how these games should look to them, I just want the option to set it to my preferences and I'm so happy people are working to fix this!

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

I was sick of Snes games looking so weird with the black borders, I had to start something, I never thought others would jump on board but sure enough, people are and I couldn't be more grateful; we now know that Snes and NES games share the same offsets when it comes to changing the aspect/resolution. The next things would be to check out the filtering and gamma, which are also controlled via GX2 rendering. "

Glad you started poking around! This stuff gets me more excited than running Wii U games from an SD card.