Hacking Hacking the WiiU gamepad

[plasmagrass]

While I think it's your project and it's ultimately up to you, I think UART bootloader would open the door for more people to get their hands dirty. Also makes iterating easier, especially for most of us with no FPGA lying around...

 

[Arisotura]

While I think it's your project and it's ultimately up to you, I think UART bootloader would open the door for more people to get their hands dirty. Also makes iterating easier, especially for most of us with no FPGA lying around...

As I said, the UART boot functionality is already present in a stock gamepad.

Just requires a way to connect to the UART pads. One can just solder wires, but it can also be done solderless -- if you have a spare battery connector (from a dead battery), for example. I did that, took spring contacts from some old USB socket and glued them to the bottom of the connector.

What I could provide would be some scripts to build and upload stuff, as an example.

 

[albarapa]

Little status update... since the latest developments in gamepad world, I'm standing at crossroads. Maybe will take a break from this stuff.

Basically, my idea was to provide a simple UART bootloader so other people could also mess with the gamepad without having to wait for melonpad. Then it turns out this functionality already exists in the gamepad's boot ROM, so I don't even need to make that.

However I did start wondering about what I could do on the gamepad, now that "loading code" is a mostly solved problem.

Keep going with melonpad as originally intended?

Make a full-fledged custom firmware? Someone suggested a moonlight port for the gamepad. That could be an interesting idea, and could also be in combination with stock gamepad functionality (ie. connecting to a WiiU, etc). Said CFW could also integrate melonpad's intended functionality and serve as a little homebrew boot menu.

I was also thinking of something to port as a technical demo of sorts. blargSNES? I'm not positive the gamepad would be fast enough for blargSNES, but I guess I can try... maybe the fun DMA stuff could be used to accelerate video rendering somehow.

But I think what I want to do in the near future is reverse-engineer the last big chunk of gamepad hardware, the camera controller and h264 codec. It will be a requirement if we are to do any sort of CFW. Besides, who would say no to some good reverse-engineering work?

There was also the idea of extending gamepad functionality, like for example adding a SD card. It's an interesting idea from the technical challenge standpoint. We have interfaces like SPI and SDIO, but we'd need to find an unused GPIO to act as a select line for the SD card.

So? What does the community think?

I was hoping that your work could contribute to the longevity of the gamepad battery. By no longer going into standby mode when the console is turned off, but also turning off completely and no longer trying to communicate with the console. Nowadays this is only possible by building in a switch into the gamepad.

 

[Arisotura]

I think we can work something out.

Post automatically merged: May 14, 2025

In the meantime, been starting RE work on that big intimidating chunk of hardware. So far:

Registers at 0xF0000800 are related to receiving picture data from the camera and storing it in memory. It's weird, it seems there are two possible buffers, and they go through different kinds of processing? Like, one is processed by another part of the hardware, while the other seems mostly vanilla?

I've been able to receive and display picture data on the gamepad. It is YUV, but a weird NV12-like interleaved format. You get 16 bytes of Y values for one row, 16 bytes of Y values for the next row (apparently), then 8 bytes of U values and 8 bytes of V values. Essentially, for each U/V value pair you get 4 Y values.

This tells us that the h264 codec is separate from the camera hardware, which is nice.

I'm still working out the kinks in the chain... I collected settings from pomelopad emulating the service firmware, but they're off -- with them, I only receive the upper half of the picture, repeated twice. I found that it's because the camera clock is set for 30FPS, but the camera VBLANK signal seems to be supplied by the SoC (and not generated by the camera) -- at 60FPS. Doubling the camera clock gives me a full picture but with weird colors. Halving the LCD pixel clock seems to also halve the generated VSYNC frequency, giving me a full picture of decent quality. I still have to figure out how this is supposed to work...

Registers at 0xF0008400 seem to be the h264 codec. This hardware component can be configured with start and end addresses for a memory buffer, and when the camera is active, it will continuously write data to the buffer -- presumably, a h264 bitstream. No idea yet how that would work (like, how to turn the data into something usable).

Registers at 0xF0008C00 and 0xF0009000 are also related to the camera function.

 

[Arisotura]

Long time no status update... I needed to take a break from banging my head at camera/h264 stuff. I will need to upgrade my gamepad emulator to make any progress in understanding that stuff.

Also, mental health. I'm looking for a job. It sucks.

I need to really clean up my emulator codebase, because it's a mess right now, and there's a ton of uncommitted shit.

 

[Arisotura]

Hey hey, sorry for the silence here... been focusing on other things (like melonDS)...

Anyway, it seems that there's a bit of interest in gamepad homebrew/development, especially with the new UART stuff, so that's nice.

There was the idea of a simple app that could be loaded over UART and allow changing a gamepad's region, maybe even uploading a different language pack (that you'd have to get from Nintendo's servers)...

I'll keep you informed whenever I find time and motivation for this. It could also serve as a bit of a practical example of programming for the gamepad.

 

[Jayro]

Hey hey, sorry for the silence here... been focusing on other things (like melonDS)...

Anyway, it seems that there's a bit of interest in gamepad homebrew/development, especially with the new UART stuff, so that's nice.

There was the idea of a simple app that could be loaded over UART and allow changing a gamepad's region, maybe even uploading a different language pack (that you'd have to get from Nintendo's servers)...

I'll keep you informed whenever I find time and motivation for this. It could also serve as a bit of a practical example of programming for the gamepad.

What kind of processing power is inside the gamepad? I'm assuming it's just some kind of high-bandwidth microcontroller for receiving 720p signals to the screen and audio clips/sound effects over a 2.4GHz receiver. I'm just curious if it's powerful enough to say, run emulators like Game Boy or NES without the Wii U.

 

[Arisotura]

It's an ARM9 CPU that runs at 108 MHz, with 4 MB of RAM. As far as graphics are concerned, you get a H264 codec and 2D blit DMA. The wifi card is 5 GHz.

I think emulating the GameBoy or NES would be feasible. I kinda want to try SNES, but I'm not sure it can pull that off.

 

[Jayro]

It's an ARM9 CPU that runs at 108 MHz, with 4 MB of RAM. As far as graphics are concerned, you get a H264 codec and 2D blit DMA. The wifi card is 5 GHz.

I think emulating the GameBoy or NES would be feasible. I kinda want to try SNES, but I'm not sure it can pull that off.

Ah, the 5GHz makes sense for bandwidth reasons, and also makes sense as to why the gamepad has to be so close to the system.

 

[zal16]

Wow! 108MHz? That's almost the frequency of a DSi (who also has an ARM9 CPU). What can you do with that power? I'm curious how far this goes.

It's an ARM9 CPU that runs at 108 MHz, with 4 MB of RAM. As far as graphics are concerned, you get a H264 codec and 2D blit DMA. The wifi card is 5 GHz.

I think emulating the GameBoy or NES would be feasible. I kinda want to try SNES, but I'm not sure it can pull that off.

 

[awesomeee]

I think emulating the GameBoy or NES would be feasible. I kinda want to try SNES, but I'm not sure it can pull that off.

I actually do own some VC games from the 3DS / Wii U shop so it could be fun to try, but if you ever do, Consider do whatever is easiest to work on / you want to do more

Of course it’s ultimately your development choices but starting with a simpler one could be a solid start.

 

[zal16]

It's an ARM9 CPU that runs at 108 MHz, with 4 MB of RAM. As far as graphics are concerned, you get a H264 codec and 2D blit DMA. The wifi card is 5 GHz.

I think emulating the GameBoy or NES would be feasible. I kinda want to try SNES, but I'm not sure it can pull that off.

DSi is sightly faster but don't capable to do SNES emulation, even old 3DS too.

 

[Arisotura]

I did have some SNES emulation going on old3DS (blargSNES...) but yeah. graphics are the main bottleneck, and the gamepad doesn't have much for acceleration.

I still think it'd be nifty to get some emulator going, but idk.

 

[Arisotura]

heh...

I was thinking of project ideas for the gamepad, and felt like trying to figure out what it'd take to run my own code on the wifi card's CPU (to use it for my own purposes)

what I've found so far:

the CRC check is part of the wifi firmware itself. it's at 0x34EEC. it's possible to disable it entirely (by patching out the call to that function).

there is a 128KB ROM at 0x800000, which contains a common function set (calculating keys, etc...). it's not possible to access it via SDIO F1. however, by patching the firmware, I was able to convince the wifi card to give out its ROM.

there are more shenanigans with the addressing, probably a MMU going on. however, a lot of the address space seems to match what is exposed through SDIO F1, ie. RAM is at 0x0, general and per-core registers are found at 0x18000000, ...

what I'd need to figure out is how to get the SDIO device core up and running, and ideally how to use the F2 FIFO. then I could do fun shit.

 

[Arisotura]

status update:

managed to get my own code running on the wifi card's CPU. I still need to iron out issues in the initialization sequence, because for some reason the CPU is running super slow, and I haven't yet figured out why.

I'm able to send shit to the main CPU via the mailbox registers. in order to receive, I'd need to work out the interrupt stuff and set up handlers and all...

I also know which registers to use for the F2 FIFO, in theory. haven't tried it yet tho. I'd also need to figure out how to bring up the whole F2 block in the first place...

muhahahahah

 

[Arisotura]

A little demo of the work in progress...

So far:

This is a frankenstein mix of lolSNES and blargSNES. It's running CPU and APU emulation. The demo in the video also renders one 4bpp BG layer, all on the ARM9, as a test. CPU usage hovers around 50%, which is honestly a decent starting point.

The ARM9 has better performance than the wifi CPU (Cortex-M3). Not only is it a tad faster (108MHz vs 90MHz), it also has caches, and the wifi CPU doesn't.

There is also room for optimization on the CPU/SPC700 front: the gamepad's ARM9 has a MMU, which could be very handy for fastmem purposes. Maybe we could even get a basic type of JIT going...

As far as PPU emulation is concerned, neither of our CPUs will be able to handle the load alone, but they can share the load, something like 50/50 could work well.

The output looks tiny on the gamepad's screen. It's 256x224. I plan on making it bigger, the screen could fit 2x the resolution perfectly. We'll see if I can do this without too much performance penalty... I might even use DMA to do it. We've seen the gamepad has pretty fast DMA...

-

This is intended to be a little demo of what the gamepad can do (and a fun challenge). Not terribly user-friendly as the ROM needs to be written to FLASH memory somehow...

But who knows, it might also give me ideas for lolSNES. A while ago I had tried seeing if I could make an improved version for the DSi, leveraging the DSP to do rendering. Similarly, the DSP there isn't powerful enough to render a full screen, but a similar load balancing scheme might work too.

Thing is, the DSi's ARM9 doesn't have a MMU, and the memory bus is slow. However, we do have the ability to use the ARM7 to emulate the APU, so there's that.

Then there's the fact the DS(i) screen can't quite fit the SNES video output entirely...

 

[Tur7L3]

A little demo of the work in progress...

View attachment 525717

So far:

This is a frankenstein mix of lolSNES and blargSNES. It's running CPU and APU emulation. The demo in the video also renders one 4bpp BG layer, all on the ARM9, as a test. CPU usage hovers around 50%, which is honestly a decent starting point.

The ARM9 has better performance than the wifi CPU (Cortex-M3). Not only is it a tad faster (108MHz vs 90MHz), it also has caches, and the wifi CPU doesn't.

There is also room for optimization on the CPU/SPC700 front: the gamepad's ARM9 has a MMU, which could be very handy for fastmem purposes. Maybe we could even get a basic type of JIT going...

As far as PPU emulation is concerned, neither of our CPUs will be able to handle the load alone, but they can share the load, something like 50/50 could work well.

The output looks tiny on the gamepad's screen. It's 256x224. I plan on making it bigger, the screen could fit 2x the resolution perfectly. We'll see if I can do this without too much performance penalty... I might even use DMA to do it. We've seen the gamepad has pretty fast DMA...

-

This is intended to be a little demo of what the gamepad can do (and a fun challenge). Not terribly user-friendly as the ROM needs to be written to FLASH memory somehow...

But who knows, it might also give me ideas for lolSNES. A while ago I had tried seeing if I could make an improved version for the DSi, leveraging the DSP to do rendering. Similarly, the DSP there isn't powerful enough to render a full screen, but a similar load balancing scheme might work too.

Thing is, the DSi's ARM9 doesn't have a MMU, and the memory bus is slow. However, we do have the ability to use the ARM7 to emulate the APU, so there's that.

Then there's the fact the DS(i) screen can't quite fit the SNES video output entirely...

Omg omg

 

[awesomeee]

This is an odd question but do you know if the GamePad’s network capability has IPv6 support?

I would assume it probably has IPv4 support since that’s more common and you showed it was able to connect to a network, but any idea for the IPv6 side of things?

 

[ben4shot]

hi, do you see possible to install something like Moonlight into the gamepad?
or allowing the wifi streaming?

 

[awesomeee]

hi, do you see possible to install something like Moonlight into the gamepad?
or allowing the wifi streaming?

They’re actually did say that would be a cool idea to try. No guarantees though since ultimately development is development after all.