Homebrew Official Retroarch WiiU (wip.)

[azy77]

Thanks guys. Managed to get it all working.

As september796 said, it's a case of being careful which files are copied over from a previous RA installation. Here's what worked for me in case it helps anyone else with similar issues:

1) With your SD card in your PC, backup your existing Retroarch folder somewhere on your PC
2) Delete all Retroarch files and folders from the SD card (SD\retroarch) (SD\wiiu\apps\retroarch.wubh)
3) Copy the latest Retroarch build onto the SD card and then put the SD card back into the Wii U
4) Fire up the Wii U and open Retroarch. This will generate a config file and allow you to test that the basic build is working
5) Power off the Wii U, remove the SD card and put it back into your PC
6) Copy any roms, savestates and remap files from your previous Retroarch folder to the new one on the SD card. DO NOT copy any cores (although you can copy savestates and remaps from the "cores" folder)
7) Put the SD card back into the Wii U, fire up Retroarch

Hopefully, everything should work fine. You might have to set some stuff up manually again but it should all at least work.

The only issue I'm having now is that I sometimes can't save/load core options files from within Retroarch. Not sure what's going wrong, but... at least the games are running and the savestates are working.

I do a bit of programming in my spare time, I'd be happy to help get Retroarch working properly in Aroma depending on what the issues are holding it back from a fully stable Aroma-ready release.

All this time I just copied the new cores over to the old build, but now followed the 7 step process here and I can see a further significant improvement in the overall speed of Retroarch.

The only core that still takes a bit of time to load is Vice X64 (aprox 30 secs) all others like ps1, mame, snes, amiga load the game in like 10 secs from selecting on playlist.

Also got shadow of beast 3 running fullspeed on Amiga by selecting a res of 360p (it was auto using 720p which was what caused slowdowns) so no need for for threaded video anymore.

And Pcsx Rearmed is running everything full speed with the core cpu speed setting bumped from 57 to 100. In the last build there would be a lot of slowdown with cpu at 100.

Big milestone achieved, well done for the hard work of all the team.



Edit: "The only issue I'm having now is that I sometimes can't save/load core options files from within Retroarch. Not sure what's going wrong, but... at least the games are running and the savestates are working"

@Willicious I had that issue where save states, .srm files and game options from old build weren't being loaded in the new build then I could see the folder structure changed slightly in the new build where each core had it's own new folder within the saves and save states folder so I transferred the old options and save states files into the newly created folders and they are working fine now.

 

[september796]

I found another thing: while using RA, if you press the power button, the console shuts down without needing to select 'Exit' or 'Load/Close Content' from the menu unlike before. However, the problem is that it takes like 10 minutes (!!) while the menu is frozen. And when it finally shuts down, the GamePad remains on, showing a 'connection lost' message instead of powering off properly with the console as it should. It's like it temporarily desync. So, if you try turning the console back on using the GamePad’s power button, it fails and displays a connection error. You have to press the power button on the console itself to restore the connection.

 

[Willicious]

I'm getting alot of conflicts when I try to merge my repo with the new upstream changes :/

Merging conflicts generally depends on which code needs to be kept.

For example, if you're seeing this:

<<<<<< HEAD
    code A
======
    code B
>>>>>> upstream/master

Assuming your project is set up the usual way, "code A" is your local working copy and "code B" is the upstream version. To resolve the conflict, choose which needs to be kept and delete the other.

So, to keep "code A", you'd delete the following lines:

<<<<<< HEAD <----- delete this line
    code A
====== <----- delete this line
    code B <----- delete this line (or these lines, if there are multiple)
>>>>>> upstream/master <----- delete this line

To keep "code B", you'd delete the following lines:

<<<<<< HEAD <----- delete this line
    code A <----- delete this line (or these lines, if there are multiple)
====== <----- delete this line
    code B
>>>>>> upstream/master <----- delete this line

Which code to keep depends on which is correct for the current working copy. I've resolved the conflicts you sent over, but as I don't have a way to test the project I've resolved both versions: one that keeps the working copy changes, and the other that keeps the upstream stuff. You'll need to copy whichever is correct into your project, and the conflicts should be resolved.

If the conflicts re-appear when you try to merge after pasting these in, paste them in again at that point and it should resolve the conflicts on-the-fly.

Post automatically merged: May 8, 2025

I had that issue where save states, .srm files and game options from old build weren't being loaded in the new build then I could see the folder structure changed slightly in the new build where each core had it's own new folder within the saves and save states folder so I transferred the old options and save states files into the newly created folders and they are working fine now.

Thanks for this, I'll take a look and see if I can figure out how the new file structure works.

 

[ploggy]

Merging conflicts generally depends on which code needs to be kept.

For example, if you're seeing this:

<<<<<< HEAD
    code A
======
    code B
>>>>>> upstream/master

Assuming your project is set up the usual way, "code A" is your local working copy and "code B" is the upstream version. To resolve the conflict, choose which needs to be kept and delete the other.

So, to keep "code A", you'd delete the following lines:

<<<<<< HEAD <----- delete this line
    code A
====== <----- delete this line
    code B <----- delete this line (or these lines, if there are multiple)
>>>>>> upstream/master <----- delete this line

To keep "code B", you'd delete the following lines:

<<<<<< HEAD <----- delete this line
    code A <----- delete this line (or these lines, if there are multiple)
====== <----- delete this line
    code B
>>>>>> upstream/master <----- delete this line

Which code to keep depends on which is correct for the current working copy. I've resolved the conflicts you sent over, but as I don't have a way to test the project I've resolved both versions: one that keeps the working copy changes, and the other that keeps the upstream stuff. You'll need to copy whichever is correct into your project, and the conflicts should be resolved.

If the conflicts re-appear when you try to merge after pasting these in, paste them in again at that point and it should resolve the conflicts on-the-fly.

Post automatically merged: May 8, 2025

Thanks for this, I'll take a look and see if I can figure out how the new file structure works.

THANK YOU! your changes got rid of the conflict I had but I'm getting this error when compiling..

EDIT: This is with local changes kept. I need to keep the local changes since they are responsible for the Cores speed performance iirc.

 

[Willicious]

I'm getting this error when compiling..

That's a type mismatch. The program is expecting vout_update to return an integer, but it must be declared as "void" rather than "int" somewhere.

I need to keep the local changes since they are responsible for the Cores speed performance iirc.

In that case, whenever you get conflicts in future, delete the "<<<<<< HEAD" line, and then everything from "======" to ">>>>>> upstream/master" and that should resolve them.

Obviously double-check that it's correct before committing!

 

[ploggy]

That's a type mismatch. The program is expecting vout_update to return an integer, but it must be declared as "void" rather than "int" somewhere.


In that case, whenever you get conflicts in future, delete the "<<<<<< HEAD" line, and then everything from "======" to ">>>>>> upstream/master" and that should resolve them.

Obviously double-check that it's correct before committing!

hmm ok, I renamed the line void vout_update(void) to int vout_update(void) and that seemed to get me passed that error, but next I get an error in libretro.c:

 

[Willicious]

hmm ok, I renamed the line void vout_update(void) to int vout_update(void) and that seemed to get me passed that error, but next I get an error in libretro.c:

It looks like a lot of the variables are undeclared. Without having the project in front of me it's difficult to see exactly what's going wrong but my best guess is that the variables used here aren't declared in the upstream copy, so maybe merging the two (and/or resolving the conflicts) has somehow removed the declarations. I could have done it by mistake when resolving the conflicts tbh, I used a text editor and currently have no way to test the project or double-check the changes.

Best bet might be to go back to the conflicted version of this file and then resolve each conflict again, ensuring that the necessary declarations are kept (if this is indeed what's caused the error).

Where is the source located? I'll have a go at building/compiling at some point next week, then I might be able to help out a bit better.

 

[ploggy]

It looks like a lot of the variables are undeclared. Without having the project in front of me it's difficult to see exactly what's going wrong but my best guess is that the variables used here aren't declared in the upstream copy, so maybe merging the two (and/or resolving the conflicts) has somehow removed the declarations. I could have done it by mistake when resolving the conflicts tbh, I used a text editor and currently have no way to test the project or double-check the changes.

Best bet might be to go back to the conflicted version of this file and then resolve each conflict again, ensuring that the necessary declarations are kept (if this is indeed what's caused the error).

Where is the source located? I'll have a go at building/compiling at some point next week.

Heres my repo https://github.com/Ploggy/pcsx_rearmed
and this is what i'm trying to merge https://github.com/libretro/pcsx_rearmed

There's a guide in my sig to compile Retroarch WiiU, tho it's possible the docker file is outdated.?

Here is the newest docker. Use the guide in my sig with this docker, that should set you up.
and thank you for your help, If I can just get it to compile so we can have a pcsx build with the latest stuff from master that would be good enough for now

 

[MikeBeast12]

I see they had a Doom 1 & 2 emulation for the Wii U, which is Crispy Doom! Have they worked on PRBoom for the RA Aroma yet?

 

[ploggy]

I see they had a Doom 1 & 2 emulation for the Wii U, which is Crispy Doom! Have they worked on PRBoom for the RA Aroma yet?

Here you go.. Untested.

 

[UsernamesAreWeird]

Is there a channel version of the PSX core ?

 

[ploggy]

Is there a channel version of the PSX core ?

No the Core has to be loaded through Retroarch like the others.

 

[UsernamesAreWeird]

No the Core has to be loaded through Retroarch like the others.

...is there a channel version of retroarch then?

idk what Aroma is and I don't wanna switch over from tiramisu

 

[ploggy]

...is there a channel version of retroarch then?

idk what Aroma is and I don't wanna switch over from tiramisu

There is a Retroarch Launcher (Channel) for Tiramisu and one for Aroma, but each core is then loading from within Retroarch

Aroma is a newer CFW and successor to Tiramisu.
Currently the Tiramisu Retroarch is the official port and Aroma Retroarch is still WIP. but the plan eventually is to have Aroma become the official Retroarch port and retire Tiramisu Retroarch.

 

[UsernamesAreWeird]

There is a Retroarch Launcher (Channel) for Tiramisu and one for Aroma, but each core is then loading from within Retroarch

Aroma is a newer CFW and successor to Tiramisu.
Currently the Tiramisu Retroarch is the official port and Aroma Retroarch is still WIP. but the plan eventually is to have Aroma become the official Retroarch port and retire Tiramisu Retroarch.

I see, where can I find the launcher?

 

[ploggy]

I see, where can I find the launcher?

For Tiramisu? on the first page iirc, for Aroma in my sig there's a link to the latest WIP build.

 

[september796]

Here you go.. Untested.

works great, thanks!

 

[CrazyCaps]

Hey, I recently installed this in my Aroma modded Wii U and the emulation runs perfectly but I've had issues with Retro Achievements. When enabled, they cause games to choke a bit on boot up and while it shows the game and my achievement progress, no achievements actually unlock while I'm playing the game. Couldn't find anything else on the issue anywhere so I figured I'd ask about it here.

 

[ploggy]

Hey, I recently installed this in my Aroma modded Wii U and the emulation runs perfectly but I've had issues with Retro Achievements. When enabled, they cause games to choke a bit on boot up and while it shows the game and my achievement progress, no achievements actually unlock while I'm playing the game. Couldn't find anything else on the issue anywhere so I figured I'd ask about it here.

I don't really use Retro Achievements, I think I may have tried it a couple times years ago. I'd suggest trying it on Tiramisu to see if its any better/worse?

 

[nothor]

I've found another issues in the last build with the snes9x core.
1) The .ips files (rom patches like translations), it detects them correctly (popup shown by loading) but it crashes after loading the game.
Using the same files with the PC works as expected.
2) Support for snes mouse not working? I tried "Mario to Wario" and changed the controller to snes mouse but it's not detected (neither stylus nor gamepad controls)