10

Emulation these days is well supported for loads of systems, and I understand that original Game Boy and Game Boy Colour are comparatively simple to emulate. Retro gaming is also pretty popular at the moment, and so it seems reasonable there is demand for people who want to emulate link cable sessions over wifi. (Surely me and my friend are not the only people currently playing Pokemon Red and Blue?)

Given how seamless it is to download an emulator and boot up a ROM, I inferred that it would be similarly simple to trade pokemon by Wifi. I was surprised to find out that this seems not to be the case. Retroarch natively supports netplay for local multiplayer, for example on the SNES, but my reading tells me that it doesn't support netplay for Game Boy link cable sessions. Searching "gameboy emulate link cable wifi" in google and youtube gives me a bunch of links for how to set up a link cable by loading two different sessions emulating gameboys at the same time on one machine, for example using TGB dual, but doesn't give me any hits for wifi support. So I'm wondering if there's some obstruction that makes it difficult.

Firstly then, did I make a wrong assumption? (maybe my searching wasn't extensive enough and this is supported somehow, or maybe people are just not interested in this, although I find that hard to believe)

And if I didn't, then my question is: What's the obstruction that makes it difficult to emulate GB/GBC/GBA link cable support by wifi?

I could imagine a setup where, user A has rom RA, with save file SA and user B has rom RB with save file SB. A sets themself up as the server, and B as the client. The emulation session sends RB and SB to A. A emulates two gameboys under the hood, running RA with SA on one and RB with SB on the other. Only the the RA session is displayed to A, and then A sends the sound and audio of the RB session back to B, and polls B for controller inputs. Any time the game is saved A sends SB back over to B, and A deletes their copy of RB and SB at the end of the session.

I'm pretty certain that this setup would require roughly the same coding as the session which runs two gameboys on the same machine to emulate link cable, combined with whatever retroarch does for its SNES netplay. Maybe there is a better solution than this, but implementing what I described seems straightforward and indicates that there probably isn't a technical problem with emulating link cable play, unless it would be too slow in practise? Or maybe there's some kind of legal issue?

[I'm currently disabled and unable to work, and my experience is mostly in scientific programming. I'm not asking anyone to do this, just trying to scope out the problem. Please don't tell me to code it myself]

Improve this question
9
  • 4
    You can read how the link cable protocol works: <gbdev.io/pandocs/Serial_Data_Transfer_(Link_Cable).html>. Basically, it’s (a variant of) an SPI link, and as such it is going to be very sensitive to latency, especially in undocumented-but-relied-on corner cases that are rampant on older platforms. The two CPUs pretty much have to run in lockstep. I highly doubt that an unreliable, medium-to-high-distance link like a wireless Internet connection is going to deliver latency low enough to let both emulators run smoothly in sync. Though for Pokémon trades, it may be just good enough.
    – user3840170
    Commented Jun 10, 2022 at 18:36
  • Thanks for the link I'll have a look. I thought that latency might be a problem in emulating the two systems separately. Would it be a problem for the setup I described? In my mind, emulating two gameboys that link up on a single machine is already a solved problem and can't be too much more resource intensive than emulating a SNES, and if the latency for local SNES multiplayer over WiFi is ok then my solution should also work for the link cable?
    – Jojo
    Commented Jun 10, 2022 at 18:46
  • 1
    There’s still the latency of getting the inputs back to the core which actually processes them, the latency of transferring screen buffers, the latency of transferring emulator state (even if just once)… synchronising the CPUs only would actually be comparatively lighter. For me it looks like you’d either have to put up with input lag or choppy emulation as the cores sync up their clock counters.
    – user3840170
    Commented Jun 10, 2022 at 19:02
  • 2
    Your idea should work. It's a bit expensive but it does sidestep the core problem. As you say, it's doable with two emulators running in tandem on the same machine, so if you can do a stop-the-world state sync before and after, the concept is workable.
    – hobbs
    Commented Jun 11, 2022 at 2:05
  • 1
    @Joe retroarch's netplay is Magic™. Basically it relies on the fact that we can emulate a system like the gameboy much faster than realtime, so when it gets an input state change from the remote player that's n frames old, it rewinds the emulation state by n frames, gives it that input, then runs things forwards again and displays the result to the local user, all within a single frame, effectively sending the lagged input "into the past". Under reasonable assumptions, it works quite well.
    – hobbs
    Commented Jun 12, 2022 at 19:33

2 Answers 2

Reset to default
11

Cariad Keigher's Adventures with an 11,000 kilometre-long Game Boy Advance link goes into detail on how timing-sensitive the protocol is to establish context for a story about emulating both sides of the link:

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.

However, the first link in that quote is a blog post specifically of interest to your question: An 8-bit Idea: The Internet of Game Boys by Matt Penny.

In early May, my friend @aidancrowther and I came across an incredibly cool video by hardware hacking YouTuber stacksmashing. For his latest project he’d created an adapter to connect an original Game Boy to a PC via the link cable peripheral, along with a web server which could host multiplayer Tetris games by bridging that connection. This combination allows players to face off in competitive block stacking match-ups over the internet with original hardware!

Improve this answer
1
2

I have carefully read Retroarch NES/SNES/etc netplay spec. Unfortunately, it is not what you thinking about.

To be exact, they not exchange state between two NES/SNES machines, they emulate ONE machine, just sending pad presses over internet.

And to make copy, just run two or more emulators with same random seed, so they behave absolutely same.

So for GB this should be emulate two (or more) GBs connected with GB-link in one emulator

This is not impossible, just few times more resource hungry than one GB emulation.

And second question - will be two GB roms on each machine. As I know, NES does not have any rom inside, all programs are in cartridges, it simplifies legal questions, but GB is next generation, as I hear, it have it's rom, etc.

Improve this answer
12
  • I edited your post to add a link to the netplay spec. My idea will work; both systems emulate both gameboys
    – Jojo
    Commented Jun 12, 2022 at 11:12
  • "ROM" in this context refers to a specific type of chip inside the cartridge, containing read-only data and executable code.
    – wizzwizz4 ♦
    Commented Jun 12, 2022 at 17:52
  • ROM in my answer mean legal issue. This is interest nuance, that when some tech made as hardware, it is typically easier to copy considering legal matters, than if same thing is software.
    – Serge Sergeev
    Commented Jun 13, 2022 at 12:45
  • In case of NES/SNES, all cartridge ROMs are like books. - It is old case, judge decided very long time ago, that you could give book to any other person, license prohibit to read one book for more than one person at once, but it accept to read it with shift.
    – Serge Sergeev
    Commented Jun 13, 2022 at 13:01
  • there is no fundamental difference between a game boy game card and an NES cartridge — each consists of ROM chips containing code and data, potentially some RAM to augment the system or to hold game saves, and possibly a memory management controller for mapping ROM into the address space. They are one and the same regarding legal issues, and the issue is "the code and data are copyrighted, so you generally can't distribute copies" whether GB, NES, SNES, or anything else
    – Fox
    Commented Jun 14, 2022 at 2:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .