Welcome!
Final Burn Neo => FBN Development => Topic started by: yggdrasil31 on July 06, 2012, 09:37:51 AM
-
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
-
Big endian patches are merged into trunk yes. Theres no reason why you cant create a workable binary
good luck!
-
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 :wink:
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) ?
-
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 :wink:
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.
-
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 ?
-
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 !
-
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...
-
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).
-
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.
-
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 :biggrin:)
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...
-
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 :biggrin:)
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 :D hope u release this :( please PLEASE! D:
-
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
-
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 !
-
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.
-
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.
-
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...
-
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.
-
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.
-
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).
-
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
-
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.
-
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 !
-
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.
-
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.
-
I miss FBA-X.
me too..those were the good old days
-
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!
-
Am I to understand that development has ceased?