Revisiting "Holy Grail" Bugs in Emulation
Mar 9, 2018
Debugging is not an easy task, and Holy Grail bugs are an exceptionally difficult class of bugs to squash. Discovering the root issue, figuring out the error in logic leading to the issue, and finally stamping out the issue without introducing new issues can be a long and arduous process. Sometimes one part can be easier than others, and sometimes every step is difficult. But common to all bugs is the required time, dedication, and ingenuity required.
It has been been a few months writing my first two articles on Holy Grail bugs, and it would seem that the articles piqued interest in these bugs, possibly bringing renewed dedication and new insights and ingenuity into the process. As such, some of the biggest, toughest bugs across multiple systems have now been solved, once and for all.
Oct 1, 2017
A new release of mGBA, version 0.6.1, is available. This version is a bugfix release, which contains many stability and accuracy fixes. An extensive list of changes follows after the cut.
"Holy Grail" Bugs in Emulation, Part 2
Jul 31, 2017
It’s been two months since first writing on Holy Grail bugs in emulation and while it did pique the interest of many emulator developers there has been little movement on solving the bugs. Lior did much more research on solving Pinball Fantasies and byuu dug up a forum post implying that there is in fact a three scanline delay when enabling background layers on the GBA. However, none of the issues have been conclusively resolved.
Of course, the previous article only covers two emulated platforms. There are far more than just two emulated systems out there and along with them a large share more incomprehensible issues.
Jul 16, 2017
After many months of delays mGBA 0.6.0 is finally available. This is a major feature release. Some of the more prominent features include a library view, translations to German, Spanish and Italian, and many new debugging features. A full list of changes follows after the cut.
Cracking the GBA BIOS
Jun 30, 2017
A computer must perform a series of initialization tasks when turned on before it becomes ready for use. Once these tasks, generally referred to as booting, are complete, control passes over to the main system. On many systems, especially on specialized systems such as video game consoles, there is a fixed set of initialization routines for the boot process stored in read-only memory inside the system. This is usually referred to as the boot ROM.
When emulating a system, there are two ways to emulate the boot process. One approach is to initialize the emulated state to reflect the state of an already booted system. But from an accuracy-focused, low-level emulation perspective, starting the emulation from a clean slate and run the boot ROM directly is often more desirable.
There are advantages and disadvantages to both approaches, but the most notable disadvantage to the boot ROM approach is that it necessitates having a copy of the boot ROM itself. Since the boot ROM is actual code and not a system design, it is potentially copyrightable and leads to concerns with distribution. Thus many emulators that use a boot ROM require users to obtain a copy separately from the emulator.
Further, many systems contain protections to prevent the boot ROM from being directly accessed or dumped. All Nintendo handhelds have protections. But due to the complexity of these boot ROMs many emulators actually require them to be provided to run at all. However, these protections make it difficult to dump the boot ROMs.
mGBA 0.6 beta 1
Jun 29, 2017
mGBA 0.6.0 has been long delayed. It’s dense with new features and unfortunately not all of those features are hugely well-tested. However, it’s almost ready for release. Before a stable release, more comprehensive testing is needed. In the getting out what’s already working and promoting testing, mGBA 0.6 beta 1 is now available. The final release of mGBA 0.6.0 should be out within a few weeks.
"Holy Grail" Bugs in Emulation, Part 1
May 29, 2017
When developing a video game emulator the goal is to run software for that system on different hardware than the original. Further, the goal of an accurate video game emulator is to run every piece software for that system perfectly—or at least as close an approximation as possible. A decent emulator can be developed working from documentation of how a system behaves when running software. For the Game Boy Advance and Nintendo DS, such documentation is GBATEK; for the Game Boy, the GBDev wiki is invaluable.
Many of these document only say what will happen when the software is well-behaved. Software and hardware generally have a defined set of behaviors which, when given valid inputs, will (barring bugs) have well-defined outputs. For invalid inputs, documents often either say not to do that, or they don’t even mention them. But inevitably some software will do things that documents won’t talk about.
There is the concept of Garbage In, Garbage Out where if the input is not valid, the output is not well defined. In such cases software may become buggy and act unpredictably; however, for perfect compatibility, emulators must maintain bug-for-bug compatibility with the original system. While some sources document the “garbage-out” from invalid inputs, this information is often sparse and can be full of errata or missing edge cases.
The actual debugging to discover these edge cases can be grueling. Yet even after days or weeks of research into just a single bug at a time, there are many bugs that are still incomprehensible and unsolved to the most seasoned of developers. Due to the extreme difficulty of tracking down and solving these issues I like to refer to them as Holy Grail bugs.
Emulation Accuracy, Speed, and Optimization
Apr 30, 2017
A commonly discussed topic in emulation is the “accuracy” of an emulator. The term means how close the emulation is to the behavior of the original hardware. However, there is a significant amount of complexity hidden behind this simple term. There is no simple metric for what makes an emulator “accurate”. Accuracy in emulators is thought to mean it’s slower, but has fewer bugs. Less accurate emulators are often said to be faster and “good enough” for most games. While there is a kernel of truth to these claims, there is far more to the reality of the matter.
medusa alpha 2
Apr 26, 2017
A new alpha of medusa is available. It contains many bugfixes, and allows many major games to be fully playable now. Notably, game-breaking bugs affecting Mario Kart DS, The World Ends With You, Star Fox Command, and more have been fixed. Some smaller hardware features have been added, but many are still missing. The full list of changes is below.
A Taste of mGBA 2.0
Apr 8, 2017
It’s been teased, it’s been joked about. No one could quite tell if the April 1 article was a joke or not. Well, allow me to formally announce to you: it’s real. Every single word was true. I’ve been working tirelessly for the past several months to bring a DS emulator up to a good enough point to release a preview build. And today, I think I’m there. So allow me to introduce another new Nintendo DS emulator: with added DS support, mGBA will now be medusa.
Subscribe via RSS