WiFi Game Boy Cartridge

Summary

Sebastian embarks on a unique project to create a WiFi-enabled Game Boy cartridge, exploring how old-school hardware interacts with modern technology. Faced with challenges like the Game Boy’s slow 1MHz memory speed and limitations of microcontrollers, he develops a hacky solution using logic gates and custom programming. The project involves overcoming issues with power supply, memory bus contention, and interrupt handling. Despite being a complex and advanced build, Sebastian successfully creates a functional WiFi cartridge that can access resources like Wikipedia. This project demonstrates the intersection of retro gaming and modern engineering.

Takeaways

• 😀 Sebastian created a WiFi Game Boy cartridge as a fun and experimental project, even though it's not particularly practical.
• 😀 The Game Boy's screen and cartridges, once considered sophisticated, are actually very outdated by modern technology standards.
• 😀 After finding his old Game Boy, Sebastian was curious about how the cartridges worked and decided to create his own.
• 😀 Despite numerous Game Boy mods, no one had successfully created a working WiFi cartridge before Sebastian's project.
• 😀 Other projects added WiFi through different methods (e.g., a WiFi link cable or wireless controller), but none used a cartridge with WiFi functionality.
• 😀 Sebastian's research revealed that even powerful modern microcontrollers, like the ESP32, couldn't handle the Game Boy's low-speed memory bus without difficulty.
• 😀 The key challenge of the project was handling the Game Boy's 1MHz memory cycle while keeping the modern microcontroller focused on WiFi tasks.
• 😀 Sebastian's solution involved dedicating only two memory addresses to the microcontroller, allowing the Game Boy to handle most tasks with an EEPROM while the ESP8266 managed WiFi and other functions.
• 😀 Interrupts weren't fast enough to handle the memory bus, so Sebastian programmed the Game Boy to tolerate slower responses from the microcontroller, including repeating memory requests.
• 😀 The project requires advanced skills, including soldering SMD components, programming the ESP8266 without a dev board, and debugging with an oscilloscope.
• 😀 Although the system is functional, it's prone to issues like power instability, memory corruption, and data line contention, making it a risky and fragile hack.

Q & A

What inspired Sebastian to create a WiFi Game Boy cartridge?

Sebastian was inspired to create a WiFi Game Boy cartridge after finding his old Game Boy in his parent's attic. He wanted to understand how Game Boy cartridges worked and wondered if he could make his own, particularly adding WiFi functionality.

Why did Sebastian think the Game Boy screen was 'absurdly bad'?

Sebastian realized that the Game Boy's screen was much worse than he remembered from his childhood. This reflection came from his current perspective on technology, where the outdated display stood out in comparison to modern devices.

What made the Game Boy cartridges so fascinating to Sebastian as a child?

As a child, Sebastian was fascinated by the Game Boy cartridges because, unlike other devices like records or cassettes, they had no moving parts and were simply plugged into the Game Boy via electrical connections. This made the cartridges seem sophisticated and superior.

What is the 'hubris of the man from the future' concept that Sebastian refers to?

The 'hubris of the man from the future' refers to the idea that modern, fast microcontrollers (like the ESP32) should be able to easily handle the Game Boy's simple 4MHz operations. However, Sebastian points out that it was more complicated than expected, as even modern microcontrollers couldn't keep up with the Game Boy's memory bus timing.

Why did Dave's ESP32 project to add WiFi to the Game Boy fail?

Dave's project failed because the ESP32, despite its higher clock speed, wasn't fast enough to emulate the Game Boy's memory bus timing. The Game Boy operates at a much slower 1MHz clock speed, and its operations require very precise and quick responses, which the ESP32 couldn't deliver.

What were the limitations of using interrupts to handle Game Boy communication?

Using interrupts to handle communication was limited because even though interrupts can trigger responses when the Game Boy signals a read or write request, the ESP8266's interrupts were too slow. Additionally, the Game Boy constantly spams the memory bus, even when accessing its internal RAM, making it difficult for the microcontroller to handle other tasks like maintaining WiFi connectivity.

How does Sebastian's design solve the issue of slow interrupts?

Sebastian's design tackles the slow interrupt issue by not trying to run old Game Boy games on the cartridge. Instead, he programmed his own software to handle the communication. He allows the Game Boy to send garbage data at the start of each read attempt, which triggers an interrupt, and then the microcontroller sets the correct data for the next read attempt.

What is the purpose of the EEPROM in Sebastian's design?

The EEPROM in Sebastian's design acts as the main memory for the Game Boy. It handles most of the memory requests from the Game Boy, freeing the microcontroller to only deal with requests at specific memory addresses (0x7ffe and 0x7fff). This helps prevent the microcontroller from being overwhelmed by constant memory requests.

What challenges did Sebastian face with the power supply of the Game Boy when adding WiFi?

Sebastian encountered issues with the Game Boy's power supply, which was not designed to handle the increased power demand of the ESP8266 when it activates WiFi. This caused memory corruption and brown-outs, especially if the batteries weren't fresh. He speculates that using a larger capacitor might help stabilize the power supply.

What advice does Sebastian offer for anyone trying to build a similar WiFi Game Boy cartridge?

Sebastian advises that building a WiFi Game Boy cartridge is an advanced project requiring skills like soldering SMD components, programming microcontrollers, and working with EEPROMs. He also mentions the need for an oscilloscope for debugging and warns that the system is fragile, with components potentially competing for access to the data bus, leading to instability.