Adventures with an 11,000 kilometre-long Game Boy Advance link
One of the things I lamented a lot growing up was an inability to find anyone else to do Game Boy link cable games with. I had a few games which would work with the setup, but very few of my friends had Game Boys themselves and when my younger brother received a Game Boy Pocket (I had the black-coloured original), it used a different cable all together, making it impossible for us to play Pokémon together.
My Game Boy was always on its own little island, never to see any real interaction any other device. It wasn’t until I was much older that I would have the ability to hook it up with other Game Boys since I now own a Game Boy Advance (GBA), Game Boy Player, and Super Game Boy 2.
But everything is online now and starting with the handheld’s successor, the Nintendo DS: it’s also wireless. There are a lot of gems for the Game Boy out there which relied on this cable that have since become largely forgotten or at least cannot have the full extent of their capabilities realized.
The GameCube and Game Boy Advance
One of the features of the GameCube was the ability to attach to a GBA via a controller port. This wasn’t meant to output from a handheld to a TV necessarily (such as with the Super Game Boy on the Super Nintendo), but instead to act as an alternate controller or to transfer content between. This same cable also works on Wii consoles with the appropriate controller ports.
One other benefit of this cable is when using the Game Boy Player, you can use the GBA as a controller instead of the awkwardly-shaped one provided with the console. And if you want to go further, you can also attach the cable to another GameCube if you want to make use of the Player on there instead.
One of the features of the GBA is the ability to load software on it without having to insert a cartridge. This made the handheld rather powerful as a game loaded on a GameCube could load content on to a handheld without additional copies of software.
This was taken advantage of games such as PacMan Vs., Final Fantasy Crystal Chronicles, and importantly for this article, The Legend of Zelda: Four Swords Adventure. All of these games required the use of a GBA to be attached for multiplayer action and acted a lot like what you’d see in some Wii U games.
However, this required you to have multiple GBA handhelds, the cables themselves (sold separately), and the appropriate copy of the GameCube game.
A ridiculous dream
One of the consequences of the ongoing pandemic is the inability to not only safely play some games in the comfort of our own homes, but to travel to see each other when we have shared interests. I’ve been wanting to play one of the aforementioned games with a few friends, but safety is important.
So on and off I’ve been thinking about just playing these games over the Internet. It was more or less an idle thought in 2020, but then in early 2021, someone released an adapter which allowed you to make use of a Raspberry Pi Pico to allow a desktop computer to interface with a link cable. I quickly ordered one and assembled it.
There’s now no reason that physically a GameCube couldn’t attach to the Internet if I had at least three of these USB adapters attached to the console with three of those appropriate link cables, and then three other people with GBAs with the same adapters attached to their PCs.
And that is where the problems started: it required everyone to have the hardware. Unfortunately, that wasn’t going to be the only issue.
The adapter itself was intended purely to trade Pokémon, which itself should work even with the latency the Internet creates. It was designed around the idea that it should be fine for pure Game Boy to Game Boy connectivity, which is forgiving due to how the protocol is supposed to work.
Since the link protocol is synchronous and bits are sent and received simultaneously, that means the master device requires the slave to send its response at a rate equal to the clock speed. In non-Game Boy Color mode, the master Game Boy supplies an 8KHz clock (data transfer speed of 1KB/s). This means that there is only a ~120μs window to respond! The Game Boy Color can operate at even higher speeds. No internet connection could possibly satisfy this latency requirement. However, the slave device has no such constraints. It just responds when it receives data!
Unfortunately, it doesn’t appear that this is the case with the GBA. Based on what I am reading in some excellent documentation, the clock rate is even tighter with its tolerances (256 KHz to 2 MHz for the GBA as opposed to the original Game Boy’s 8 KHz). As a result, the hardware is unlikely to accept being a GameCube controller once you are of significant distance, which in the GBA’s case is more than a few metres.
But maybe the hardware being a problem is a non-issue. What if we just scrapped the hardware idea and do this using software instead?
Luck would have it that a few months after the USB adapter was released, the team behind the GameCube (and Wii) emulator, Dolphin announced a new feature: Game Boy Advance netplay.
This was no small feat for the team, but they’re also known for being rather meticulous and talented with their software. It wasn’t fool-proof and was rife with problems as evident from this excerpt from their blog:
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.
When I casually brought up in the fall of that year that I wanted to do this, someone linked the above blog piece, which then led to some organization.
Getting a crew together
Eventually my friends, authorblues, tinahacks, Aetyate, and I got together to go over playing this game online. We kept testing brief as we wanted to play the chosen game mostly obscured from us aside from “does it work”.
Once we were assured, we set up a night to play and thus The Legend of Zelda: Four Swords Adventures was being played on Twitch with all four Game Boy Advance displays on stream alongside the GameCube game itself.
While Aetyate and authorblues are in the eastern United States, tinahacks herself is in Finland. With my being in Vancouver, we effectively had two 4,000 KM (2,500 mi) connections and an 11,000 KM (6,800 mi) one going to my PC, playing a game which originally used a two metre (6 ft) cable itself — these distances are approximations and not based on the actual connections between us.
A single button press would find itself travelling 15,000 KM (9,300 mi) one-way, meaning that we’re approaching at least 3/4ths of the circumference of the whole planet considering the nature of of both TCP and the link cable protocols. The emulator was required to do this in order to keep everything in sync and consequently we had to endure somewhere of a 1/5th of a second delay on our individual inputs just to make it manageable.
But it was possible and we were playing it.
Reducing the latency was something I had considered. I looked at options for acquiring a virtual machine with a GPU located somewhere in eastern North America close to fibre links across the Atlantic to Europe, but the costs for such systems have become quite expensive.
For example, one large cloud computing service was quoting me US$800 for a single month’s use of a machine meeting these requirements. Even with a discount I had available plus US$450 in credits I had with them, it just didn’t seem worth it.
This was something another streamer had done in order to host fighting games online and had a great deal of success, but we didn’t feel that the cost was worth it for what we were playing. Four Swords Adventure is an action role playing game and with two streams of this game under our belt, we were feeling that latency would not hinder us too much.
Or so we thought.
When the lag caught up with us
The latency in Four Swords Adventures was largely manageable for us and often was comical. In fact, the latency was the least of our concerns for the most part as we had other issues to deal with.
During one of our streams, tinahacks’ copy of Dolphin suddenly ran into problems and started to spew all sorts of errors on her computer. Fortunately, we were not too far past the last save point so we all opted to just restart Dolphin and carry on.
On average, I was seeing about 60–80 ms of latency between Aetyate and I, 110–130 ms for authorblues, and unsurprisingly, 180–220 ms for tinahacks.
This is where the whole 1/5th of a second from earlier comes from. We were restricted by the laws of physics to what options we had available.
Dolphin includes an adjustable buffer setting in its netplay feature and we can adjust it based on what feels right. I kept it at ‘20’ the whole time as reducing it any further started to introduce audio choppiness and that is just not good “stream content”. It was fine for the first two streams, but towards the middle of our third night of playing the game, it reared its ugly head.
The game wanted us to walk in-step to get to the other side and failing to do so would result in us having to circle back to where we began on the screen.
Typically if you run across a pit in a Zelda game, you can use your “Pegasus Boots” item to quickly dart across large gaps. However, the game developers placed what appears to be potato-pineapple hybrids in the way so if you were to dash across, you’d collide with them and then fall down the pit.
The game requires you to walk parallel to each other in formation in order to keep the platform balanced and then upon approaching the blocked items, simultaneously pull them off of the ground and then toss them. If you can pull off the second part successfully, then the pit is resolved so all we need to worry about is just getting at least one of us across.
With the current buffer settings, we probably made a dozen and a half if not more attempts. It was starting to look dire as the input latency combined with the latency that a Discord audio call produces made it impossible for us to just get the timing down right. It was beginning to look like this might be the end of this fun experiment until we tried one idea.
Let’s just make the buffer not exist and play the game frame-by-frame.
Each frame we progressed was progress in itself and when we made it to the other side, almost all of us managed to remember to pick up the object on the other end — I inadvertently hit my sword button instead (oops).
What proceeded was pure comedy because once one of us successfully got over, another went and attempted to sabotage everything because it was possible to get away with that now and I found myself and that saboteur at the bottom of the pit.
However, this was no longer a problem as now the boots I had put on earlier were now possible as an option across this pit.
This wasn’t the only obvious latency problem we had to contend with as a prior boss battle during this stream was proving difficult due to a need to time certain actions, but this was the first time we had to adjust the emulation in order to actually make any meaningful progress.
What’s next?
We have a few more streams of this game left with plans for this upcoming Sunday and Tuesday (February 6 and 8, 2022), with the second day being a hopeful completion of what has been a rather fun experience. This will be on authorblues’ Twitch channel.
If you’re interested in watching the past broadcasts, you can view the VODs on Twitch here (I will do my best to update this with the other streams once we are done):
After completing our misadventures, we intend to play Final Fantasy Crystal Chronicles, which is another game I have never played.
This is likely to be after the upcoming Frost Fatales 2022, an all-women speedrunning marathon I contribute my spare time to. I hope you’ll check out as we’re raising money for Malala Fund and lots of talented women will show how fast they can play games!
