I reported an issue here on Github, regarding m-GBA and how ROMs do not automatically boot up upon loading them. I have tried both real BIOS and emulated BIOS modes, skipping the intro, not skipping the intro, and no matter what I do, I have to pause the emulator then resume in order for the ROM to boot up. My issue has been posted here https://github.com/mgba-emu/mgba/issues/48 and I can only hope that eventually, someone looks into it. The versions I tried were 0.21 official and the recent developer builds, neither resolve this issue, and no one else can seem to reproduce it. Would it help if I captured video of it with nVidia Shadowplay and upload it to YouTube to show what I'm talking about? I'm very baffled here and I want to enjoy this emulator even more, I just don't know why the games don't boot up automatically.

In the interest of furthering the state of Game Boy Advance emulation, I've been writing a test suite that tests various aspects of hardware. At the moment, it only tests timing operations, but way more will be coming in the future. Source code is available on GitHub.


Memory tests
Each test contains 44 configurations. The current version contains 1552 tests total.

Scores:

1. mGBA (master): 1552 passes
   
2. higan v107: 1552 passes
   
3. mGBA (0.8.0): 1532 passes
   
4. NO$GBA 3.0 (BIOS): 1394
   
5. VBA-M 2.1.4: 1337 passes
   
6. VGBA 5.5: 1255 passes
   
7. NO$GBA 2.8e: emulation crashes
   

1. higan v103: 123 passes
   
2. NO$GBA 3.0: 122 passes
   
3. mGBA (0.8.0): 116 passes
   
4. VBA-M 2.1.4: 100 passes
   
5. VGBA 5.5: 10 passes
   

• ROM 4/2 waitstates, no prefetch
  
• ROM 4/2 waitstates, prefetch
  
• ROM 3/2 waitstates, no prefetch
  
• ROM 3/2 waitstates, prefetch
  
• ROM 4/1 waitstates, no prefetch
  
• ROM 4/1 waitstates, prefetch
  
• ROM 3/1 waitstates, no prefetch
  
• ROM 3/1 waitstates, prefetch
  
• WRAM
  
• IWRAM
  

1. mGBA (0.8.0, BIOS): 1540 passes
   
2. mGBA (0.8.0): 1520 passes
   
3. higan v103: 1300 passes
   
4. NO$GBA 2.8e: 968 passes
   
5. VBA-M 2.1.4: 679 passes
   
6. VGBA 5.5: 4 passes
   
7. NO$GBA 3.0 (BIOS): varies
   

1. mGBA (0.8.4, BIOS): 744 passes
   
2. mGBA (master, no BIOS): 639 passes
   
3. mGBA (0.8.4, no BIOS): 610 passes
   
4. VBA-M 2.1.4: 440 passes
   
5. NO$GBA 3.0 (BIOS): 172 passes
   

1. mGBA (0.8.0): 70 passes
   
2. higan v107: 36 passes
   
3. VBA-M 2.1.4: 8 passes
   
4. NO$GBA 3.0: varies
   

1. NO$GBA 3.0: 140 passes
   
2. higan v107: 132 passes
   
3. mGBA (0.8.0): 132 passes
   
4. VBA-M 2.1.4: 132 passes
   

1. mGBA (0.8.0): 93 passes
   
2. higan v103: 93 passes
   
3. NO$GBA 3.0: 93 passes
   
4. VBA-M 2.1.4: 93 passes
   
5. VGBA 5.5: 93 passes
   

1. mGBA (0.8.4): 52 passes
   
2. NO$GBA 3.0: 52 passes
   
3. VBA-M 2.1.4: 52 passes
   

1. mGBA (0.8.0): 625 passes
   
2. VBA-M 2.1.4: 425 passes
   
3. NO$GBA 2.8e: emulator crashes
   
4. mGBA (0.5.2): emulator crashes
   
5. VGBA 5.5: emulator crashes
   

1. mGBA (0.8.0): 1232 passes
   
2. NO$GBA 3.0: 1060 passes
   
3. VBA-M 2.1.4: 1032 passes
   
4. VGBA 5.5: 998 passes
   

• v0-r71
  
• v0-r66
  
• v0-r62
  
• v0-r61
  
• v0-r57
  
• v0-r56
  
• v0-r51
  
• v0-r46
  
• v0-r44
  
• v0-r42
  
• v0-r40
  
• v0-r38
  
• v0-r35
  
• v0-r33
  
• v0-r29
  
• v0-r23
  
• v0-r22
  
• v0-r20
  
• v0-r19
  
• v0-r16
  
• v0-r13
  
• v0-r11
  
• v0-r10
  

Hopefully as my way to give back something to this emulator, in case it gets support for cheat lists (and maybe patches - something like ips/ups codes to be applied to the rom but included in the cheat list file) to cover some interesting stuff enhancing the emulation experience...

If this is okay, this thread should be a compendium of interesting cheat codes from around the internet covering obscure stuff - mainly codes to enable e-Reader content in Japanese and English versions. It could be really helpful for game releases from regions that never had the codes in question. Also covered would be some other peripherals (including probably ones already emulated by mGBA).

So, here I go

Super Mario Advance 4: Super Mario Bros 3
PAL version
European regions never had the e-Reader software officially released, but the ROM does include the ability to scan US e-Cards and all e-Reader features fully translated. The fourth option is just... hidden.
A blank PAL save file with the fourth option is available online, but a cheat code could be more useful in our case (especially since people get to keep their old PAL saves this way).

While I couldn't manage to find the "enable flag for file select screen layout including the e-Reader option", I found the next best thing... a code that forces the cursor to select the invisible e-Reader "Level Card" option. Doesn't display the number though like in the US version or the hacked PAL save, and doesn't enable R button (scan switch cards) in main game.
It's a memory code, couldn't convert it to CB format and have it working :/

Hi there

Really pleased with how open you are with feedback, and seeing as this may be the de-facto portable GBA emulator down in the future, I figured I might want to elaborate a bit on my.. wish list of stuff I'd really, really love to find in the game

So, without further ado, here I go

Color Correction

The older GBA models lacked back-lighting, hence why some games tended to overcompensate with altering their palettes to look far brighter than needed. As later models included back-lighting, some games disregarded this.
It would be lovely to have some custom palette correction options, kind of like with NES palettes.

SAPPY Sound Emulation Enhancements

GBA sound output is, bluntly put, often horrible. Sound gets processed through the CPU, and in most games it just tends to get the shorter end of the stick.
That aside, for games that do get the sound processed to the full potential of the hardware, the sound quality is full of crackling and noise, kind of like how sound gets distorted through phones.

While some games rely on chiptunes/GB sounds (Starfy 1, Castlevania HoD, Super Robot Taisen J), or the internal sound samples themselves have a very low bitrate to save ROM space (Lunar), ... in most cases, the sound samples found within the ROM are much higher quality than what gets output.

I often used this tool "GBA Music Ripper". It's a bit of a work-in-progress, and there are bugs at times (having to do with some instruments not being figured out, or in the case of both Golden Sun games not at all due to them using a different sappy format with reverb and stuff like that).

However, the sappy format is really widespread and almost universal in GBA games, and this tool takes the rom and rips all music, voice samples and sound effects, in sets of SoundFont files (.sf2) and midi files (midi). Using a tool like foobar to read the soundtrack, even Mother 3, often cited as a highlight of sound engineering in the GBA, pales compared to the ripped version which sounds like from a DS game. Zelda Minish Cap is a delight.

So, what I'm asking for is...

This reminded me a huge lot of 3D models rendering in shit resolutions... then emulators added upscale options to process the game's assembly instructions for graphic displaying (in our case it would be sound emulation) as normal, then recognizing specific calls to graphic hardware (here sound hardware, or just sappy sound engine assembly instructions), overriding them when it comes to end-user output to show a custom higher quality model/sound output done in real time.

Would this be possible here? I have the feeling this would be the biggest drawing point to this emulator if this ever materialized.

Debugger Suite

To help fan-translators and such folks.

Well, for starters we'd need some basic stuff, namely:
1/ Cheat support (we have already a really good base work, besides editing/deleting cheats it would also need external cheat files)
2/ Powerful cheat search engine (relative search with ability to set initial values, searching specific value, searching value equal to a given address, displaying values signed/unsigned/hex), and options for bigger/lower/equal... should be assigned to hotkeys in-game with HUD optionally displaying and telling how many results are there.
3/ Search for ranges of unused memory addresses throughout the game that never get written to aside from instructions blanking whole memory, could be running in the background as we play.
Useful for translators to find where to stuff their custom code.
4/ Save States, Rewinding, Frame Advance, Pause key, Reset key

With that out of the way:
1/ VRAM viewer (with ability to switch between various GBA modes)
2/ Map viewer (with ability to see what each square from each BG is from)
3/ OAM viewer (with info like rotation/palette/etc, palette viewer and exporter to same format as VBA, )
4/ Hex viewer/editor (divided by memory types ROM/VRAM/SRAM/...) and the ability to extract a specific range to an external file, pick a custom table (tbl) to change what each hex byte displays as as a letter/char in the right column (ascii, shift-jis, given by default, with option to get an external tbl file)

5/ you can drag to select a given area in either hex viewer or map/vram viewer, then
a: copy it to the clipboard (for VRAM: as a bitmap, for HEX: depending if it's the letter area or the hex area, as a string of characters/hex bytes selected in raw text)
b: paste with overwriting from the first byte onwards, byte number gets unchanged
c: track from ROM : meaning, relying on the rewind feature, tracking where this byte originated from in the ROM - either until a MOV instruction of a block of stuff from the rom, an LZ/Huffman compression scheme or just displaying the instruction that generated it the instant we reach a dead-end.
Figuring out where stuff is in the ROM is the bane of translators
d: watch value for RAM addresses. Like with SNES9X, it can show a tiny HUD with the value real time in-game. Could be useful too if available in the cheat engine

Of course, there's the debugger:
1/ Disassembler
2/ All Breakpoint options (on write, on read, on execute, run, break...) with keyboard shortcuts too
3/ A good status viewer of various hardware flags
4/ Tracer (just dumps all instructions executed between instants t1 and t2)
5/ Assembler (like with FCEUX)

Unemulated Stuff

* Various rumble features: GB Player Rumble, Drill Dozer variable Rumble, WarioWare Rumble...
could use smartphone rumble, joypad rumble, wiimote rumble, or alternatively just a colored HUD square (that turns orange, or shades of orange/yellow/red for Drill Dozer's variable speed rumble)

* Key mapping for gyro controls in Yoshi/WarioWare with various schemes - key inputs with four keys, wiimote emulation (better), wiimotion plus/gyroscopic smartphones (best). And maybe the screen could rotate too?

* Figurine stuff (LegendZ, among 4 other games, but it's really obscure)

Hi, thanks for pushing GBA emulation to the next level!

I had a question, I noticed MESS implemented some GBA improvements taken from mGBA, which is cool of course, the power of open source.

Now this ConsUME site says that MESS (or UME) "is, in our opinion, at least as good as the best standalone emulators for this system."

Would you agree that MESS and mGBA are on the same level of accuracy/compatibility, or do you think mGBA still has an edge?

Using mgba-qt, the program didn't seem to catch all the inputs from my 360 controller. It recognizes it, but only grabs a few input presses (mostly main joystick, and one trigger.)

Is this a known issue? Can I help troubleshoot in any way?

Thanks!

Thanks so much for doing this! We are in desperate need of a modern emulator built from the ground up. Also thanks for the early Linux support!

Q1) Is there a gui for the linux version? I seem to only have a CLI command. If I have this right you wrote the GUI in QT, that should make it easy to get going under Linux, yes? For reference I'm on Kubuntu 15.04 using the nightly.

Q2) What anti-aliasing process are you using under Windows, and can I use it under Linux? It seems to wash out the colors and smudge the image a bit, but at least it's an option.

Q3) I'm very much looking forward to filters coming to mGBA, as it's one of the big things that makes me choose to emu over standard play. What do you hope to implement and how likely do you think it is for it to make it into version 3?

Q4) When do you expect v3 to release, roughly?

Thanks again for everything! mGBA is now my goto emu as it performs flawlessly for me, while VBAM does not.

A while ago I asked about this in an email, but since there was no reply I assume you missed it. Sorry if you're reading it twice.

Do you have any plans for a colour correction filter? GBA games were oversaturated to compensate for the poor screen of the GBA. I first noticed the issue on Golden Sun 2, which I'd already extensively played on an original GBA and an SP. The game was fine even on the backlit SP, but on an emulator without a desaturation filter, every instance of black appears maroon. VBA-M and No$GBA are the two emulators I can think of with such a filter.

Is this option necessary if you have the emulation synchronized to audio? I would have thought that the emulator would already run at 59.7fps if the audio was running at the right speed.

I've gotten a request for a bunch of tools to be added for ROM hacking purposes, including:

• A palette exporter
  
• text translation table support (.tbl?)
  
• A way to trace RAM data back to ROM