Topic: FBAlpha on Wii ?

[yggdrasil31]

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 lacking 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...

[Haze]

depending on how limited you are for CPU power (on the Wii I guess you're already on the edge) you could in theory try some techniques like RLE compressing the tiles, with some kind of index and marker for blank tiles, that would squeeze you a bit of extra ram out but increase CPU cost at runtime.

that's why PGM and Suprnova for example have so many sprites with smaller rom sizes, because they've found techniques to compress the data rather than storing tiles with lots of wasted space.

Other techniques could involve flagging tiles / ranges of tiles as 1bpp/2bpp/3bpp if they only use a limited number of colours (although the index to say which colours could get bigger, but could be shared between tiles)

but yeah, there are various techniques which could be applied to the data after loading, and stored in some cache (or converted before putting it on the wii in the first place) which could in theory save you memory at the cost of CPU time involved in decompressing them on the fly.

audio is trickier as audio (de)compression techniques tend to be more computationally expensive and gains lower, especially when we're already talking about low qualtiy audio samples in the case of the Neo.

[Twinaphex]

depending on how limited you are for CPU power (on the Wii I guess you're already on the edge) you could in theory try some techniques like RLE compressing the tiles, with some kind of index and marker for blank tiles, that would squeeze you a bit of extra ram out but increase CPU cost at runtime.

that's why PGM and Suprnova for example have so many sprites with smaller rom sizes, because they've found techniques to compress the data rather than storing tiles with lots of wasted space.

The Wii CPU actually performs very well - to the point where the PS3/360 CPUs are only about 20% faster at best (Xenon/Cell being craptacular in-order CPUs that were advertised as being powerhouses vs. the Wii's modest out-of-order Broadway actually performing way better than what could have been expected). It definitely smokes the Xbox 1 as well - Virtua Racing on Genesis Plus GX runs at 42/45fps on RetroArch Xbox 1 vs. 60fps on RetroArch Wii, Super Street Fighter II Turbo Revival on VBA Next runs at 42/43fps on RetroArch Xbox 1 vs. 59/60fps on RetroArch Wii.

I believe these comparisons are as fair as could be possible since the emulator cores used are identical between the platforms and only the audio/video/input code differs per platform.

Anyway, even after having MEM1 and MEM2 in one shared memory pool, we can't really go beyond loading zipped 23/24+MB NeoGeo games - the cutoff point in terms of games is probably rbffspec.zip - this with a shrunk down FBA core that only contains code pertaining to Neogeo.

Any advice and a rundown on a virtual memory management implementation and the potential pitfalls would be most welcome - I hear iq_132 has some experience in that field.

[Twinaphex]

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).

[lantus]

oDD and myself (Surreal 64 authors) were the first to implement virtual memory management on the Xbox1. The first working version relied on C++ exceptions for memory access violations to be trapped and disk access to retreive the matching page on disk. It worked but it wasnt pretty. It was 'generic' though.

For FBA-X kev and i refined it a little on it. We decided to apply VMM to sprite ram *only*. The concept was simple:

- set up a simple LRU memory map and create a temporary 'pagefile' on disk which is a copy of Sprite memory used in FBA.
- replace the sprite memory malloc/free calls with a pagefile init and an open file pointer
- intercept and replace UBYTE/UWORD calls to Sprite ram with calls to the VMM manager.

those calls would simply determine if the page requested was in memory. return that, if not then fseek() to the position in Sprite ram on the pagefile and add that to the LRU algo and return that instead.

theres no reason you couldnt use this going forward on the Wii/Xbox1. I'm not sure how fast seek access time is on the Wii. on the Xbox1 sometimes theres a little stutter here and there as the disk is being seeked. Its not terrible but sometimes can be noticeable, especially on some of the larger roms.

I believe the code has been tweaked and reworked a bunch since then. Looking at some of the Xbox1 FBA-XXX videos it looks pretty smooth. I'm not sure about that codebase but if you were looking to implement it at least as a baseline check out FBA-X Beta 4 source (on Xbins). The files you are interested in are memdumper.cpp/.h and take a look at neo_decrypt.cpp and neo_run.cpp

[Haze]

The Wii CPU actually performs very well - to the point where the PS3/360 CPUs are only about 20% faster at best (Xenon/Cell being craptacular in-order CPUs that were advertised as being powerhouses vs. the Wii's modest out-of-order Broadway actually performing way better than what could have been expected). It definitely smokes the Xbox 1 as well - Virtua Racing on Genesis Plus GX runs at 42/45fps on RetroArch Xbox 1 vs. 60fps on RetroArch Wii, Super Street Fighter II Turbo Revival on VBA Next runs at 42/43fps on RetroArch Xbox 1 vs. 59/60fps on RetroArch Wii.

I believe these comparisons are as fair as could be possible since the emulator cores used are identical between the platforms and only the audio/video/input code differs per platform.

Anyway, even after having MEM1 and MEM2 in one shared memory pool, we can't really go beyond loading zipped 23/24+MB NeoGeo games - the cutoff point in terms of games is probably rbffspec.zip - this with a shrunk down FBA core that only contains code pertaining to Neogeo.

Any advice and a rundown on a virtual memory management implementation and the potential pitfalls would be most welcome - I hear iq_132 has some experience in that field.

Well yes, there would definitely be a cut-off point regardless, my suggestions were merely ways of possibly pushing what you could load keeping them in more compact formats without having to resort to actual virtual memory techniques, either way keeping things smaller will mean you have to hit the disk less often, you have to consider that the way the tiles are stored now is incredibly inefficient.  Such techniques might be the difference between a large game fitting in memory or not :-)

Of course that would be a significant change to the actual FBA code rather than just a port and for performance reasons you might even want people to prepare the better compressed .rom files on a PC first and load those directly because obviously a PC is a better platform on which to be loading the rom data and analysing how it could be better compressed while still remaining usable in realtime.

[yggdrasil31]

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.

thanks, this was exactly the information i was lacking as i didn't understand what salamander was in your design !

[Twinaphex]

oDD and myself (Surreal 64 authors) were the first to implement virtual memory management on the Xbox1. The first working version relied on C++ exceptions for memory access violations to be trapped and disk access to retreive the matching page on disk. It worked but it wasnt pretty. It was 'generic' though.

For FBA-X kev and i refined it a little on it. We decided to apply VMM to sprite ram *only*. The concept was simple:

- set up a simple LRU memory map and create a temporary 'pagefile' on disk which is a copy of Sprite memory used in FBA.
- replace the sprite memory malloc/free calls with a pagefile init and an open file pointer
- intercept and replace UBYTE/UWORD calls to Sprite ram with calls to the VMM manager.

those calls would simply determine if the page requested was in memory. return that, if not then fseek() to the position in Sprite ram on the pagefile and add that to the LRU algo and return that instead.

theres no reason you couldnt use this going forward on the Wii/Xbox1. I'm not sure how fast seek access time is on the Wii. on the Xbox1 sometimes theres a little stutter here and there as the disk is being seeked. Its not terrible but sometimes can be noticeable, especially on some of the larger roms.

I believe the code has been tweaked and reworked a bunch since then. Looking at some of the Xbox1 FBA-XXX videos it looks pretty smooth. I'm not sure about that codebase but if you were looking to implement it at least as a baseline check out FBA-X Beta 4 source (on Xbins). The files you are interested in are memdumper.cpp/.h and take a look at neo_decrypt.cpp and neo_run.cpp

Hi there Lantus,

thanks for the info - 'll definitely be checking out the FBA-X Beta 4 sources. I guess with Neogeo ROMs being the only really big ones with any kind of mainstream appeal (other than CPS3 I guess - which might not have been in FBA when you did the Xbox port), I could get by with just doing this targeted Neo-Geo driver sprite RAM hack and just making separate cores for the other systems that have big ROMs (but which are not as big as Neogeo ROMs and might still fit into RAM). It will be a maintenance nightmare though in the long run having to update all these separate cores whenever a new version of FBA gets released (such as now with 0.2.97.27). Perhaps the FBA team wants to pursue 'ifdef' compile-time options in a similar vein to Mednafen - such as 'WANT_CPS1', 'WANT_CPS2', 'WANT_NEOGEO' - to make it possible to optionally compile in a variety of drivers.

I'll also be updating FBA libretro to the latest version to go along with it and will provide the latest libretro patches again so they can be merged into FBA mainline.

[kev]

I believe the code has been tweaked and reworked a bunch since then. Looking at some of the Xbox1 FBA-XXX videos it looks pretty smooth. I'm not sure about that codebase but if you were looking to implement it at least as a baseline check out FBA-X Beta 4 source (on Xbins). The files you are interested in are memdumper.cpp/.h and take a look at neo_decrypt.cpp and neo_run.cpp

I miss FBA-X.

[lantus]

I miss FBA-X.

me too..those were the good old days

[LastCupOfSorrow]

Any reason I have code dumps every time I try to utilize cps1 or cps2 through wiiflow on vWii?

I can post a code dump screen by request.

All of my roms are zipped and in the correct cps1 and cps2 folders and my dols are in the correct retroarch-wii folder in my plugins folder. I have all needed bios in the correct folders and have tried setting cores manually while restarting retroarch with still, nothing but code dumps with an 8 second restart time.

I am just getting tired of having to get up and delete this config file every time just so I can get back into retroarch for it to do the same thing all over again, lol...

I have been messing with this for almost two entire days and about to give up. It is hard to find any FAQs or troubleshooting guides for this wii version...

I would greatly appreciate any assistance!

[LastCupOfSorrow]

Am I to understand that development has ceased?