Topic: FBAlpha on Wii ?

[yggdrasil31]

Hi,

looking at the forum, it doesn't seem to have a lot people trying to port FBAlpha to the Wii.
I would be interested into trying to do it, although i don't have a lot of time. I own a hacked Wii, i'm an embedded software C developper, but i know little about Wii programming (i've installed devkitpro yesterday and managed to compile the examples)

Is there something that would technically kill my efforts ? (except RAM size and CPU power, but FinalBurn should be lighter than mame i think. I agree that big roms will take to much memory and crash the Wii whatever the emulator you use )
Are the big endian patches already merged into the project trunk ?

Looking forward to your answers

[lantus]

Big endian patches are merged into trunk yes. Theres no reason why you cant create a workable binary

good luck!

[yggdrasil31]

i've started to work a little on the makefile.
i've added a makefile.wii based on the makefile.mingw.
I managed to make it uses powerpc-eabi-gcc from my devkitpro setup, so dependency building is starting, but terminates quickly, as you could imagine 

the process begins with d_dodonpachi.cpp from the "burn" sub project
- at first tchar.h was missing, so i copy it from another directory
- now it is burn_endian.h that is missing. It seems to be present in \src\burner\libsnes (from the burner subproject). burn_endian.h make some reference to the WII through "IFDEF". In your opinion, where is the best place to put those defines ? I don't want to break the directory structure or change too much the makefile
- since i understand nothing to the gamelist building things in perl
- and perhaps one day the wii target can be added to the main line (if somebody succeed this port)
Can someone explain me why libsnes is the only build that uses burn_endian.h ? is it a file that is only added for big endian plateform ?

from what i understand "burn" is the core emulation, and "burner" is the user interface. Is that it ?
is there a document that explains the design of the emulator (or at least, what are software modules meant at) ?

[kev]

i've started to work a little on the makefile.
i've added a makefile.wii based on the makefile.mingw.
I managed to make it uses powerpc-eabi-gcc from my devkitpro setup, so dependency building is starting, but terminates quickly, as you could imagine 

the process begins with d_dodonpachi.cpp from the "burn" sub project
- at first tchar.h was missing, so i copy it from another directory
- now it is burn_endian.h that is missing. It seems to be present in \src\burner\libsnes (from the burner subproject). burn_endian.h make some reference to the WII through "IFDEF". In your opinion, where is the best place to put those defines ? I don't want to break the directory structure or change too much the makefile
- since i understand nothing to the gamelist building things in perl
- and perhaps one day the wii target can be added to the main line (if somebody succeed this port)
Can someone explain me why libsnes is the only build that uses burn_endian.h ? is it a file that is only added for big endian plateform ?

from what i understand "burn" is the core emulation, and "burner" is the user interface. Is that it ?
is there a document that explains the design of the emulator (or at least, what are software modules meant at) ?

Libsnes (now retroarch) is the only big endian target in the main source tree but there are others on the net in various places.
You'd be better off downloading the whole of libretro from here to see how that works: http://www.libretro.org/
Alternatively, take a look at the 360/ps3 standalone ports or the iOS port to see how a non libretro port could be made.

the game list building script generates a header file to save typing it in for the 1000 * x number of drivers that are in FBA.

You will probably need a specific makefile for wii. In the mainline there are at least 2 specific makefiles for different windows compliers so adding one for wii is probably the best way.

Also there is no design. At this point FBA is older than I care to imagine (I think I was a teenager when I started working on it and i'm now in my 30's and pretty much have no hair left) and most of the internal bits have never been really documented. Having said that it is pretty easy to follow (for the most part) and is quite portable when you get the hang of it.

[yggdrasil31]

when trying to connect to https://code.google.com/p/fba360/
(xbox 360 and ps3 port) i got :

"403. That’s an error.

Your client does not have permission to get URL /p/fba360/ from this server. That’s all we know. "

is it the same for you ?

[yggdrasil31]

I had a look into retrolib and retroarch
Very interesting design, indeed. Furthermore, There is a preliminary port for the wii.
I will try to build it as soon as i get the time to test it. PS3 and Xbox ports of retroarch seem to be near completed.
The wii developments seem to be active as there have ben some commits a few days ago.
I hope i'll be able to play toki and final fight on my wii soon !

[yggdrasil31]

yeah, this morning i managed to compile libretro-wii.a (the one with the fba core)
but it is 33MB big... i shall remove console things, since it is big for a wii. How many bytes may that operation frees ?
Perhaps, i shall also play with gcc optimizations.

to be continued...

[iq_132]

I would greatly suggest removing the Megadrive driver. It is massive.  Maybe rip out PCE if you still need space. 
One of the tricks you're probably going to have to use with the Wii's limited ram is a VMM (I'm not sure how fast reading from an SD card is, but the lack of seeking should help with speeds).

[Twinaphex]

Hi there,

FBA runs on Wii fine with libretro / RetroArch Wii - HOWEVER - the limited amount of RAM on the Wii is definitely a problem (according to posts by seasoned Wii devs, you can only assume 45MB RAM will be free and available for your app - so that's a very tight squeeze).

Therefore, I've decided to do something a little different for my own fork on Github -

FBA Cores

https://github.com/libretro/fba-libretro

Basically, create separate versions of FBA that are meant to play games for only one specific arcade hardware system.

Right now, I have a FBA Cores CPS1/CPS2 working on Wii - so far two of the bigger CPS2 games (Street Fighter Alpha 3 and Vampire Savior) will load on the Wii (without having to resort to virtual memory). By doing this, I cut down the FBA binary from - say - 33MB to somewhat around 900Kb - this big difference in binary size allows the larger CPS2 ROMs to load/fit into memory.

You can find FBA Cores CPS1/CPS2 at src-0.2.97.26/fbacores.

Obviously, it's going to be a lot of maintenance work if this were ever committed to mainline FBA, so I just keep it for my own separate fork now.

I'm going to be doing more of these cores - they will also prove to come in handy for the Xbox 1 port (64MB RAM on retail Xbox 1). Obviously we are not going to be able to load all the Neo-Geo ROMs with just 45MB of RAM - so perhaps for the bigger ROMs I might have to implement some virtual memory implementation for RetroArch Wii / Xbox 1.

Basically, I wouldn't advise anybody to start doing a separate Wii port at this stage - we nailed video and audio synchronization after a lot of trial and error and I wouldn't advise anybody else to try to reinvent this particular wheel - it won't be pretty, and the solution we arrived at is non-conventional.

[yggdrasil31]

Hello
i build your frontend and linked it with my libretrowii.a one week ago, but it crashed right after the rom selection (with a nice coredump).
as i see a lot of commits on the wii directory of your github, it makes me though the developpment was still on going, and it was too early for me to test it (i really want to play TOKI on my wii  )
i'm doing it to learn a bit about wii developpment at home, since i had nothing very exciting to develop at work for almost a year now.
My first plan was to port fba, but someone pointed me to your work on libretro and retroarch, and i discovered that your work was almost done, so, as i didn't want to reinvent the wheel, i decided to build your sources and try to understand what you've written.
I came accross the same conclusion as you :
Memory is so limited on the Wii, that we will need many retroarch wii binaries, each of these binaries including a system specific libretro, that embedded a limited number of fbacore.
Perphaps, one binaries for pre 90's system (with small roms and lighter system) and then one binary for neogeo, one for caves game, one of for cps2, etc...

[Monster-Of-G]

Hello
i build your frontend and linked it with my libretrowii.a one week ago, but it crashed right after the rom selection (with a nice coredump).
as i see a lot of commits on the wii directory of your github, it makes me though the developpment was still on going, and it was too early for me to test it (i really want to play TOKI on my wii  )
i'm doing it to learn a bit about wii developpment at home, since i had nothing very exciting to develop at work for almost a year now.
My first plan was to port fba, but someone pointed me to your work on libretro and retroarch, and i discovered that your work was almost done, so, as i didn't want to reinvent the wheel, i decided to build your sources and try to understand what you've written.
I came accross the same conclusion as you :
Memory is so limited on the Wii, that we will need many retroarch wii binaries, each of these binaries including a system specific libretro, that embedded a limited number of fbacore.
Perphaps, one binaries for pre 90's system (with small roms and lighter system) and then one binary for neogeo, one for caves game, one of for cps2, etc...

:/ so at least SFA2 works? D: hope u release something :c i know that not everything works because of the limited memory of the wii D: but something is something hope u release this please PLEASE! D:

[Twinaphex]

RetroArch Wii is released now.

FBACores CPS2 runs every CPS2 game at fullspeed - including Street Fighter Alpha 3 and Vampire Savior - two of the biggest ones.

http://xbins.org/index.php?action=catsearch&searchtxt=WII

[yggdrasil31]

what a great release !!! Even the full fba core runs a lot of games.
There are some remaining bugs to be tracked down (rotated UI in vertical games such as Varth or dodonpachi, memory leaks, aspect ratio detection, "the punisher" won't load, but perhaps it comes from my romset, dataeast driver is suprisingly slow etc...) but the performances in most emulated systems are awesome ! I would never believe games such as outrun would run on a wii.
Toki works great !!!!

Could you explain me how to compile my own core from lib retro fba core. I would like to make a tiny fbacore to runs cave and psyko biggest shoot'em up, such as guwange and esp. Is there something to change to comply with your frontend ?

thanks a lot for all your efforts !

[Twinaphex]

what a great release !!! Even the full fba core runs a lot of games.
There are some remaining bugs to be tracked down (rotated UI in vertical games such as Varth or dodonpachi, memory leaks, aspect ratio detection, "the punisher" won't load, but perhaps it comes from my romset, dataeast driver is suprisingly slow etc...) but the performances in most emulated systems are awesome ! I would never believe games such as outrun would run on a wii.
Toki works great !!!!

I'll try to see if there can be an option so that the UI will not rotate along with the game screen itself.

I believe the memory leak problems are present in FBA mainline except that it's never a big issue on PC due to the fact there's no reentrant ROM loading.

The Punisher should work - most of these ROM problems are due to people not having all the clone ROMs. For some reason, FBA libretro requires more (child) ROMs than regular FBA mainline - but it doesn't mean those games are broken.

Could you explain me how to compile my own core from lib retro fba core. I would like to make a tiny fbacore to runs cave and psyko biggest shoot'em up, such as guwange and esp. Is there something to change to comply with your frontend ?

thanks a lot for all your efforts !

You first need to generate some needed files - you do this by doing -

make -f makefile.libretro generate-files

After that is done, you can compile it (for the Wii) by doing this -

make -f makefile.libretro platform=wii

If you wanted to compile for PC, you would do instead

make -f makefile.libretro

Simple. Shouldn't take much getting used to.

To make custom stripped down cores you'll have to do the same things I did with my FBACores CPS1/CPS2/Neogeo - copy all the code somewhere and start seeing what files you can remove based on the system hardware you want to target (ie. Cave, Psikyo SH2, whatever).

Stripping down the binary like this is the only real way I've seen that has successfully allowed me to load a lot of large ROMs into RAM that otherwise it would have been impossible to do. We still need more for Neo-Geo though - there might be no way around it other than a VMM for the bigger Neo-Geo games unfortunately.

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