FBA Compatibility - GameCube specifics

RetroArch Nintendo consoles
#1

I’m working on a compatibility list for the FBA cores of the GameCube port of RetroArch. The ultimate goal is putting a GameCube to work as an embedded platform inside a real arcade cabinet. Retroarch FBA on GameCube via RGB (SCART) to a CRT TV for a monitor with the new resolution modes looks and performs really, really, REALLY well for the genres intended, and it’s so easy to boot up and config and use arcade stick and button controls wired up. Just easy all around and a very capable system unleashed by the power of RetroArch. Initially I took the Wii-focused list from another thread and began to regression test the list on my GameCube to see what could be hammered out to get the fullest potential. I also got help from aea to correct a previous assumption I had on CPS2 compatibility (5 games now work, not just one) and some other working comparisons. Thank you for that aea! :lol: As we all know, RAM is at a premium on Wii/GC, especially so on GC with only 24MB available. So I started focusing on max loadable rom sizes on GC as a limitation and rejection filter for testing and found some observations I thought I’d share. DOL-001(EUR) with XenoGC, Costis SDLoad on DVD-R and running cores and roms off SD, retroarch-ngc-v1.0.0.2

MEM1 usage per core with no rom loaded (viewable with ‘Show FPS’ feature) (numbers are bytes of MEM1 used / free out of total 25165824)

FBA (0.2.97.30) 19943440 / 5222384

CPS1 (0.2.97.30) 9207824 / 15958000

CPS2 (0.2.97.28) wondering why the .30 version wasn’t compiled into 1.0.0.2 8695824 / 16470000

Neo-Geo (0.2.97.30) 9097232 / 16068592

Largest loadable ROM: uncompressed total ROM data in bytes (subsequent numbers are MEM1 used / free out of total 25165824 when that rom is loaded)

FBA opwolf: 1900544 (24825872 / 339952)

ballbros: 1900544 (23269392 / 1896432)

CPS1 (all CPS1 games fit in RAM) slammast: 12717332 (23318544 / 1847280)

CPS2 sfa: 14942208 (25161744 / 4080) just about squeezes in there with a few bytes short of 4K to spare =D SHORYUKEN!

Neo-Geo stakwin: 12845056 (24227856 / 937968)

strhoop: 12845056 (24236048 / 929776)

EDIT: Neo-Geo roms that are smaller than largest loadable (12845056) but still crash, so maybe for other reason than mem max: kotm2, pbobblen, pspikes2, wh1, miexchng pbobblenb bootleg works however

New Zealand Story bug: All but one game based on The New Zealand Story hardware/driver crash the core on first rom load attempt after starting the FBA core: arknoid2, drtoppel, extrmatn, plumppop, chukatai, kageki, jpopnics, tnzs The exception is insectx , it loads fine. However there is an interesting workaround… load the flstory rom first, and then switch rom to one of the above, and they will work. Maybe Ptolemy is working her magic in some mysterious way? :slight_smile:

#2

Here is a reworked compatibility list with a column added for GameCube status:

https://anonfiles.com/file/f4e9c7502c64 … 2a2f07be86

Credits to Groose, Charco and oji for the extensive work on the original Wii-focused list which this is based.

I also added a column for ROM size (uncompressed) to help with filtering those that would never run on GC due to RAM constraints. It’s about 90% complete for a status remark on GameCube compared to Wii. TO DO:

  • obtain and test all the homebew/prototype roms not on official rom sets
  • trial & error test the remaining blank statuses
#3

More games can be made to work on GameCube if the FBA core is broken up into smalller drivers. i.e. konami core.

Some work was done here a good while back http://www.gc-forever.com/forums/viewtopic.php?f=13&t=1222

#4

Very true. The progress made by splitting off CPS1, CPS2 and NeoGeo to their own cores is really fantastic, and owes a lot to those platforms being very standardized hardware sets in the first place. Personally I would love to see a Taito core :slight_smile: Then again, fragmenting the drivers even further does introduce more challenges such refreshing code bases and doing parallel builds and tests for every release, not to mention if an improved front end ROM chooser ever got spun up. There’s a lot to be said for monolithic cores to keep those things easy since the GC release doesn’t support core switching, you have to bounce the whole system and go through your dol loader again. Another optimization route for GC might be to drop drivers for system ROMs that are so large they will never ever run on GC (anything larger than 24MB lets say) and have a starting codebase like that. This might shrink the FBA macro core down enough to start working towards some kind of sweet spot of multi system support.

#5

I know that maybe it is not related to the thread, but could you please tell me if the prboom and tyrquake cores work for you? If positive, could you please post your configuration? Thanks.

#6

Related to the topic at hand, I’ve been working on isolating the drivers in FBA so the RetroArch/FBA binaries (i.e., an FBA-CPS2 core, FBA-pre90s core, FBA-dataeast core, etc.) would be as small as possible with the hope that it would open up some more games to NGC users. I’ve built the libs but I’m having trouble getting RetroArch to statically link them in at compile-time.

Does anyone here compile their own RetroArch binaries? If so, would you be interested in compiling those isolated cores if I send you the libs? If not, I guess I’ll just keep poking at it until I figure out what’s up.

#7

This sounds great for Wii aswell. Any progress?

#8

Never tried them on GC to be honest. I think I got Doom to work on Wii once. Worth a test to see what kind of memory footprint these cores take up. It’s probably worthy of a discussion thread on it’s own.

#9

I haven’t compiled RetroArch but I had some success with dol compiling years ago when the GC scene was thriving so I’m dusting off devkitPro and will see how I can give back to the project. Any pointers or links to starter guides for setting up the build environment would be appreciated.