Your eyes are not deceiving you. As of 5.0-14690, Dolphin now has mGBA directly built into it as a new way to handle Game Boy Advance connectivity with GameCube titles. For those who don't know, mGBA is the most renowned and accurate GBA emulator of this era and has been rapidly improving since its inception. Recently, we wrote about mGBA adding support for our TCP GBA protocol, but this is something completely new. With integration and synchronization work done by bonta, connecting your favorite GameCube titles with a Game Boy Advance for multiplayer and other bonus features is now greatly simplified. Dubbed the Integrated GBA, a stripped-down version of mGBA will boot up alongside Dolphin when set to one or more controller ports. These mGBA instances are clock-synced to GameCube emulation for impeccable connection stability. By bringing these two emulators together in one package, GBA connectivity features now work with popular features like savestates, input recordings, and netplay! All of this comes with the added bonus of improved performance and compatibility. If you don't believe us, check it out yourself!

Getting to this point has been a trial that spans generations of developers and emulators. If we're going to tell the full story behind emulating GBA to GCN communication, we have to start from the very beginning.

The Legacy of GameCube and Game Boy Advance Communication¶

As a feature of the GameCube, Game Boy Advance connectivity was pushed to a significant degree in the early days of the system at events like E3, magazines, and of course television commercials. With talented developers from Sonic Team USA, Nintendo EAD, The Pokemon Company, and others releasing titles that would take advantage of the feature, it was easy to see the potential. And at its best, GBA connectivity games are incredibly fun and provide rather unique experiences that you wouldn't be able to find on any other console.

As those who had a GameCube would know, these experiences were few and far between. The feature was left in an awkward spot where it was expensive and needed lots of games to justify the cost, but because of the small userbase most developers weren't willing to invest a significant amount of effort into GBA connectivity features. There are some undeniable gems, but more often than not GBA connectivity features were tacked on poorly as some kind of checkbox feature. With the library now set, we can sort the types of GBA connectivity features into five rough categories.

• Multiplayer Games - These games heavily rely on GBA <-> GCN connectivity to give each player unique information or their own screen to play off of at times. This includes The Legend of Zelda: Four Swords Adventures, Final Fantasy Crystal Chronicles, and Pac-Man Vs. Bonus points go to Factor 5 for allowing players in Rogue Squadron III to link a GBA in competitive multiplayer to use as an extra screen for hiding orders, even if it doesn't amount to much.
• Transferrable Minigames - These games let you transfer detachable games to the GBA. Sometimes it is a bonus NES game, sometimes it's a miniature version of the game you're playing. Sometimes it is... Crash Blast. Examples of games with this feature include Nintendo Puzzle Collection, Animal Crossing, and technically Crash Bandicoot: Wrath of Cortex.
• Bonus Modes or Extra Content - Games could also use the GBA in a single player context to unlock bonus content on the main game. Animal Crossing's GBA island, Mega Man X: Command Mission's Treasure Tracker and Wind Waker's Tingle Tuner are great examples of this. This may seem like a rather expensive bonus feature, but at least it's not an amiibo to unlock quick warping, right?
• Connectivity with a GBA game - Titles could also connect with specific GBA games to unlock content or do things between one or both games. Many games do this, including Harvest Moon: A Wonderful Life, Sonic Adventure 2: Battle, and Metroid Prime. Note that Sonic Adventure 2: Battle can also connect to a GBA without a game for a slightly lesser version of what it does.
• The Pokemon Games - We split this into a separate category because the GBA games are the main product in this case. Pokemon Colosseum, Pokemon XD: Gale of Darkness, Pokemon Box, and their bonus discs can all connect to various Generation 3 Pokemon GBA games for bonuses, trading, and battling. Pokemon Box also let you store Pokemon and had an adventure mode where you could play the GBA games on the big screen without a Game Boy Player.

Still, the few games that truly embraced GBA connectivity presented an interesting emulation challenge. Over the years, several developers have embarked on the multi-system mission.

The Dawn of GBA <-> GCN Emulation¶

The earliest recorded implementations of GBA connectivity emulation go back to around 2009, with the feature first being spotted in Dolphin r2578. While we don't know the exact details behind connecting the earliest versions to a GBA emulator, we do know from developer accounts that multiple ideas were trialed with a focus around the best GBA emulator of the era, VBA-M.

But before we could connect to another emulator, we needed to understand how the connection actually worked. GameCube games will actually encrypt the GBA binary that is sent to the various games, and the way it does this actually posed a bit of a problem for Dolphin early on. The encryption process took place on the Digital Signal Processor (DSP) under a special microcode that we refer to as the GBA microcode. Now this may sound weird, as most people consider the GameCube/Wii's Digital Signal Processor (DSP) specifically for audio emulation, but sometimes it could be used for other tasks. In this case, it is used to encode the executable sent to the GBA as a weak form of obfuscation.

The most notable part of this process is that the cipher used by the GBA BIOS for decryption includes a step where data is XORed with its author's nickname, kawasedo. This refers to Tomohiro Kawasae, who would also end up coding NES emulation features that would be used in GBA connectivity games like Animal Crossing, Metroid Prime and many others.

All of this happens once during the initial connection and only takes a fraction of a frame. After that the game quickly jumps back to the previous microcode before you can even hear an interruption in audio. As a special note, certain first party Nintendo games skipped this step and never swap microcodes. In these rare cases, the game (or service disc) will implement the encryption process directly in PowerPC code. This includes The Legend of Zelda: The Wind Waker, Animal Crossing, and potentially some service discs.

Other than that little bit of a curveball, the protocol in which the GCN communicated to the GBA was dead simple. The GBA Link Cable attached to the data port of the GBA and plugged into a controller port on the GameCube. On the GameCube side, communication was then handled by Serial Interface (SI). The main problem was then figuring out a good way to implement communication between two completely different emulators. While we know several methods were trialed, the surviving implementation from that era used the Transmission Control Protocol (TCP) to bridge communication between the GameCube and GBA emulators. While it may seem like an odd choice to use a network communication protocol, the decision was made in an effort to preserve the experience of having multiple separate devices connected to the GameCube. The idea was that you could still connect VBA-M on the same PC if you wanted, or you could connect it from another computer on the same network. These efforts were spearheaded by shuffle2 and while old support logs seem to indicate that this feature was just a framework and had very little functionality, users did claim that getting to Animal Crossing's GBA island was possible. Take that as you will.

Signs of Life¶

While the initial GBA controller option turned up in 2009, the first evidence of true playability turned up in early 2010, with development posts from shuffle2 explaining how to use the new Joybus options in VBA-M and what to do in Dolphin. He, of course, included some screenshots that would wow prospective players.

GBA connectivity was finally working, but performance was abysmal. This was due to the obfuscation we mentioned earlier. Dolphin's DSP-HLE didn't support the GBA microcode, forcing users to fall back to DSP-LLE. And this isn't the DSP-LLE Recompiler we enjoy today. No, this was DSP-LLE Interpreter. shuffle2 lost interest in the project, saying that until the extreme performance problems were solved, there wasn't much point in doing anything. This would eventually be remedied with a DSP-HLE implementation of the GBA microcode developed by... shuffle2. With DSP-HLE support, performance in the few games that did work skyrocketed, but it didn't fix the core usability issues and low compatibility.

Frustration with how slowly the feature was progressing eventually strained relations between VBA-M and Dolphin developers in 2011. The drama resulted in shuffle2 losing interest in the VBA-M to Dolphin connectivity project, but it wouldn't be his last foray into the realm of GBA connectivity. He returned in 2014, this time using the Higan GBA core as the catalyst for his new experiment. When thinking about the best GBA emulators, using Higan's GBA core might seem odd on the surface, especially back in 2014. It was rather immature and couldn't match the high compatibility or performance of VBA-M. But that's not what he needed. Higan's GBA core offered something that VBA-M absolutely couldn't: A clean, modernized codebase that was easier to work with and integrate.

He also abandoned the TCP communication implementation. shuffle2 instead wrote a new Shared Memory communication method. This was a lower overhead method of interprocess communication which allowed for tighter synchronization but meant that you wouldn't be able to run GBAs on separate machines. Having seen how problematic running a GBA emulator across LAN worked for the previous method, he no longer considered that a viable idea anyway.

These changes yielded immediate results, as there were huge visible improvements to both performance and compatibility. The Legend of Zelda: Four Swords Adventures (and Four Swords+!) was now smooth and responsive. There were tons of new games that also worked, like The Legend of Zelda: The Wind Waker, Nintendo Puzzle Collection, Animal Crossing, and Mega Man X: Command Mission. There were now over half a dozen games supported. And even more impressively? All of these games were running full speed! We here at the blog were so excited about the feature that we made a video anticipating its eventual release!

For those that followed development back then, you already know that this implementation would never be merged. As we at the blog painfully learned, sometimes the hardest part isn't proving that something can work, but rather is the process of cleaning it up and getting it to completion. Compatibility and performance was great, but using it was difficult and there were a lot of ways to cause crashes. There was also the small issue that you could only connect one GBA emulator at a time in the prototype and the implementation was locked to Windows machines. While all of these problems were fixable with enough time and effort, the project eventually stalled and would never see the light of day.

The Modern TCP GBA¶

With the permanent suspension of the Higan Dolphin Shared Memory project, GBA connectivity emulation was on life support. The early protocol only supported a few games and it didn't see much use. It was slow, cumbersome, and worse yet, many developers on both sides showing disdain toward the supporting connectivity project. With VBA-M developers even drawing up plans to remove the feature from official builds, it really seemed as though everything was falling apart... until it wasn't.

One of the key reasons things were able to hold together through rough times was a developer known as skidau. They were a contributor to both Dolphin and VBA-M and also helped with the GBA side of the 2010 implementation. Throughout the years after that, they provided support and helped users get GBA connectivity features working. Because of this experience, they had a deep knowledge of the problems and challenges around GBA connectivity. Unlike shuffle2, who used what they learned from the 2010 implementation to create a new protocol, skidau took what they learned and tried to improve the current TCP GBA situation. In 2015, the fruits of their labor were delivered with tons of changes to both Dolphin and VBA-M.

• Transfers were now asynchronous, which increased performance greatly
• A second port was used to send clock information to connected GBAs
• Reduced CPU load by checking for connections less often
• Dolphin could now handle disconnections from the GBA
• Sockets were now blocked on disconnect

Overnight, Dolphin went from being able to connect to a couple of games to having at least some compatibility with most of the GBA connectivity library. This was accomplished through a clever system that kept emulators communicating with minimal syncing. The key component to this was that the GBA emulator was to remain paused while waiting for packets from Dolphin. Dolphin would in turn send packets to the GBA emulator while they were connected, telling the GBA where it was in emulation and when the next reply was expected. The GBA emulator would then reply immediately before emulating uncapped to the reported guest time in the packet. If by that point it hadn't received another command, the GBA emulator would pause and wait for the next packet. The solution was rather crude and the framepacing wasn't fantastic, but it worked. This core idea would become the basis for GBA connectivity in Dolphin for years to come, and even now some of the code from this implementation is still used!

It was at this point then the scales tipped and GBA <-> GCN connectivity became more than an experimental curiosity. By using Dolphin and VBA-M, you could access GBA connectivity features in popular games like Wind Waker and multiplayer in The Legend of Zelda: Four Swords Adventures. Tons of other games worked too, and even Final Fantasy Crystal Chronicles could connect... at least to some degree. Most other games with smaller features worked, with a few exceptions here and there.

Limitations and Problems¶

Things were finally coming together, but the feature wasn't living up to its full potential. The first thing that has to be clarified is that while TCP is a network communication protocol, TCP GBAs do not work very well over the network. In fact, something as simple as using WiFi was enough to push the latency too high to maintain connectivity. Wired LAN could work in some games, but even then it was cutting it extremely close. The feature only really worked on LAN in one game, The Legend of Zelda: Four Swords Adventures, and added tons of performance implications.

Speaking of performance, the CPU requirements of using TCP GBAs were a huge deal breaker for a lot of users. At the very base, all of the pausing and waiting meant that you needed a much stronger computer just to keep things running full speed compared to running just the base game. And remember, back in 2015 you'd most likely be using LLE (Recompiler) audio to connect your GBAs as the numerous problems with HLE audio limited compatibility. Only the most powerful computers could maintain full speed in games like The Legend of Zelda: Four Swords Adventures with multiple VBA-M instances connected at once. Final Fantasy Crystal Chronicles was slow with dropped inputs no matter what you tried to do.

But those games at least connected and worked most of the time. One of the biggest problems with the 2015 implementation was that some rather big titles struggled to connect. We're talking about Pokemon Colosseum and XD and their bonus discs. For many users, this was the biggest disappointment of GBA connectivity. Over the years, clever users have figured out tricks to make it connect sometimes. Battling was more consistent because it had a retry connection option but trading was near impossible.

What was causing all of these problems, especially considering how simple the protocol actually was? The key was in how the TCP GBAs remained in contact with Dolphin. These games in particular loved to spam tons of commands, sometimes sending over 200 commands a frame. This exposed a rather serious flaw in the TCP GBA protocol. Namely, they could get tripped up if they received a command while they were still emulating forward to catch up to the point from the previous command.

This could happen on repeat until the GBA falls so far behind that the GameCube gets responses that don't make sense. At this point, the game would cease talking to the GBA and a communication error of some kind would occur. Worse yet, one or both of the emulators could outright freeze if the communication error wasn't handled cleanly, as each emulator would be stuck in limbo waiting for a response from the other. Timeout features usually prevented full on crashes, but there were definitely times where everything would go catastrophically wrong. While it would be easy to just blame bad emulation, the games didn't exactly make things easy. Many of the games relied on race conditions or had timing issues even on console!

Entering the Modern Era¶

In the years following the 2015 TCP GBA implementation, improvements were not nearly as dramatic but kept making the situation a little bit better. Most of the improvements came outside of the actual protocol. Most notably were things like fixes to HLE audio that allowed for the connection of multiple TCP GBAs, giving a sizeable performance increase in those situations. Additions to reverse engineered DSP-LLE allowed connectivity in picky games without needing to specifically dump DSP files from a GameCube or Wii.

While things weren't changing on the GameCube side of things, the GBA landscape was seeing a paradigm shift. VBA-M was now a legendary emulator that had firmly cemented itself into the annals of emulation history, but a new generation of emulators had emerged. Rapidly, mGBA was improving and becoming a robust, accurate alternative with a plethora of advanced features. As users saw more hardware peripherals supported, many wondered if Joybus support and connectivity with Dolphin would eventually come. It turns out that users weren't the only one interested; endrift also wanted to implement Joybus support and even submitted fixes to Dolphin in preparation for support. Unfortunately, other features and work on mGBA caused things to get delayed again and again. Finally, in 2021, support for Dolphin connectivity was added in mGBA 0.9!

mGBA's more accurate emulation immediately made an impact in compatibility. Audio issues that plagued VBA-M in GBA connectivity titles like The Legend of Zelda: Four Swords+ did not happen in mGBA. Additional fixes to Dolphin from endrift also fixed connectivity with games like Sonic Adventure 2: Battle and Final Fantasy Crystal Chronicles. On top of playing audio correctly, fixes by both endrift and bonta fixed a critical hang between rounds in The Legend of Zelda: Four Swords+.

More impressively, all of these changes were made within the confines of the 2015 protocol! Backward compatibility wasn't affected and there weren't any changes needed from VBA-M. However, during all of the preparation and development another project was unveiled, one that wouldn't be limited by the TCP GBA protocol.

The Creation of the Integrated GBA¶

During discussions in the development channels, bonta noticed that several developers were talking with endrift about potential improvements to the GBA <-> GCN protocol. Figuring that his personal project may be of interest, he decided to speak up and announced that he had been working to integrate mGBA directly into Dolphin. He even claimed that these internal GBAs were compatible with netplay.

Big promises are easy to make, but usually the underlying product is messy or limited, at least early on. Expectations were tempered while some developers decided to compile and test out the branch. It was extremely impressive. bonta's build was already incredibly polished by the time he showed it off. More than just performance, but having everything included in one package made it easy to set up and use. This initial prototype showed that the Integrated GBA was more than feasible, it was awesome!

While we at the blog would love to tell a harrowing tale of narrow escapes and crazy solutions to get things to production, that isn't the case here. Despite our best needling, bonta repeatedly explained that all he did was the grunt work in regards to mGBA integration. Advances in emulation quality between Dolphin and mGBA, along with the historical work done in the early days by shuffle2, skidau, and several others had solved a lot of the problems already. Recent fixes to the protocol from endrift were just the cherry on top.

Contrary to bonta's insistence that he only did the easy part, let us clarify that his contribution to this cannot be understated. He's dedicated a lot of his time toward the dream of getting GBA <-> GCN netplay working, and while this particular incarnation went smoothly, other attempts in the past didn't.

If you go back to the summer of 2020, bonta was in the thick of things with another attempt to get The Legend of Zelda: Four Swords Adventures working on netplay. This attempt involved trying to make VBA-M and Dolphin's TCP GBA protocol work together with Dolphin's netplay infrastructure. If this sounds crazy to you, you're correct. However, where there's a will, there's a way and bonta managed to make it work. Using the fairly new Host Input Authority style of netplay and VBA-M's movie recordings... he created this monstrosity of a setup.

At the start of netplay, there was an up to two minute SI buffer where emulation would remain paused. Remember that connected GBAs communicate over SI, so this massive buffer actually acted as a time limit for the host and clients to set everything up. Each client would run one VBA-M and connect it to Dolphin, while the host would need to connect four VBA-M instances to their Dolphin. Through netplay, inputs would be communicated from the various VBA-M instances through Dolphin to the other VBA-M instances. Players had no feedback and any mistake would result in everything breaking horribly. If successful, the clients' emulators would automatically run as fast as they could to catch back up to the host. From there netplay would run normally, albeit with the latency penalty of using Host Input Authority. It was a mess, but it was also beautiful in a strange, strange way.

Changing to mGBA¶

While things worked, bonta wasn't happy with the performance, latency, and difficulty of using his setup. He abandoned the project, but didn't exactly give up on his goals. In fact, just six months later he returned to the realm of GBA connectivity to start a new project, this time utilizing libmgba. libmgba is the emulation layer of mGBA, and things like the GUI you'd use in an mGBA executable are layered on top of it. This is one of the key reasons that mGBA is so easily ported to so many different platforms. This design gave bonta a relatively easy way to integrate a GBA emulator directly into Dolphin's core. By doing that, he no longer had to rely on timing windows and stopping/starting emulation to keep things synchronized. Instead, the emulators could now be clock synced and always be at the correct point in guest time. The integration kept things simple and there was no need to manage or handle interprocess communication since everything was bundled together.

Another important note is that communication is deterministic. This is an important thing to note, as netplay was his primary goal and this opened up a lot of possibilities. He continued to work on and polish this implementation, before unveiling it to other developers. In the lead up to getting it merged, bonta worked with developers to add key features and fix bugs in both emulators. With his and endrift's work together, we can now say that 100% of compatible GBA connectivity titles will work with the Integrated GBA.

Harnessing the Integrated GBA¶

All of this sounds great, but how do you use it? It's actually very simple, as the Integrated GBA is designed specifically for Dolphin's needs. When you've configured an Integrated GBA to any controller port, it will automatically boot up alongside the game. Any necessary settings can also be directly configured in Dolphin, such as the location of a GBA BIOS, a default GBA ROM to load on boot, controls, and more. All of this is directly available within Dolphin's GUI without the need for an external GBA emulator. And because we're relying on the excellent mGBA for our GBA emulation, all supported titles will run correctly on the GBA side.

One of the biggest benefits to having an integrated GBA emulator is performance. Despite being much more closely synced to Dolphin, the Integrated GBA is actually much faster than running separate GBA emulators. This is simply due to the differences in syncing versus the current TCP protocol. There's just a lot less stopping and waiting.

There are also some rather nice bonus features that having an internal GBA allows. Creating a savestate while an Integrated GBA is running will include the state of the GBA for when you restore the state! This means that features like the Tingle Tuner in The Legend of Zelda: The Wind Waker won't disconnect if you have to use savestates for a difficult trick. Speaking of Wind Waker, the performance issues of having a GBA emulator connected do not happen when using Integrated GBA! No random stutters from having a GBA try to connect without the tuner active.

Picky games such as Pokemon Colosseum and XD no longer run into problems because the Integrated GBA is more than capable of handling their stringent connection requirements. This also applies to the various Pokemon Bonus Discs! All of this possible without needing to adjust any kind of settings or hoping that they'll maybe connect once like with TCP GBAs. As a quick aside bonta also fixed the issue in SI where Pokemon Colosseum would softlock if a GBA is connected on startup in order to make things easier. This particular fix also applies to TCP GBAs!

Another potential boon is that Tool-Assisted Speedruns using GBA connectivity features are now possible. Everything is already hooked up, since savestates and input recordings are already supported! Considering that speedrunners use the Tingle Tuner in The Legend of Zelda: The Wind Waker speedruns, having easy access to it with savestates may allow for easier development of new strategies or Tool-Assisted Speedruns. But none of this was bonta's final goal. He wanted to play GBA <-> GCN games like The Legend of Zelda: Four Swords Adventures on netplay with friends. And the implementation of GBA connectivity on netplay might be the most impressive part of this package.

A Link Across The World¶

As we said before, bonta had previously dabbled in GBA connectivity with Dolphin in an attempt to get netplay working. His disdain toward the flaws and difficulties of the previous incarnation caused him to create a brilliantly simple, yet robust system that fits directly into Dolphin's netplay infrastructure. The hard part wasn't even getting everything to work; mGBA and Dolphin are both deterministic for these purposes and once everything was integrated it worked for free. The main difficulties was hooking various features to the GUI and making sure that Dolphin's netplay could handle how the GBA communicates.

By now, you're probably wondering how exactly bonta defeated the seemingly impossible latency requirements of linking GBAs across the internet? After all, even over LAN with less than a millisecond of latency, TCP GBAs would start to have problems. The key here is that he didn't need to solve that problem, he just sidestepped it. Instead of trying to pipe GBA communication over the network, during netplay every player will emulate every GBA instance. In a four player GBA <-> GCN netplay session, every player will be running five emulators!

In terms of features and convenience, a ton of work has gone into making this powerful enough to handle anyone's needs. bonta was more than just the developer. In this case, he was also the user and knew exactly what was needed to give a sublime experience. There's a lot of polish and nifty features designed around making GBA <-> GCN netplay seamless and fun. One of the coolest features is that there is an option to hide and mute all other players' GBAs during netplay! This gives a very authentic experience when playing these games online.

The level of detail in the breadth of features is astounding. For games like Pokemon Colosseum and XD, there is GBA save synchronization from the host, meaning that you can be sure that all players are using the same savefiles during netplay sessions. Netplay will also make sure that everyone has the correct GBA games set, and will even prompt players to select a ROM if it can't be found. Netplay also supports the ability to Reset GBA, which is necessary to start the connection process in these games. Each player controls the ability to reset their specific GBA, so players can't mess with their friends by resetting other GBAs!

Even Final Fantasy Crystal Chronicles, long considered the most difficult of GBA <-> GCN titles has been felled thanks to numerous fixes from bonta and endrift. And yes, you can play it online with friends without any issues. This also opens up the opportunity to turn The Legend of Zelda: The Wind Waker into a multiplayer experience by giving a friend control of your fate with the Tingle Tuner. Just make sure you trust them.

There is one rather unfortunate limitation, however. Pac-Man Vs. is a game that heavily relies on passing controllers between different people. Dolphin's current netplay infrastructure doesn't have a way of changing controllers once a game has started. While the game does work and synchronize correctly on netplay, the game's flow is impossible to follow. It is a shame, as the game can be a lot of fun. Note that this is a netplay limitation rather than an Integrated GBA limitation. Our netplay infrastructure just isn't designed for changing who controls what controller during emulation.

Legacy and Future of the TCP GBA¶

One question you might have is what happens with the TCP GBA now? It may be easy to think that because of the Integrated GBA that we would drop support, right? Well, that's not what we're planning. The Integrated GBA might be convenient for Dolphin users, but it may not be something that mGBA and VBA-M users want to rely on. After all, they have all of their controls, settings, savefiles, directories, and more already setup for their chosen emulator. If they're planning on mostly playing GBA games, why force them to transfer everything over to Dolphin and back?

If you're playing a Generation 3 Pokemon GBA game, you'll probably end up in the GBA games more than you will Pokemon Colosseum and XD. While these games are currently problematic with the TCP GBA, they're the primary case of why keeping it around in the future will be useful. As a standalone GBA emulator, the Integrated GBA comes up very short. It's specifically designed around Dolphin's needs and cuts out tons of features that are standard in other GBA emulators.

For instance, mGBA has tons of features that don't make sense to expose in our simplified GUI. Stuff like syncing modes, audio buffers, rendering method, and more would just add complexity that is unneeded. If you're able to run Dolphin, you shouldn't need to be optimizing performance settings for a GBA emulator! On top of that, there are several games that are designed for you to be able to disconnect the GBA and continue playing even when the GameCube is turned off. The Integrated GBA shuts down when GameCube emulation stops because it's tied directly to Dolphin. This can be annoying for the tiny Chao Garden in Sonic Adventure 2 or the downloadable bonus games in Nintendo Puzzle Collection, Crash Bandicoot: The Wrath of Cortex, and Animal Crossing.

Differences in compatibility mean that sometimes you may need to use the Integrated GBA regardless. And in those cases we've included several features to make handling things as painless as possible. You can export separate GBA only savestates in the Integrated GBA context menu. These savestates are compatible with mGBA, meaning you can continue your progress on a standalone emulator without Dolphin running later on. You can also import savestates from mGBA if you so desire, which can be convenient versus moving around savefiles.

And because TCP GBAs are still supported in Dolphin, you can combine them with Integrated GBAs if you so desire!

As for improving compatibility, endrift has shown interest in revamping the TCP GBA protocol to eliminate most of the downsides. While it wouldn't be able to support special features like netplay and movie recordings, it would make things simpler for people who are just using Dolphin for GBA bonuses, like obtaining Jirachi from the Pokemon Colosseum Bonus Disc.

There are also some linking capabilities that require some of the more complex features of mGBA that might be confusing or impossible to use with the Integrated GBA. A good example of this is the GBA e-Reader. While the Integrated GBA is mGBA, the stripped down GUI has no indication of how to use the GBA e-Reader or how to scan cards. Meanwhile, if you're using mGBA standalone, it has clear indications of how to use the GBA e-Reader and how to load e-Reader cards.

Why does this matter to Dolphin? Some GameCube games, including various Pokemon titles and Animal Crossing, can actually connect to the GBA e-Reader. If you didn't know about this functionality, it might be because of just how uncommon it was for someone to own everything necessary.

• The Required GameCube Game
• A GameCube
• A Game Boy Advance
• A GBA e-Reader
• A GBA to GCN Link Cable
• e-Reader Cards

Suffice to say, this feature saw incredibly limited use, especially outside of Japan. Thankfully, mGBA is one of two emulators to fully support GBA e-Reader cards. This means that e-Reader features in GameCube games are already supported.

All of these reasons combined made the decision to keep the TCP GBA around rather easy. Even a decade after its initial merge, it still has a future in Dolphin.

Conclusion¶

GBA connectivity has reached a new plateau. With Integrated GBAs, taking advantage of GBA connectivity features is super user-friendly. And because everything works so well, it can be forgotten just how much work went into getting things to this point. This wouldn't have been possible without shuffle2, skidau, and everyone else who worked on understanding the GBA connectivity protocol in the earlier years. And without endrift's work on Dolphin, mGBA, and libmgba, there wouldn't have been an easy way to integrate a GBA emulator to Dolphin without tons of refactoring. And of course, bonta's work can't be overlooked. They are the catalyst that actually made it happen. It's still weird to think that when users ask about playing The Legend of Zelda: Four Swords Adventures on netplay, developers and support staff will finally be able to answer, "Yes, you can."

One potential disappointment is that none of this is hooked up for Dolphin on Android yet. The good news is that, technically speaking, things should work once everything is set up. Because of the increased synchronization between the GBA and GameCube emulator, performance issues won't cause disconnects or interruptions in communication. Even a Raspberry Pi 4 was able to play The Legend of Zelda: Four Swords Adventures with multiple Integrated GBAs on netplay... albeit at 6 FPS. With performance issues not affecting connection stability, it could be worth figuring out how to hook things up.

Beyond that, there's not really any mysteries to solve regarding the Game Boy Advance and Dolphin. Everything interesting regarding the GameCube and GBA is working. Yep. Nothing really interesting left to do.

Wait, what's that in the distance...?