The Game Boy As You Have Never Seen It Before Is Newest From [Sprite_tm]

Explain a Game Boy to a child in 2021 and they’ll have little idea of how much impact that chunky grey brick had back in the day. Search for a YouTube video to demonstrate, and you might find the one we’ve put below the break. It starts with the classic Tetris on the Game Boy, then moves on to Super Mario World before treating us to Sonic the Hedgehog, and finally Doom. All seminal games of the Game Boy’s heyday, with one small problem. The last three were never Game Boy titles, and certainly wouldn’t have run on the device’s limited hardware. Most of you will by now not be surprised to find that the narrator is none other than [Sprite_tm], and his Game Boy has one of the nicest Raspberry Pi conversions we’ve ever seen.

Given his previous work we expected the cartridges to have an ESP32 on board that  somehow mapped into Game Boy display memory, but in fact he’s swapped the original Nintendo motherboard with a replacement carrying an ICE40 FPGA on one side to handle the Nintendo hardware and a Pi Zero on the other to do the heavy lifting. Insert a Game Boy cartridge and it emulates the original to the point you’d never suspect it wasn’t the real thing, but insert one of the non Game Boy cartridges and it passes an identifier to the Pi which launches a script to run the appropriate Pi code. So the Mario and Sonic games are running in Pi-based emulators, and Doom is running natively on the Pi. It gives the appearance of a seamless gaming experience, wherein lies its charm.

This project certainly has the quality we’ve come to expect from Sprite, and a quick flick through these pages will show plenty of previous examples. One of the most recent was a miniature working DEC VT100 terminal containing an emulated PDP minicomputer.

16 thoughts on “The Game Boy As You Have Never Seen It Before Is Newest From [Sprite_tm]

  1. now this is a hack worthy of hackaday.

    I’m looking to do something similar with an AMSTRAD ALT-286, the technique of temporal dithering the screen to smooth and improve the contrast will probably also work for my case.

    1. The CPU of the gameboy isn’t fast enough for that. Best it could do was “faceball 2000”. The GPU of the gameboy is also not very good at those kinds of graphics. As it’s tile based.

      Common misconception is also that the gameboy CPU is a Z80, it is not. It’s an upgraded 8080, which some opcodes that look like Z80 opcodes. Closest we have been able to find is that it’s a SM83. But that does mean some optimizations that speed up Z80 code are not available.

      Finally, development for the gameboy is alive and well! If you want to know more: and if you want to learn it, it’s the best time to start, as there is a GB Compo starting tomorrow:

      And the discord is a great place to learn about everything. Including emulator development. We’re still finding unknown quirks in the gameboy that are not properly emulated.

      1. Is it really important if it is based on z80 vs 8080? The z80 also implemented the 8080 instruction set, so it seems unimportant of a detail. The Sharp CPU in the GB included some features that were in the z80 but not in the 8080 so it seems accurate to say it is more z80 than it is 8080. But either way your overall point is not wrong, its z80’esque since it is an application specific CPU.

          1. If the goal was to port the TI version of Doom to a GameBoy, I cant imagine it would be an unrealistic goal. Unless someone made a more advanced TI Doom, I remember it being not much different looking than FaceBall. It was just a simple raycast game with Doom sprites. It definitely was not an accurate port of Doom, at least not enough to say that the TI-83 could “run Doom”.

        1. Then me, and the whole GB development community is wrong? It’s not anywhere near a Z80, as it lacks the indexing registers, which are pretty important for the Z80. It’s closer to the 8080 then the Z80.

  2. This is hilarious. I remember how bad the LCD screens were back then. Low contrast and ghosting issues galore. But we managed because we didn’t know anything better than that. Kudos on interfacing with that and then running things like Doom on it for the laughs.

    1. There were better alternatives at the time. GameGear and Atari Lynx were around, its just that they were too expensive, required a lot of batteries and would chew said batteries up in a couple of hours. The GB was huge because it was extremely affordable and had decent power economy because of its low hardware specs.

      1. Oh yeah, I had a Game Gear too, later in the 90s when someone was getting rid of theirs cheap. I knew of the Lynx but never actually saw one. There was also the portable version of the TG16. They all used the color lcd tech that used a lot more power.

        Lots of the monochrome LCDs of the time had the same issues as the Gameboy.

    2. Interesting to note is that the Original GB screen was 4 colour, one of those simply being off so just 3 shades of “green”. Sprite_tm’s FPGA driver actually manages to use PWM trickery to get 16 shades of green from a 4 shade display by actually leveraging the fact the refresh rate is low. If you look there are far more “colours” on Doom, Sonic and SMW that are possible on that display with native hardware drivers.
      This is interesting because it could have been done back in the day I imagine with little cost increase and only a slight variation on the driver. So in theory, the original GB was under performing as far as the screen went.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.