thanks for your reply Twinaphex.
as much as i can remember, these 2 command lines generated libretro.a, not the .dol of the core
i managed to build the .a on my own some times ago, but i was laking a hint on how to generate the wii core as a .dol
is the .dol of the core retroarch itself, with the first dol we launch in the homebrew channel being just a frontend ?
what is the name of the frontend ? i saw some references to "salamander" in github ? is it its name ?
i suppose the frontend sends paramaters to the core to launch the proper game with the proper options. how is it done ? pushing data on the stack, or using registers ?
sorry for all these questions, but i'm very interested in all these aspects !
perhaps this forum is not the best place to talk about retroarch...
Hi there, I think I should explain to you how this works since I sense some confusion in your post -
The libretro port (FBACores CPS1/CPS2/Neo in this case) that gets compiled for the Wii is a static library (on the PC, a dynamic library gets made instead - we avoid that on consoles out of performance concerns since dynamic libraries are inherently slower than static ones).
Anyway, after compiling, you'll end up with a libretro_wii.a file.
What you need to do next is to grab yourself a copy of RetroArch's source. (doing a git clone for instance). After having done that, take the libretro_wii.a file and put it in the RetroArch source directory. Then, you need to issue the following commands:
make -f Makefile.wii.salamander clean pkg
This creates the bootloader for RetroArch Wii. This is a mandatory part of the compilation process.
After this, do -
make -f Makefile.wii clean pkg
This should compile all needed input files, create ELF files, convert them to DOL and put them in the gx/pkg directory. You can take those files (should be only three needed ones - boot.dol, CORE.dol and meta.xml), put them on your SD card, and then run RetroArch Wii from Homebrew Channel.
On startup, it will look at CORE.dol (which is the new emulator/game core you just compiled) - if it can be found, it will attempt to rename that executable to a saner filename based on the libretro port's 'name' (ie. a Genesis Plus GX libretro port would mean that CORE.self gets renamed to genesis_plus_gx.DOL'). If the filename already exists, then the RetroArch libretro manager assumes it needs to upgrade the core and it will do just that - overwriting the old one.
Anyway, this last procedure I described is all carried out automatically.
To boil down a long story - what we've done with libretro and RetroArch is decouple the emulator from the actual backend and made the emulators into pluggable libraries (on PC - on consoles they are static libraries that get turned into binary blobs combined with the RetroArch backend).