[feat. request] higan as gba core

[Liger0]

Higan is the only cycle-accurate gba emulator and overall the most accurate one. I think adding it as an alternative core to mgba would be good to complete the gba scene being able to use bizhawk's lua scripts and such on an emulator that aims to be the most accurate as possible to the real console with no compromise, being unique in his conception. This would be beneficial for games such as the Pokemon ones in which pokemon generation depends on cycle accuracy. Being probably a niche usage and that mgba is a good compromize for general usage, it would make sense to leave mgba as main core and higan as alternative gba core, if plausible.

[nattthebear]

cycle-accurate

buzzword detected

overall the most accurate one

citation needed

[Liger0]

Actual tests are hard to find between higan and mgba, I have searched but I haven't found any practical results, except claims that as of now mgba and higan are very near (with higan having wide improvement margin due to its policy), but being still the only one that cares about accuracy alone it is the only one that can have reach the best accuracy. So if it still isn't, it can actually become the best one so considering implementing it in the future would be good. I consider only aiming at accuracy better than finding a compromise between accuracy and speed anyway, as long as the speed is the same as on the real hardware.

[vadosnaprimer]

How do you know mgba aims for a compromise?

[Liger0]

Because it's written in the FAQ I guess.

[vadosnaprimer]

Quote? I'm seeing

The project started in April 2013 with the goal of being fast enough to run on lower end hardware than other emulators support, without sacrificing accuracy or portability.

[Liger0]

It is a common misconception that mGBA is now or will become cycle accurate, but to do so would require a major rewrite of some of the foundational elements of mGBA.

[nattthebear]

Yet in the opinion of endrift, this choice does not sacrifice accuracy, so...

[Liger0]

Well, to each his own. Giving the user the opportunity to choose would be a good thing, as general in-game accuracy has not be to be the same as cycle-accuracy. I would honestly just go with the most accuracy as I don't care about speed.

[vadosnaprimer]

Is there at least a game compatibility list where higan wins?

[alyosha-tas]

Someone put together a neat list of game bugs in Higan. (I didn't know it emulated so many different things.) So maybe a comparison can be made between it and mGBA. Not sure how complete it is. https://www.retrowide.com/stuff/byuu_compat.htm

Higan appears to be pixel based, so edge cases like this have some relevance for that: https://github.com/mgba-emu/mgba/issues/1644

It is my understanding that the test coverage of GBA is very low, I doubt much can be said about accuracy beyond game compatibility and some limited CPU timing tests.

[YoshiRulz]

The only 2 GBA console verifications to date were dumps of BizHawk/mGBA movies (one of which isn't on TASVideos because it was a resync of an accepted .vbm). There's no point in adding another accuracy-focused GBA core unless mGBA falls behind, which it won't.

[Spikestuff]

I'm going to be the boring one to point this out. Use this test suite specifically for results. Thread (info is a tad outdated). There was a whole thing back in 2016 where they were improving emulation... but in the end mGBA became more accurate than higan.

Heck. You're better off porting VBA-M into Hawk after they removed VBA-Next to get the few outlier games that cause desyncs on mGBA cause of an upstream issue.

[RetroEdit]

I don't think it's as cut-and-dry as you present. mGBA has definitely undergone more work and attention than higan's GBA core, but even those tests have one case where higan outperforms mGBA (and higan is equal to mGBA in many cases).

Also, endrift has said the test suite is incomplete, and more robust testing could definitely be done for GBA emulation. higan and mGBA have some fundamental architectural differences, so it may be the case that certain issues are unsolvable in mGBA and could require higan's approach (e.g. the issue Alyosha linked to).

However, it is my opinion that any upstream mGBA issues should be addressed if possible, instead of trying to fallback on VBA-M (because it seems to me the tradeoff in development time to integrate would be better spent diagnosing and fixing the mGBA issues).

[jengablocky]

Sorry to bump an old thread, but I've been working on console verification of a short run that relies heavily on Pokémon RNG manipulation recently, and my understanding is that "cycle accuracy" would fix the issues I'm having with sync.

[CasualPokePlayer]

Either higan or ares would be a herculean task due to the structure of their emu cores. And "cycle accuracy" is not going to really help you here ("cycle accuracy" does not mean "timing accurate"). There's still a lot of timings which are simply unknown for the GBA. higan isn't going to really perform any better for those. And mGBA might very well be more accurate timing wise in a lot of cases, considering higan's GBA core seems to have slowed down a lot in development, while mGBA has very active development.

EDIT: Also, consider that a lot of GBA games will have outright non-deterministic timing if dealing with flash/eeprom/etc memory for save data. And Pokemon does use flash for its save data. Console verification is going to be finicky for a lot of games just due to this.

[alyosha-tas]

@jengablocky what version of BizHawk are you using? mGBA core gets updated pretty regularly, so using current version is important. Also, what is the nature of your sync issues? If you are just getting incorrect RNG, there might not be much that can be done with current knowledge. If you are finding that you need to add in frames around times when the game is loading stuff, it might be worth reporting it to upstream mGBA. (The last attempt at verifying a GBA game had this issue, so there might be a fixable issue with DMA or memory timing or some such thing running too slow.)

[jengablocky]

@CasualPokePlayer Thank you for the clarification, I was admittedly not knowledgeable at all about what "cycle accuracy" actually meant, I think I was just going off the first Google search definition, which seemed to not be entirely accurate, or at least simplified a bit.

As for the save data affecting timing, would it still affect a cartridge with cleared save data, or is that mostly a factor when there's a savegame already stored? I did end up with a somewhat reliable console-verified script after inserting a bunch of delays, but it relied on the save data being cleared before running it. It did seem to become unreliable at the very end when the script saved the game, so this may explain that.

@alyosha-tas I'm using BizHawk 2.7.0, and the issues I'm having are indeed with needing to insert frames at certain points. It was always a matter of having to insert blank frames, usually during loading times. I don't think I've ever had to remove a frame, for example, but there were around 60 points in the script that required frames to be inserted. After that, it did end up working correctly, so I don't think the issue is with the RNG.

I'll go ahead and try to create an issue report for mGBA. I did notice that the mGBA version is listed as 0.8 under the "about" dropdown in BizHawk's help tab. Is that accurate, or is it actually mGBA 0.9.1 like the recent release notes mention?

Thank you both.

[CasualPokePlayer]

About dropdown is inaccurate, mGBA here is one of the 0.9.x versions.

[getCursorsExe]

Did the accuracy of higan core slightly increase? The accuracy seems simillar...

[YoshiRulz]

I'm told development has slowed on their GBA core. We'll stick with mGBA.