Thanks, but if wasn't for gblues I'd still be crying in the corner somewhere lol (actually true )@ploggy good job man!
Thanks, but if wasn't for gblues I'd still be crying in the corner somewhere lol (actually true )@ploggy good job man!
Another new Core
REminiscene - Flashback - this Core needs:
The Flashback data files - Mandatory
Sound files from the Amiga version - Optional
Voice.vce from the Sega CD - Optional
- hot to setup
Tested and working!
(Load the Core then Load Content, navigate to your Flashback Data files then load the LEVEL1.LEV file)
Yeah Gblues really saved my sanityNice to see you got a hold of it with gblues help!
Perhaps a tutorial would help for others that might want to develop
Also, don't forget to add cores to the Makefile if they work properly!
Oh one more thing, can you test if PrBoom is crashing after some quick saves and quick loads?
I think that issue is carried across all platforms.
You know what other core used to be there too?Yeah Gblues really saved my sanity
I'll attempt a tut tomorrow after some kip, its pretty easy once you get the steps down
Sure I can test PrBoom
I'm slowly going through the list of Cores to see what can be compiled (and work) for WiiU, fMSX and Prosystem used to be on WiiU before the build bot change but Flashback is brand new!
Once I get through them I'll see if Autechre will add them to the build bot
I still have to post our issue list too I'll do that once I get through this PROGRESS!! lol
heheh, I tried it, fails to compile now, something about mmap.h errorsYou know what other core used to be there too?
Don't wanna say the name, but it ran at 6 fps lol
Thanks for testing!
And best of luck with your subsequent tests
Worth the shot lolheheh, I tried it, fails to compile now, something about mmap.h errors
$ readrpl -r retroarch_wiiu.rpx | grep REL24
025EBCF4 0000030A REL24 00000000 $UNDEF + 0
025EBD10 0000030A REL24 00000000 $UNDEF + 0
025EBD2C 0000030A REL24 00000000 $UNDEF + 0
025EBD60 0000030A REL24 00000000 $UNDEF + 0
025EBDA4 0000030A REL24 00000000 $UNDEF + 0
025EBDE8 0000030A REL24 00000000 $UNDEF + 0
025EBE14 0000030A REL24 00000000 $UNDEF + 0
025EBE28 0000030A REL24 00000000 $UNDEF + 0
025EBE44 0000030A REL24 00000000 $UNDEF + 0
025EBE60 0000030A REL24 00000000 $UNDEF + 0
025EBE7C 0000030A REL24 00000000 $UNDEF + 0
025EBE98 0000030A REL24 00000000 $UNDEF + 0
025EBEB4 0000030A REL24 00000000 $UNDEF + 0
025EBED0 0000030A REL24 00000000 $UNDEF + 0
025EBEE4 0000030A REL24 00000000 $UNDEF + 0
025EBF00 0000030A REL24 00000000 $UNDEF + 0
025F08B4 0000030A REL24 00000000 $UNDEF + 0
025F13B4 0000030A REL24 00000000 $UNDEF + 0
025F13D0 0000030A REL24 00000000 $UNDEF + 0
025F13EC 0000030A REL24 00000000 $UNDEF + 0
025F1408 0000030A REL24 00000000 $UNDEF + 0
Had a go at running a random build off the git head with the latest devkitPPC tooling, was able to replicate the system memory error. Luckily the console also made a log, which led me to this check in decaf, and after significant tomfoolery and chasing dead ends I ended up at this rather spicy output:
Code:$ readrpl -r retroarch_wiiu.rpx | grep REL24 025EBCF4 0000030A REL24 00000000 $UNDEF + 0 025EBD10 0000030A REL24 00000000 $UNDEF + 0 025EBD2C 0000030A REL24 00000000 $UNDEF + 0 025EBD60 0000030A REL24 00000000 $UNDEF + 0 025EBDA4 0000030A REL24 00000000 $UNDEF + 0 025EBDE8 0000030A REL24 00000000 $UNDEF + 0 025EBE14 0000030A REL24 00000000 $UNDEF + 0 025EBE28 0000030A REL24 00000000 $UNDEF + 0 025EBE44 0000030A REL24 00000000 $UNDEF + 0 025EBE60 0000030A REL24 00000000 $UNDEF + 0 025EBE7C 0000030A REL24 00000000 $UNDEF + 0 025EBE98 0000030A REL24 00000000 $UNDEF + 0 025EBEB4 0000030A REL24 00000000 $UNDEF + 0 025EBED0 0000030A REL24 00000000 $UNDEF + 0 025EBEE4 0000030A REL24 00000000 $UNDEF + 0 025EBF00 0000030A REL24 00000000 $UNDEF + 0 025F08B4 0000030A REL24 00000000 $UNDEF + 0 025F13B4 0000030A REL24 00000000 $UNDEF + 0 025F13D0 0000030A REL24 00000000 $UNDEF + 0 025F13EC 0000030A REL24 00000000 $UNDEF + 0 025F1408 0000030A REL24 00000000 $UNDEF + 0
Those addresses all belong to things like _exit, __gthread_once, __libc_lock_init (?), basically devkitPPC-internal stuff that has been added or tweaked in the 10 or so intervening releases. Usually you'd have this covered by a BSP like wut (exit/libc lock, gthread) but since RetroArch doesn't use wut these have slipped in unnoticed.
I have zero idea why RA even compiles with the latest tooling, I would have really expected missing stuff like this to throw a build error instead of spitting out invalid binaries (specifically, they include .dynsym sections instead of erroring out, which is totally nonsensical for the Wii U - even on PC it's questionable). Presumably RetroArch periodically finds broken or missing functionality even in the old tools, which would explain why some versions inexplicably give system memory errors - the actual binaries are broken.
In theory RetroArch could copy in the code for ghtread and things, but honestly between apparently silent errors like this, fixes that never made it into RA's ancient build, and the lack of a clear answer to "what happens another few devkitPPC releases from now" I would think RetroArch would be better off with a port to wut proper and doing away with the in-tree toolchain.
Benefits:What would it take for Retroarch to be updated to used the latest WUT toolchain?
What would be the benefits of updating to the new WUT apart from stability?
Would the SD card speed be better/faster (I remember there was updates to the SD card that allowed faster read/write speeds than the WiiU port currently has?)
I know the new Toolchain easily allows RWX which helps with JIT which in itself would be amazing
I know Aroma allows direct booting of Homebrew from the WiiU Menu as Channels, which also is Amazing! but again it would require Retroarch to be updated to use the new WUT..
So really what I'm getting at is would it be worth starting a Bounty or something to get Retroarch Updated with the new WUT Toolchain?
Benefits:
Downsides:
- If I diagnosed the 160-2203s correctly then the updated linkscripts and elf2rpl in wut should reduce or remove that issue
- Updated elf2rpl also supports compressed binaries, which should make rpxes a good deal smaller
- First step towards Aroma compatibility and .wuhb builds (there are still a few other things to do, notably argc/argv handling and ioctl100 for rpx loading, and on a more difficult note handling ProcUI and the home menu overlay)
- .wuhb can bundle files into the binary, so maybe we could include the menu assets and .info files? not 100% on how that'd interact with core loading but hey. I'm told accessing bundled files is much faster than reading SD even after optimisation (see the GTA3 port)
- I'm sure someone could write tools to put a rom in the .wuhb too and do your own virtual-console-y things
- ioctl100 (Aroma-exclusive) is a much, much nicer way to load RPXes and switch cores. it's not really a user-visible change but it makes me happy
- Aroma mucks with the cos.xml permissions to allow "easy" JIT (it still has the W^X thing I've discussed previously, but it's better than the HBL's "half of installations can't do JIT at all") - though personally I still think this should be added to the libretro API or libretro-common rather than handling it in the core
- (dreaming, this is very unlikely) wut can build custom .rpls and I've asked if Aroma can support loading them so maybe the wiiu port of RA could be the first non-static console platform - loading and unloading cores into one central RetroArch binary like on PC, rather than having each core be a standalone binary with menus and everything
- wut's socket devoptab makes networking a bit more standard, which could (but may not) improve netplay, though we won't know until we see it
- wut's filesystem devoptab is a bit more modern, which yes, should improve SD card speeds for large files and aligned buffers on non-iosuhax systems - it's also known to work properly with setvbuf which should guarantee ideal conditions for the speed boost - though it is possible to patch the same improvements into the existing RA code as I discussed previously, with a wut port you get it free
- I'm not sure if retroarch ever added an rthreads wrapper for wiiu, but wut also supports threading via std::thread and c11 threads, so in case retroarch doesn't have the wiiu-specific code already we should get that free and potentially make use of the three CPU cores instead of just one (depends on how effectively RA utilises that, though)
- Other minor things (compatibility with the latest devkitPPC release - newer compilers and better codegen, battle-tested Cafe headers should give more accurate structs, GX2 helper functions, wrappers for C++ libraries like nn::swkbd, etc.)
- As long as wut is maintained, it should be possible to build RetroArch against it with the latest devkitPPC release - would only face the usual Odd devkitPro Changes (like the int/long int thing) rather than arcane bugs like what I found here
I've been idly turning over doing something like this for a while now - Maschell wants me to so RetroArch can work under Aroma - so I'd be down to work on this, I've just been busy and other projects have taken up what time I do have at the mo (uni's in the final weeks). I dunno if bounties and me are a bit of a sensitive topic after I pushed so hard with the PSX one but, y'know, if y'all wanted to do one I'd take it, if nobody else did
- It could potentially be a lot of work, especially things like struct naming differences could wreak havoc in the GX2 driver
- HBL ELF builds would be goneski, we'd be RPX only even for non-Aroma users
- There's quite a few awkward points in the existing RetroArch code - things like the audio driver using AXMultiVoice, which is only mentioned on the internet inside Cemu changelogs and RetroArch itself. Things like that would either need to be added into wut (unlikely given the lack of independent documentation), workaround headers included in RetroArch (making wut updates a bit more difficult), or the audio driver changed to use a more standard API
- The main motivation (beyond stability) would be Aroma compatibility, which has a lot of unique features and incompatible APIs, so at some point the we'd have to talk about whether Aroma should be a hard requirement and drop support for HBL users too. at least initially it should be possible to support both though
- ProcUI support for Aroma would mean deciding between not using the HOME overlay, or mapping the RetroArch menu to something else (right stick? TV? not many options)
- Existing playlists and the like would probably break since the paths are all different (different devoptab). Something could potentially be done about this in libretro-common but I would have to ask
Should probably get an OK from someone who's been working on RetroArch a bit more regularly though, I know they've had issues with external toolchains before (libogc) so maybe they like having one in-tree. There are ways around it - they've copy-pasted the libogc source into RA, or you could use a submodule. Need a game plan, I s'pose.
I'm not sure what impact it'd have, since they still need to be decompressed, but it would be very cool to find out! xPlol yeah the with the current elf2rpl the WiiU Cores can be 12MB plus (even the smaller Cores) I would guess just reducing the Core size would reduce load times?
ioctl100 still loads RPXes in much the same way RA does now, it's just that the code to achieve that is muuuch cleaner. It's not really a killer feature, I probably didn't need to include it.. but yes, all RPX loading we have right now gets an RPX into memory, then restarts the current application (Mii Maker for HBL systems, Health & Safety for Aroma). It's about as quick as you could expect that process to be.Then there's the ioctl100 RPX loading thing you mention, that would provide the biggest reduction in load times? iirc the way the current RPX loader works on Retroarch means it reloads HBL to switch the Cores? (I may have misunderstood that tho)
Assuming we get RetroArch working under Aroma, then it should also work as a .wuhb!Building roms into a .wuhb so we can launch Retroarch roms directly from the WiiU Menu Virtual-Console style is a massive plus if possible, every other Console/Handheld port of Retroarch can do this iirc and is one of those missing features I think a lot of users would like to have.
It's not really related to any wut/toolchain-y things, and I'm not sure what the best way to handle it would be (on the DS, you can always show the game on one of the screens and dedicate the other to your keyboard, but on WiiU, people sometimes want to play on the Gamepad screen). I should have a peek at how they pull it off, though. my suspicion is that they just don't tell RetroArch about the secondary display and hide a separate keyboard somewhere in the console-specific code.I know I keep harping on about this but the ability to display different things on the TV and WiiU gamepad is a big missed opportunity in Retroarch, to be able to display say a Keyboard that can be interacted with on the Gamepad and an Emulator on the TV at the same time is something that can only be done on the WiiU and would be a great WiiU specific selling point
(actually the DS/3DS can technically do this too... just pretend they don't exist) or perhaps looking into how they did it would help? I dunno.
Gblues is the current WiiU dev with Retroarch but I don't know if he knows anything about Aroma?
I see, still the wut devotab stuff will still help a lot for SD speeds, which really is one of the biggest gripes with the current port.. That and the fact we can't have the gamepad and a pro controller be player 1 at the same time.ioctl100 still loads RPXes in much the same way RA does now, it's just that the code to achieve that is muuuch cleaner. It's not really a killer feature, I probably didn't need to include it.. but yes, all RPX loading we have right now gets an RPX into memory, then restarts the current application (Mii Maker for HBL systems, Health & Safety for Aroma). It's about as quick as you could expect that process to be.
I know but I couldn't help throwing it in there. Using the TV button as a toggle for Keyboard/standard could be an option?It's not really related to any wut/toolchain-y things, and I'm not sure what the best way to handle it would be (on the DS, you can always show the game on one of the screens and dedicate the other to your keyboard, but on WiiU, people sometimes want to play on the Gamepad screen). I should have a peek at how they pull it off, though. my suspicion is that they just don't tell RetroArch about the secondary display and hide a separate keyboard somewhere in the console-specific code.
He's a good guy, walked me through compiling wiiu with Docker so the guys got patience lolI was just thinking I should hop on the Discord and say hi to him!
Yes, the 4TU Discord is where most of the WiiU Dev folk hang out I'm looking forward to whatever you can do to update the WiiU RA portHi @ploggy and @QuarkTheAwesome. Catching up on recent comments, it sounds like the effort is worthwhile and doable. I'll have some time to revisit Wup & devkitpro modernization later this month (July 2021). I'd like to coordinate with the right folks. Is the best way to reach everyone to stay logged into discord?
Looking at recent comments, it sounds like the effort involves:
- Add dual devkitpro version support to 30+ makefiles: Need to support building cores with both devkitpro versions during migration. IIRC 20 or so cores use -mwup option which is required for older devkitpro versions, whereas -mwup will break builds using newer devkitpro version. Since each retroarch core has its own repo, retroarch makefiles need to support old and new devkitpro versions simultaneously until all core repos are fully upgraded to use devkipro >= r38. If we don't do this, the wiiu retroarch nightly builds will break.
- Modern WUP support : 30 or so cores build with WUP libs shipped with retroarch. Change these to use the WUP support shipped with modern devkitpro packages. Per @QuarkTheAwesome, even if the cores build with devkitpro >= r38 and package with older WUP toolchain, they won't run due to incompatibilities with old vs new WUP implementation.
- test, test, test - per re2, these cores will build with r38, but not launch until we use r38's built in WUP toolchain. Additionally, the base libraries and includes shipped with devkitpro have changed between r29 (current nightly environment) and r38 (latest build I tried). Simple things like paths and include flags will be easy, but if basics like networking api wrappers changed... TBD - check with @QuarkTheAwesome if his decaf patch was mainlined into retroarch for easy testing.
- fix unexpected breakages from 3.
- update official nightly build environment to use devkitpro >= r38
- cleanup (optional) - remove migration code from build scripts, remove wup libs from Retroarch repo, remove support for devkitpro < r38