[WiiU] Possibility of a WiiU Port?

[Ploggy]

Would it be possible for this Core to come to the WiiU?

[Ploggy]

I've tried compiling it myself by copy/pasting a random build script from another WiiU Core but that didn't get very far before error's stopped the compilation.. Then I tried copy/pasting the build recipe as the other Sharp Core which allows me to get further through the compilation process but then I get this error...

x68k -I./fmgen -I./win32api -DC68K_NO_JUMP_TABLE -DLIBRETRO -fpermissive In file included from libretro/../m68000/c68k/c68k.h:35:0, from libretro/../m68000/m68000.h:17, from libretro/winx68k.cpp:16: libretro/../m68000/c68k/core.h:64:20: fatal error: gccore.h: No such file or directory

                ^

compilation terminated. Makefile.libretro:446: recipe for target 'libretro/winx68k.o' failed make: *** [libretro/winx68k.o] Error 1

I'm getting the feeling it's going to take more than just tweaking the build recipe to get it to compile :/

[gingerbeardman]

@Ploggy did you set up libretro-super to do the compile? Basically, following the compile guide?

[Ploggy]

I compile them manually. following this guide: https://gbatemp.net/threads/retroarch-wiiu-wip.447670/page-619#post-9451333 I can compile other Cores fine, actually I'll have to try and compile the other Sharp Core, see it throws the same type of errors :P

[Ploggy]

This is what I added to theMakefile.libretro..

Nintendo Wii U

else ifeq ($(platform), wiiu) TARGET := $(TARGET_NAME)_libretro_wiiu.a CC = $(DEVKITPPC)/bin/powerpc-eabi-gcc$(EXE_EXT) CXX = $(DEVKITPPC)/bin/powerpc-eabi-g++$(EXE_EXT) AR = $(DEVKITPPC)/bin/powerpc-eabi-ar$(EXE_EXT) FLAGS += -DGEKKO -mwup -mcpu=750 -meabi -mhard-float -DPOWERPC -Dppc -DWORDS_BIGENDIAN=1 -malign-natural FLAGS += -UINT32_TYPE -U UINT32_TYPE -DINT32_TYPE__=int -fsingle-precision-constant -mno-bit-align FLAGS += -DHAVE_STRTOUL -DBIGENDIAN=1 -DWIIU -DUNIX -DLINUX__ FLAGS += -DMSB_FIRST CFLAGS += -g -O2 CXXFLAGS += -g -O2 -fno-merge-constants BIGENDIAN=1 STATIC_LINKING = 1

It was taken from R-type's Xmil-libretro repo: https://github.com/r-type/xmil-libretro/blob/master/libretro/Makefile.libretro

Funny thing though the other Sharp Core wont compile either, so probably I'm missing something my end :P root@e140a7c373cd:~# make -f Makefile.libretro platform=wiiu make: *** No rule to make target '../vram/make15.o', needed by 'x1_libretro_wiiu.a'. Stop.

[Ploggy]

I've got a bit further.. I've managed to successfully compile the core by removing the "-DGEKKO" from the recipe.. If I try to boot a game (in this case Bubble Bobble) the Core boots to a Blackscreen BUT if I press one of the Controllers Triggers it displays a GUI Menu, which allows you to load a game on different FDD/HDD slots. All seems good but if I attempt to load a game the Core crashes :/

I do have an idea of why this happens but haven't got the skill to fix it. :D

This looks likes a similar issue that stopped MCD Emulation from working with Picodrive haha.

[gingerbeardman]

Jump on the discord and ask for help

[negativeExponent]

https://github.com/libretro/px68k-libretro/issues/49#issuecomment-342829634

[Ploggy]

Ahh... Funny enough it was @r-type that brought the X Millennium Sharp X1 emulator Core to the WiiU :p

[Ploggy]

Hi again, abit of progress has been made on this issue. LibretroAdmin has helped me get the Core to run on WiiU, we've got as far as fixing the seg fault I was getting when I try to change the game path from the Cores ui but now instead of a black screen when booting a game I get a screen of Blue lines which suggests the game is now booting something at least :)

@TurtleBazooka do you have any idea why the graphics are messed like that? could it be due to more endian patches being needed? You can see the changes made here https://github.com/libretro/px68k-libretro/commits/master

Thanks :)

[TurtleBazooka]

Hi. thanks for calling.

＞when booting a game I get a screen of Blue lines oh! it's great! :-o

I try to run on PowerMac on same CPU archtecture. (WiiU -- PowerPC 32bit CPU used, )

but.... RUN on BLACK Screen yet. (booting Human68k) I see source code, mem_wrap.c , and c68k.c, and the others .

think revert little-endianess to big-endianess,, there will be something oversight.

[Ploggy]

Bit more info, I've tried different file formats and so far all seem to display the same blue bars. But I noticed that I change the cpu speed core option and restart the core/game I can change the length of the blue bars.. higher the cpu speed the longer the blue bars :P I'm not sure if that's helpful to you , but so far its the only thing that I have done that changes the output. It's hard to see from the screenshots but if you compare my last shot to this one you can see the lines separating the bars.

[negativeExponent]

x68000 is suppose to run in big endian mode. portions of data read/writes take that in mind (those ^ 1) but some data do not account for it (like crtc regs)

this appears to be an issue as well since both code will output the same value;

#ifdef MSB_FIRST
#define GET_WORD_W8(src) (*(uint16_t *)(src))
#else
#define GET_WORD_W8(src) (*(uint8_t *)(src) | *((uint8_t *)(src) + 1) << 8)
#endif

is this correct in MSB?

also not really sure how BE compatible the C68K core is... you may want to try the musashi cpu core instead

[negativeExponent]

im willing to coordinate if anyone is able to work/compile this on WiiU/BigEndian devices/system.