bbbradsmith / hatariB

Libretro core for Hatari emulation of Atari ST STE TT Falcon
GNU General Public License v2.0
20 stars 3 forks source link

Wii and Wii U builds #18

Closed bbbradsmith closed 7 months ago

bbbradsmith commented 1 year ago

I might be able to test this out with my Wii U since Tiramisu makes it easy to access. Should be able to try the virtual Wii homebrew too.

The libretro/hatari CI build should probably help understand how to compile: https://git.libretro.com/libretro/hatari/-/pipelines

The compiler toolchain is called DevKitPro: https://devkitpro.org/wiki/Getting_Started

Some of it seems like it should be similar in nature to the RPi builds, but it generates a static ELF instead of an SO. Because it's not a shared object, RetroArch actually switches total execution to the core, so building for these platforms involves including that subset of RetroArch needed to support the static core. Info:

bbbradsmith commented 7 months ago

After looking into this, I've decided I should not proceed at this point. I think it is possible for the Libretro organization to build Wii and Wii U cores with their build system, but I don't think I have access to what I need independently.

Issue 1: Can I build RetroArch for Wii U?

On the CI machine, using this build Script: build.yml

It got as far as linking, and then failed with many errors that look like it's trying to bind with a core that it hasn't been given. I couldn't find instructions about how to resolve this. As far as I know the makefile with no parameters should build the main application, not try to build a bound static core?

LD objs/wiiu/retroarch_wiiu.rpx.elf
/opt/devkitpro/devkitPPC/bin/../lib/gcc/powerpc-eabi/13.2.0/../../../../powerpc-eabi/bin/ld: objs/wiiu/runloop.o: in function `libretro_get_system_info':
runloop.c:(.text.libretro_get_system_info+0x80): undefined reference to `retro_set_environment'

On my local machine, it complained about not being able to find zlib. I tried HAVE_ZLIB=0 and then it complained about rzipstream_read_file, and I decided not to keep chasing this rabbit.

Issue 2: Can I built hatariB for Wii U?

This is unknown, I didn't get as far as trying. The SDL2 dependency may be a problem, but maybe Libretro has a special Wii U SDL2 that could be used.

If SDL2 can't be built, we might be able to reproduce the very small subset of SDL2 that is needed. I explained how to do this in DEVELOP.md but it just hasn't been worth the effort yet.

Otherwise I think the rest should be doable. Hatari and hatariB seem to run fine on various Arm architectures so far. As long as we can build the core into a library, we should be able to statically bind the core to a build of RetroArch. We need to be able to build RetroArch first, though.

Issue 3: Can we only support 1 specific version of RetroArch?

Because the Wii and Wii U RetroArch cores are actually a static combination of the core and the entire RetroArch application, we can't mix-and-match cores manually the way it works on other systems where they're a separate shared object of some form. It seems dangerous to just pick one version and hope users are able to use it.

Conclusion

I've got to put a pin in this, personally. It doesn't seem worth the effort at this point. If I could manage to build it locally I'd consider continuing, but where I got to I don't know if I'm 1 build test cycle away from getting there, or 100. The Actions runner seemed to get farther, but every build cycle is much slower when you don't have your hands on the machine.

I believe eventually if it becomes a Libretro core, we can support the Wii and Wii U through their official build system. The same goes for a number of other platforms, which I don't have suitable hardware to test with at this point.

However, if a contributor can resolve how to get the Github Actions CI build working here for this platform (or any other reasonable platform), please submit a PR and I'll add it. This build.yml from my test PR might get you started.