[WIP] (WiiU) wut toolchain port/Aroma compatibility #14925
Conversation
|
Thank You VagueRant, FixGB FixNES are both current WiiU Cores ;) Their on the buildbot anyways :) |
|
I've edited all the makefiles with -mwup and added the new ffunction-sections -fdata-sections -D__wiiu__ -D__wut__ CFLAGS :) It'll have to be later tho it's late now and I'm shattered :P |
|
Do the non -mwup Cores need to be modified also? EDIT: |
|
I finished editing ALL the Cores from the list above with the new changes for Aroma. That took a while lol |
|
Had a discussion with @LibretroAdmin and we're going to try and restructure this so that the old and new buildtypes can coexist to some extent. The goal is still to replace the old toolset eventually but this way we can merge it even with issues remaining and leverage the libretro CI to track progress and make test builds available. Hopefully with wider testing and more eyes we can work out what's going on with e.g. the very long reported loadtimes. |
Brilliant, saves me manually compiling all the cores :) There were a handful of cores that failed to compile with the new wut changes but they can be tackled as they show up on the CI test builds? |
|
Is this still being worked on? |
|
@DaveyL2013 Probably not right this instant due to other projects, but it's not abandoned. |
|
Hi there :) been a while I just for fun tried a couple of the Aroma Cores and I think I may have stumbled onto something.... But how can that be it was soo slow before.. and confirmed by others too? I've only tried this a couple times and maybe it's something else entirely, but could someone else give it a try and confirm? and if you attempt to quit RA it will just stay loading and not go back to the wiiu menu (perhaps if I left it long enough it would have loaded back to the wiiu menu?) The path defaulting may happen when switching to another core? I seemed to be able to load a few games one after another when using the same core. Hopefully this is something trivial and can be fixed easily so this can finally be merged :P
EDIT4: The damn SNES CORE!! the Snes Core is messing up things.. As long as I stay away from it I can switch cores fine.. EVEN THROUGH RETROARCH!!! well that's it.. the Aroma port works :D the slow loading must have been to do with Aroma CFW and it must have been fixed over the last year? dunno.. strange. |
== DETAILS serial debug and some testing revealed that the cause of the lockup on exit was because of a deadlock in the HID i/o thread. solution: explicitly shutdown the HID thread during RetroArch termination process.
This commit is enough to compile RetroArch using wut and more modern versions of devkitPPC. Among the requisite ports and bugfixes, the wiiu code has been switched to use wut's headers (where possible). There's a handful of headers where RA's are more precise, and these have been put into the `wiiu/include/` hierarchy mirroring WUT's folder structure, but with `ra_` prepended to the filename to avoid include directory priority fighting. Other changes are related to the header changes: - update defines to use WUT's new definition - replace custom integer types with standard ones (eg u8 -> uint8_t) - remove some workarounds/hacks in favor of more precise handling in WUT. Cut features that will be re-added later: - Current rpx symbol names in the exception handler - somemopt networking optimisations - Core loading - libfat support - always uses fs:/vol/external01 (WiiU) memory: handle being in the background properly Quitting on Aroma works a little differently to HBL - we need to use a ProcUI loop and go into the background before quitting. This patch prepares the MEM1 and bucket allocators so they won't crash when this happens. (WiiU) aroma: fix conflict with FTPiiU plug-in == DETAILS The HID polling thread was written to be run on a single core, and basically completely occupies it, not allowing any other threads to run on it. It turns out, this is a problem in Aroma, because other things can be running on your cores. For instance, the FTPiiU server thread runs on the same core as the HID polling thread, which explains why FTPiiU stopped working when RetroArch was running. The other problem, is that if FTPiiU is holding the IPC BufPool mutex when RA is started, a deadlock will eventually happen because RA will try to acquire the mutex and the FTPii thread, being suspended, won't be able to release it. So! To fix it: - add a 500-microsecond sleep to the HID polling thread - update to WUT's HID headers, which makes some minor changes to structure member names
subrepo: subdir: "deps/libmocha" merged: "630d9681bc" upstream: origin: "https://github.com/wiiu-env/libmocha" branch: "main" commit: "630d9681bc" git-subrepo: version: "0.4.6" origin: "https://github.com/ingydotnet/git-subrepo" commit: "73a0129"
Users need to be running an updated Tiramisu or Aroma, otherwise we'll fall back to the standard wut devoptab. Since Aroma ships with plugins that keep the SD card mounted all the time, we have some restrictions: - On Tiramisu, use libfat for the USB and SD card - On Aroma, use libfat for the USB only - stock devoptab for SD card This makes loading on aroma preeeettty slow.
This commit re-adds core loading support, now compatible with Tiramisu and Aroma; using a libmocha feature added in those CFWs. Note that this does NOT work under Haxchi FW, non-payload Mocha versions, etc. RetroArch now requires either Tiramisu or Aroma on Wii U. The overall strategy is to make the path of the core to be loaded relative to the SD card root, pass this off to Mocha, then switch titles to the wrapper title (usually Health and Safety). In order to pass arguments, sysapp is used, with a little extra logic (since sysapp passes a blob of arbitrary bytes) to emulate argc/argv.
|
Rebased onto current RetroArch. |
|
Docker build container updated: https://git.libretro.com/quarky/libretro-build-wiiu/-/commit/6c95d67e2ec5ee73f4a4564a2ff81dffb14ef275 |
ashquarky
force-pushed
the
wiiu-wut-merge
branch
2 times, most recently
from
374c2a8 to
892b0ce
Compare
|
That last change changes how RA is packaged, in exchange for greatly improved load times on Aroma, so I'll quickly go over that.
This does mean that users can't "directly" boot a desired core from the menu, instead going via Salamander and their last-used core, but the core switching speed should be fast enough now that this isn't a big problem. This also sets us up for a potential future where cores are dynamically-linked .rpls, which will practically eliminate load times altogether by putting all the menu code into Salamander. |
Implements support for the Wii U's HOME button menu (HBM). This fixes various "OS integration" warts (like powering off the console). Now that the HOME button is used for HBM, change the menu bind to Start+Select. Various changes are also required for backgrounding support. Co-developed-by: Maschell <[email protected]>
Users who prefer the old legacy behaviour of the Home button opening the RetroArch menu, they can disable the HBM here.
These assets are shared to the cores after core switch. Reading them out of a .wuhb is an Aroma-exclusive feature that makes core loading times dramatically better. Branding assets provided by @Ploggy, originally by cucholix afaik. Co-developed-by: Maschell <[email protected]>
ashquarky
force-pushed
the
wiiu-wut-merge
branch
from
892b0ce to
4405bc4
Compare
|
Adding ProcUI/HBM support brings RetroArch in line with official Wii U software as well as all Aroma homebrew. It does create a conflict over the HOME button - it now opens the OS's built in HOME menu overlay rather than the RetroArch menu. To smooth this over, the RetroArch menu is opened alongside the HOME menu so users can access it when they return, and the default "open menu" binding is changed to Start+Select, as it is on the Switch. |
Some users like to use native-format drives to store their data alongside Wii U games. Use libmocha to support this. Note Mocha_MountFS claims success even if the mounted folder doesn't exist. Since Salamander only has a "minimal" version of libmocha without the MountFS functionality, undefine HAVE_LIBMOCHA in that build. Users may want to build without MountFS but can't reasonably build without RPX loading.
ashquarky
force-pushed
the
wiiu-wut-merge
branch
from
5f6d7a8 to
b138a74
Compare
|
Does anyone know where https://docs.libretro.com/development/retroarch/compilation/wiiu/ are written up? In Git somewhere? I may have to update them if this merges due to the new toolchain |
https://github.com/libretro/docs/blob/master/docs/development/retroarch/compilation/wiiu.md |
Description
This PR ports RetroArch to the wut toolchain, allowing it to be compiled with current devkitPPC tooling. It also changes the core loading and filesystems such that they are compatible with Aroma.
There are a few user-visible changes resulting from this, besides the Aroma compatibility:
__init_wut_socket; such changes are not included in this PR.sd:/, while on Aroma it'sfs:/vol/external01. Users switching between Tiramisu and Aroma may have issues with their config file resulting from this difference.Moving to wut should put RetroArch in a much stronger position for its long-term maintainability, since fixes to the Cafe bindings, stock Cafe devoptab, and networking compatibility will no longer have to be applied to RetroArch specifically, and can instead be adopted through wut updates. In addition, new features should be possible, such as multithreading (wut provides c11 threads) and dynamic core loading. Cores can also access the Cafe API in the standard way for homebrew, rather than being required to copy headers ad-hoc into their own source trees.
Related Issues
#14429
Related Pull Requests
The related PRs are the primary reason this is still a draft.
Cores
Due to the removal of
-mwupin newer devkitPPC tools, many of the core makefiles need to be changed.-mwupis directly equivalent to-D__wiiu__ -DHW_WUP -ffunction-sections -fdata-sections; though usually the defines can be tweaked a bit. Still need to decide whether-D__wut__or similar is worth including.Every core built for wiiu that currently uses
-mwupwill need to be fixed before merge.Toolchain
There's a new docker container drafted up here: https://git.libretro.com/quarky/libretro-build-wiiu/-/tree/wut
I've not filed a PR for this yet (I think I have push access to the real libretro-build-wiiu anyway...). The toolchain container will need to be live for the same set of nightlies as this PR's merge - the new tools can't build old RetroArch, and the old tools can't build wut RetroArch. Woohoo!
Reviewers
@LibretroAdmin
@gblues (gblues is a co-author of several of the patches submitted here, massive props!)
@Maschell (in case you have comment on the libfat situation)