Homebrew RetroArch - A new multi-system emulator

[kylster]

Is there any plans to support PS1/N64?

Sorry if this has been asked already; still loving the emulator going to try out sega cd games later rwar in the mean time I'm finishing up Star Ocean SNES (I'm in the 7star Ruins baby!)

 

[vigi_lante]

It's really sad to see this kind of animosity against Squarepusher (LibretroRetroArch). People really can't appreciate the work he is doing to get all those emulators running the best it can on all kinds of platforms, with unparalleled attention to detail, like prioritizing performance (instead of using a fancy GUI) and input lag - something that very few developers care about.

He is filling a void in the console scene, providing an unique work that I really doubt anyone else would be doing. People should be grateful and understand that he is only trying to be assertive (and not aggresive), in a healthy and constructive manner. Saying that Snes Next and VBA Next are better than others is a fact.

He is also very open and receptive to feedback from users. Some people are really misinterpreting him.

 

[DJPlace]

who ever is dissing this emulator can fuck off!! it looks nice.

 

[Dogway]

He is also very open and receptive to feedback from users. Some people are really misinterpreting him.

MY BALLS!!:

I'm not trying to attack Tantric and how he ported Snes9x to the Wii, but for one reason or another, he wanted to use frameskipping and I can respect that.

I don't see how you can play without frameskipping. I understand RetroArch stance on this, they want to do things the right away, avoiding the need to frameskip, and while this means well, it's just not practical because old games rely on timing, and frameskipping allows that, things occur evenly real time despite missing frames here and there, while by not using frameskipping you expand and contract the game (time) making it impossible to play. If adding frameskipping doesn't have an impact on the real framerate performance of the game I think it should be added, for gameplay purposes (probably not emulation accuracy purposes though)

Ummm...... scratches head....

I think you have some mystical notion of frameskipping that is not in my version of reality. Frameskipping is nothing but an ugly speedup hack that should be used as a VERY, VERY last resort.
If you honestly think that the SNES used frameskipping of any kind or that you get 'better timing' by doing frameskipping, then I honestly don't know what to say anymore.
Here - I regularly post on an IRC channel where there are various emulator authors and developers around - I posted this and here was the response -

http://pastie.org/4670046

Seriously people - you guys are all over the map - needless to say - frameskipping is to be avoided like the plague if you can do without it. If anything, frameskipping will fuck up your timing - not the other way around.
I hope I don't have to 'debate' people on obvious empirical things from this point on and we can go on to more substantive subjects.

It's very sad you claim respect and consideration, when an user comes here to give an opinion, and all you do is to quote that user's post to make fun in an external place:
"guy is dumber than average around there, and that's not easy"
Is this the way you want to be treated around here? I don't know about 360 or PS3, but the Wii community is and has always been very friendly.

Maybe people who cannot read words intentions are dumber, what I meant is that during the gameplay there's a sucession of events in the background, which get displayed upon frame rendering, if frame rendering takes longer than intended framerate playback you extend the time and the sucession of events (call it rythm), game rythm and timing (patterns) get modified and gameplay suffers from original intentions. In the other hand if you use frameskipping, you don't get faster fps (I never said that), what you get is to DISPLAY most number of frames the CPU is capable to render without affecting the aforementioned sucession of events, or timing, or whatever you wanna call it, even if that means skipping frames once in a while.
My question (and you already know I'm not a programmer) is; having an already faster emulator (VBANext), what harm can enabling frameskipping do to frame rendering if as you say it's mostly running at top intended speed already? Most likely you will only get frameskipping on those few clogged places people are reporting or still not aware.

And for the record, the post above mine was with different words to mean the same I did.
I mean, have you ever thought why frameskipping was ever conceived? It's a mean to play, although what you only aim at is to disPLAY.

 

[LibretroRetroArc]

It's very sad you claim respect and consideration, when an user comes here to give an opinion, and all you do is to quote that user's post to make fun in an external place:
"guy is dumber than average around there, and that's not easy"

Did I make that comment? No, somebody else on there did. Sorry, but this is what you guys look like to people inside coding circles - I don't derive any sort of sardonic pleasure from it - in fact, me posting that there was meant as a nice gesture on my part to deliver the message to you guys to PLEASE STOP with these wild crazy theories on what should probably be included because it's really making zero sense anymore and most developers just tell me plain off the cuff - 'dude, don't even bother responding - talking to ignorant end-users is a pain'. Sorry, but I don't treat people like crap and I'm a very down-to-earth guy - I can assure you that a lot of people are not though and consider every end-user an instant idiot.

So sorry, but this is an unpleasant but necessary outlook into what the general dev community actually says 'off-record'. It's not nice or pleasant to see, but it's reality nonetheless. If you don't like what they say in that IRC log - buck the trend and don't act like it.

Now look at this here - this nice detailed response here is me giving you my most valuable resource - my time - to explain something to you and to take away any pent-up frustration and anger for having read that comment. Now, would a guy that treats people like shit be doing this? Because time is my most valuable resource after all - time is money and me typing all this stuff right now could have been reappropriated into things I should otherwise be doing.

So make up any judgement you want regarding my character based on that. Personally, I would trust the guy who delivers it to you plain rather than talking behind your back, but that's just me.

One thing nobody can holds against me is - I'm a straight shooter - I try not to talk behind your back and even when I do, I let you know what is said and in public. Having been an end-user myself it wouldn't be right for me to treat people like crap just because they are not in a little coding circle.

I also try not to ignore what users say and always try to respond to it and explain myself - and look where that shit gets me most of the time.

Is this the way you want to be treated around here? I don't know about 360 or PS3, but the Wii community is and has always been very friendly.

I'd say it's pretty much the same (and seeing as I'm the only guy targeting Wii/PS3/360/Xbox 1/Gamecube for development simultaneously, I might be inclined to know) - you've got the guy earlier coming in with his turf war nonsense (because he worked with such and such author on a 'skinning job'), trying (in vain I might add) to pit me against certain developers (happens all the time in other scenes as well - I seem to remember Brittneypairs trying to have a good go at it in the Xbox 1 scene) and then there is the usual GUI adoration and other stuff going on. Oh, and a lot of incredulity that people's ZIP files are extracted of course - because that stuff is of course way more important than the actual idea/concept behind RetroArch and the fact it has all these cores running at very respectable speeds.

One thing you definitely don't have in the PS3/360 scenes at least is know-it-all people trying to argue/debate authors who can be reasonably assured they have a firm handle on what they're talking about - I don't mind arguing with people except when it becomes stupid and as long as both parties are suitably clued up on matters. It simply gets frustrating afterwards.

I must stress this -you have no idea how much 'tolerance' I have towards users - I consider end-users on an equal playing field with devs - however, when it delves into stupidity (like happened earlier in this thread), the reason I react in the way I do is that I'm more or less disappointed and start playing with the idea that - hey - maybe those other devs are right - 'dont talk to them'. I don't want to do that, but then again, trying to argue with people on here on stuff they haven't even tested and are just making up is just frustrating.

I see people here telling me up front - 'oh ANY emulator is better at this point' - then finding out they haven't even tested RetroArch yet - but they have no problem making the comment off the cuff. Now you tell me how I should feel about stuff like that. It's like people fire off their torpedoes of opinion without actually having any knowledge about what they're talking about.

In the other hand if you use frameskipping, you don't get faster fps (I never said that), what you get is to DISPLAY most number of frames the CPU is capable to render without affecting the aforementioned sucession of events, or timing, or whatever you wanna call it, even if that means skipping frames once in a while.
My question (and you already know I'm not a programmer) is; having an already faster emulator (VBANext), what harm can enabling frameskipping do to frame rendering if as you say it's mostly running at top intended speed already? Most likely you will only get frameskipping on those few clogged places people are reporting or still not aware.

Anytime frameskipping is visible to me - I instantly turn it off. There's simply no point to jerky screen updating - it's unplayable - which the actual FPS without frameskipping would tell you in and of itself.

And it's not 'at top intended speeds' - most of the time it barely breaks even and it's 'just' running a few frames per second above 60fps.

If something doesn't run at fullspeed, it's not worth playing with anyway and either more speed hacks need to be arrived at or the emulator is simply too slow on the host platform, or (most likely) the host system is simply too slow to do it justice. That being said, a lot of these emulators are very naively and poorly coded from a performance perspective so there is a lot of room for improvement.

I'm not going to just throw in frameskipping in there and 'call it a day' - I avoid it like the plague, and the timing code needed to implement it will slow things down in and of itself (and mess up the timing itself). Bottom line - I'm not touching it - I wouldn't even feed it to the dogs. I've looked at the frameskipping code in SNES9x GX and no way in hell would I ever submit that in SNES9x Next.

Bottom line - the best frameskipping is no frameskipping at all - it's a last resort for when you want to give people the 'illusion' (I don't see how that illusion isn't shattered by the vomit-inducing jerky screen update, but whatever) that it's still running decently when really, it doesn't.

Bottom line 2 - further speed improvements done to VBA Next will have to come in the form of speedhacks, improvements to the rendering code - ie. hard work and time being put in. Like I indicated earlier though, a port of gpSP to libretro will also be done.

THAT BEING SAID - other emulator authors can implement frameskipping as they wish in their respective libretro cores - notaz for instance is doing it with PCSX-reARMed libretro. I don't condemn it - i just don't think it would be suitable for SNES9x and/or VBA - frameskipping in 3D games I find to be far more tolerable than 2D ones.

I mean, have you ever thought why frameskipping was ever conceived? It's a mean to play, although what you only aim at is to disPLAY.

It was made so that developers could 'fast forward' through games which probably helped out a lot while debugging and saved heaps of time (note - this is also the same reason every emulator has savestates in it by de-facto standard - it's meant for the convenience of the developer first and for your convenience second). The fact that it also made games 'playable' (if you can call it that) on systems that could not reach fullspeed was an additional side effect that turned out to be a bonus.

MAME/MESSdev operates along a similar philosophy but taken to even more dizzying extremes - if you think I'm radical, you should see these guys someday .

 

[Rydian]

If people want to post that this is shit and then admit they haven't tried it, report them for trolling.

Seriously, our mods don't like that shit.

 

[the_randomizer]

To those who are constantly bitching about the reasoning behind why LibretroRetroArch coded RetroArch in such a way, knock it off. Seriously, cut it out. You would be wise to refrain from blurting out such baseless, asinine (not to mention childish and destructive) and sophomoric remarks. He understands the know-how of emulators and emulation coding and has stated and proved time and time again that frameskipping solves nothing. It never has and it never will. Underpowered CPUs on mobile devices and very old PCs are likely benefited, but even then, it's pushing the limit and will result in sub par performance at best.

I see exactly where he's coming from, and has not in the least come across as being rude, brusque or otherwise demeaning. If you people construed his explanation as such, well, too f***ing bad.

Any more diatribes or accusatory slander will be reported. Good day.

To reiterate:

- If you have to use .zip files, either get a bigger storage device or use another emulator
- Frameskipping does NOT equate to better performance
- Having an opulent shiny GUI does NOT make said emulator exalted or superior to another emulator,
if that were the case, Zsnes would have been less popular than Bsnes.
- Nobody is forcing you to use RetroArch, if you don't like it, use something else

I support LibretroRetroArch in his decision and stance.

It's ironic, people bitch about Snes and GBA emulators having poor performance on the Wii, and yet, when they get their golden egg (RetroArch) they bitch again. What the hell is wrong with you people!!?

 

[Dogway]

So there you go, I wondered why for the time being couldn't you just add frameskipping, and it happens to be more annoying to handle of than not relying on it and going instead the "right" way. It could be added as an option, but as you state that could drain your time because it isn't as easy to implement. I think we all applause here the commitment to do the job in the ideal way without dirty hacks, that's for granted, what we all wondered I think, is to why not add that as an option "for the time being". Now it's explained and it's ok, no drama.
I never said this or that emulator was better than the other, I just said that I won't be using certain aspects of this emulator because personal preferences, beyond those I explained.

Don't think of everybody as lazy whiners, you use your (free) time for programming, as some people around here as well, I use it creating Avs scripts and restoring video, others do their stuff. No need to complain or stir up. People liked your efforts and they give back as "naive"(or not) suggestions, and you just make a fuss of it and start spitting "stupid", "shit", and similar offensive words. You can be all the honest and straight shooter as you want, but if all of your sincere words are scorn, and offensive words maybe it could be a better idea to keep quiet. At the same time good guys don't go around saying how good they are, they just are.
It's very cynical of you to quote a post with the INTENTION to make fun (ok, to be made fun of), actually do make fun (you or your colleagues), and then post/link that back! That says more about you and your "friends" than me.

I also try not to ignore what users say and always try to respond to it and explain myself

You did care about that post of mine because it was a perfect bait to joke with, but I can see how you just ignored several others I did, for example I first commented about CCPro input lag, but you only started talking about it much later when it already was a common issue, same for the controller configuration, and much recently my question about saving service menu options, (apart of rom paths too which have been commented several times.

 

[quepaso]

If anyone is here to talk crap about this emu, leave this thread and never return. Why is it that when the wii scene finally gets something amazing, all the idiot kiddies who think they know it all show up and try to bash the dev. Squarepusher has gone out of his way to do AMAZING things and this sort of project has never happened before, its unparreled and the fact that something like the Wii got a port is nothing short of outstanding. If you cannot appreciate his work without calling him names, trying to start flames with other people etc, please do not comment and leave this thread to people who are actually using this emu and truly enjoying it. Its astonishing to have something work so well out of the box, and bravo to the team who did the port.

Ontopic, i played some Samurai Shodown 2 neo geo on this emu for hours the other day on the wii and it ran/performed flawlessly. Amazing job guys.

 

[Coto]

LibretroRetroArch don't waste time doing long posts trying to counter non constructive posts. As for I, i'm agree with most of stuff you've argued. Let the others speak and speak.

Tomorrow i'll give a go to RetroArch Wii and post any issue I find. Thanks man (and your team)

 

[Jacobeian]

I know a lot of people have been voicing their opinions here, but I would like it if we got this topic back on track and stop the fights.

I should avoid the archive debate too. The last one to talk about that was an idiot (just joking Jacobeian!). Compressing files is useless.

Uncompressing to a buffer is difficult on the Wii since we do not have lots of spare RAM to use as we wish. on GBA, copying over 32MB roms as-is is impossible, and we would have to either copy the file in parts or edit the core to use the RetroArch buffer, which in turns will require changes to RetroArch to keep the buffer in memory, which IN TURN will require edits to all the other cores to account for this, and for some cores, that will just be wasted space. libretro's modular approach just does not benefit from this.

Or... you could have retroarch decompressing ROM(s) directly to their emulator reserved location in RAM (when virtual memory is not used off course) instead of using your own additional buffer. I've looked through retroarch code and a few implementations (fbanext, snes9xnext) and it seems to me that you are indeed using a common approach to load rom to the cores, which is to either pass a pointer to decompressed/read ROM file and/or directly a filename, for cores that support it. In snes9x-next core for example, it seems you are already passing a pointer to decompressed rom and modified the core loading routine to read from it instead of a file, which is contradictory from what you said about not wanting to use extra rom buffer or alterate original cores. Also seems to me that in this case, there is no need for retroarch to use temporary unzipped file.
Then for some other cores (fba for example), you are simply passing the filename and let the core handle the file reading. This core already had unzipping support using filename as an entry, i don't get why this wasn't used ? If your goal was to get ride of zip support in all these cores for saving memory, then why not having handled externally in retroarch and the core's libretro.c layer ? I mean, in all emulators, loading the ROM file(s) is a one-shot thing, it only happen once on startup (again, when VM is not used but we assume for cores that don't use that here) so it could as well be replicated in libretro.c with calls to retroarch API, something like int Retro_LoadFile(char *path, void *dest, int maxLen) which takes care of zipped or unzipped roms transparently. For FBA roms which need specific filenames in an archive file, you could define an additional input parameter that gives the wanted file to look for in path archive.
Off course, it requires libretro implementation to callback retroarch api (which it might not be designed for in first place) but it seems to me a better solution.

Again, just to be clear, my idea is not to force you adding zip support like other emulators or bitch about it but simply point out that since you are already supporting it in retroarch, it is quite unefficient to have to resort to hackish things such as temporary uncompressed files to load zip files into emulator cores and that better solutions surely exist. If you were deliberately not supporting .zip files, this discussion would not have existed since it is a respectable choice.

As for the flamefest this thread is turning in sometime, i understand where you came from but it's not ps3 or xbox scene here. Most people were just expressing their opinion or kindly making requests from what i have read. I still think the general "agressivity" in earlier answers were not appropriate and out of proportions. Remember the people here are generally just users, you will gain more respect in educating them than talking to them as stupi ignorants or making fun of them on private chatrooms where techies are hanging together.

 

[Morpheus_72]

Many thanks guys for this awesome emu. Great job. I tried a lot of CPS-2 games (from mame set 0.144) and my all-time favorites Pitfall II and Sunset Riders. It was pure fun to play them on a TV. Normally I play these games on my Caanoo with FBA 0.2.97.24.

But for some reasons I cannot get NeoGeo ROMs to work with RetroArch. I tried several different neogeo.zip bios and ROMs from different mame sets. Where do I have to store neogeo.zip ? In the RetroArch system folder on my SD card or along with the game ROMs on my USB hard drive ? Can I store it zipped or do I have to unzip it ?

Help from this forum would be greatly appreciated.

 

[Hielkenator]

Many thanks guys for this awesome emu. Great job. I tried a lot of CPS-2 games (from mame set 0.144) and my all-time favorites Pitfall II and Sunset Riders. It was pure fun to play them on a TV. Normally I play these games on my Caanoo with FBA 0.2.97.24.

But for some reasons I cannot get NeoGeo ROMs to work with RetroArch. I tried several different neogeo.zip bios and ROMs from different mame sets. Where do I have to store neogeo.zip ? In the RetroArch system folder on my SD card or along with the game ROMs on my USB hard drive ? Can I store it zipped or do I have to unzip it ?

Help from this forum would be greatly appreciated.

In the same folder as were you neogeo roms are located.

 

[Toad King]

I've looked through retroarch code and a few implementations (fbanext, snes9xnext) and it seems to me that you are indeed using a common approach to load rom to the cores, which is to either pass a pointer to decompressed/read ROM file and/or directly a filename, for cores that support it. In snes9x-next core for example, it seems you are already passing a pointer to decompressed rom and modified the core loading routine to read from it instead of a file, which is contradictory from what you said about not wanting to use extra rom buffer or alterate original cores.

These are parts of RetroArch's PC heritage, and for all the cores where filesize is an issue. On the cores where we run into filesizes being too big (like GBA) we do not do this, and it is only left around in some other ports due to RAM usage not being a huge concern on those platforms.

All the devs were speaking last night, and while extracting a ZIP file to buffer might be done on the other platforms RetroArch supports, it will not be done on the Wii, or any other platform which has RAM limitations. This is a design choice to avoid unnecessary memory usage.

 

[OriginalHamster]

@ToadKing, it could be possible to do more tweaks to alpha_core? Old Capcom games as Commando and GunSmoke runs slow and the sound looks to be at low frequency.

 

[LibretroRetroArc]

You did care about that post of mine because it was a perfect bait to joke with, but I can see how you just ignored several others I did, for example I first commented about CCPro input lag, but you only started talking about it much later when it already was a common issue, same for the controller configuration, and much recently my question about saving service menu options, (apart of rom paths too which have been commented several times.

What makes you think I am ignoring any of those issues?

They're duly noted and they will be looked at - but you will have to wait until 0.9.8 to see fixes for those unless you are willing to compile from source (assuming you know how to do it - if not, either get somebody who does know to do it regularly or learn it yourself - unlike other authors, I support people doing unofficial WIP builds every once in a while - it's a good way to track bugs/problems before an official release comes up).

---

 

[Gamecuber]

I visit your source page every day, and I find that you are diligently coding it like industious bees. Thank you for all your hard work!
There was a snes9x 1.43 port for Gamecube somedays ago, but I can't find it now. Did you cancel it or change it to snes9x 1.50 port?
Hope more respects to coder and less disrespectful requests.

 

[LibretroRetroArc]

I know a lot of people have been voicing their opinions here, but I would like it if we got this topic back on track and stop the fights.

I should avoid the archive debate too. The last one to talk about that was an idiot (just joking Jacobeian!). Compressing files is useless.

Uncompressing to a buffer is difficult on the Wii since we do not have lots of spare RAM to use as we wish. on GBA, copying over 32MB roms as-is is impossible, and we would have to either copy the file in parts or edit the core to use the RetroArch buffer, which in turns will require changes to RetroArch to keep the buffer in memory, which IN TURN will require edits to all the other cores to account for this, and for some cores, that will just be wasted space. libretro's modular approach just does not benefit from this.

Or... you could have retroarch decompressing ROM(s) directly to their emulator reserved location in RAM (when virtual memory is not used off course) instead of using your own additional buffer. I've looked through retroarch code and a few implementations (fbanext, snes9xnext) and it seems to me that you are indeed using a common approach to load rom to the cores, which is to either pass a pointer to decompressed/read ROM file and/or directly a filename, for cores that support it. In snes9x-next core for example, it seems you are already passing a pointer to decompressed rom and modified the core loading routine to read from it instead of a file, which is contradictory from what you said about not wanting to use extra rom buffer or alterate original cores. Also seems to me that in this case, there is no need for retroarch to use temporary unzipped file.
Then for some other cores (fba for example), you are simply passing the filename and let the core handle the file reading. This core already had unzipping support using filename as an entry, i don't get why this wasn't used ? If your goal was to get ride of zip support in all these cores for saving memory, then why not having handled externally in retroarch and the core's libretro.c layer ? I mean, in all emulators, loading the ROM file(s) is a one-shot thing, it only happen once on startup (again, when VM is not used but we assume for cores that don't use that here) so it could as well be replicated in libretro.c with calls to retroarch API, something like int Retro_LoadFile(char *path, void *dest, int maxLen) which takes care of zipped or unzipped roms transparently. For FBA roms which need specific filenames in an archive file, you could define an additional input parameter that gives the wanted file to look for in path archive.
Off course, it requires libretro implementation to callback retroarch api (which it might not be designed for in first place) but it seems to me a better solution.

Yes, at the moment this aspect of the ports is not really standardized - if we set 'need_fullpath' to true, it's assumed that all internal ROM handling will be done by the core and RetroArch stays out of the picture - this is the reason for instance why FBA directly 'boots' ZIP files. If not, RetroArch maintains a ROM buffer itself of the ROM that has been loaded into RAM - which is a bad idea if the emulator core itself manages its own ROM buffer as well (as was the case in VBA Next before we turned need_fullpath to true).

Also, several emulators like SNES9x and VBA like to allocate very big ROM buffers whose size are fixed - ie. they automaticaly allocate memory for the biggest ROM in existence for the system (in the SNES' case - 64Mbit or so - in VBA's case - 256Mbit). Obviously this is a bad idea on memory-constrained systems and we obviously have to look at making that size variable depending on the ROM we're about to load.

There's basically lots of work involved in every libretro port because most of the time these emulators/games were not really made with consoles and limited RAM usage in mind - memory leakage is also a major problem in most emus that has gone unnoticed because PCs have a lot of memory to waste before it becomes a potential hazard, thus leaks like that tend to get overlooked.

---

 

[LibretroRetroArc]

You can be all the honest and straight shooter as you want, but if all of your sincere words are scorn, and offensive words maybe it could be a better idea to keep quiet.

As a side note - I find it amazing that this purported 'friendly scene' is one where end-users feel they reserve the right to tell devs to 'keep quiet if you don't have anything nice to say' - now if that isn't the world upside down I don't know what is (and say what you want about the PS3/360 scene - but that has never happened in there either). Perhaps you don't mean it like that but anyway - let's give it another try - I'll try to bite my tongue when seeing stuff I would normally shake my head at and we'll see how it goes.

BTW - I don't think you read my post correctly - if you would re-read it, you would find that I am NOT one of these guys that thinks all end-users are idiots - in fact, I was an end-user very much in these scenes until 2010 or so - so I don't think that way and that's why I always try to have a forum presence on news sites and try to reach out to people on all sorts of forums. If I thought that negative about users I wouldn't even be posting right now and certainly wouldn't be making these long posts.

Now, can we leave this all behind now? Let's say I can admit half-way to reacting somewhat abrasively before - good enough for an about-face? How about moving on.

 

[seam]

Many thanks guys for this awesome emu. Great job. I tried a lot of CPS-2 games (from mame set 0.144) and my all-time favorites Pitfall II and Sunset Riders. It was pure fun to play them on a TV. Normally I play these games on my Caanoo with FBA 0.2.97.24.

But for some reasons I cannot get NeoGeo ROMs to work with RetroArch. I tried several different neogeo.zip bios and ROMs from different mame sets. Where do I have to store neogeo.zip ? In the RetroArch system folder on my SD card or along with the game ROMs on my USB hard drive ? Can I store it zipped or do I have to unzip it ?

Help from this forum would be greatly appreciated.

i had this problem too with neogeo. i eventually had some people SEND me their EXACT bios and roms they used(which they had working) and it STILL didnt work for me... which doesnt make any sense. so i was forced to give up. all the other cores ive tried booted games just fine though. loving being able to play cps 1-2 and some cave games on my wii