Hello from the 8 by 8 grid

This is the first Retroable Dev Blog post, so I should probably introduce myself before discussing video RAM. I’m Christian Göbert-Golle. I run Retroable through Gnomish Tinkers UG, a small company where “the team” currently means me.

Retroable exists because I’ve always loved computers and video games equally. More specifically, I wanted to make games for old consoles long before I had any practical way to do it. Now I’m building the way in that I wish I’d had.

The kindergarten Apple II department

I’ve been attached to computers since I was a small kid. In kindergarten, I was the child who looked after the Apple II computers. The other children played. I made sure the machines worked.

This may have been an early warning.

I later became a programmer and a cyber security expert, which is what happens when the child guarding the computers is allowed to continue unsupervised. I learned how systems are assembled, how they fail and how small assumptions can become large disasters. Old consoles are particularly honest about all three. Their limits aren’t vague suggestions. If you exceed a hardware limit, something disappears, corrupts or refuses to fit. The machine does not schedule a meeting about it.

But games were always the other half. As a kid, I could play Game Boy games, study them and imagine my own. I couldn’t build one. The tools and knowledge weren’t available to me in a form I could use. There was a solid wall between having an idea and holding a working game.

That wall is the part I’m interested in removing. You can read a little more about me on the About page, although I promise the Apple II incident remains the main piece of evidence.

Why Retroable exists

My aim with Retroable is to share that combined love of computers and games, without requiring you to become a programmer first. You should be able to make a game for an old console whatever your technical skill or budget. You can arrive with a few sentences and no idea what video RAM is. The hardware will still impose its rules, but you shouldn’t need years of specialised knowledge before you’re allowed to meet them.

The Codex, Retroable’s retro gaming encyclopedia, is free. I want the explanations of these machines, their games and their constraints to be available whether or not you create anything. Knowing why a sprite vanishes is useful. It is also a fine way to discover that a machine from decades ago can still reject your creative decisions with complete confidence.

There’s another reason I’m doing this. What Retroable earns, after the cost of keeping the site online, goes towards Continue?, a modern family arcade I’m saving for. Continue? is the longer plan: a place where families can play together and where the machines are there to be used rather than admired from a safe distance.

For now, Retroable is the part I can put in front of you. You bring the idea. I deal with the old hardware’s objections.

From a sentence to a Game Boy ROM

I started with the original Game Boy because its limits are hard, few and well documented. A clear box is a good box to build in. It gives every decision a visible cost, which is useful for the machine and even more useful for the person making their first game.

The basic box looks like this:

• A screen measuring 160 by 144 pixels
• Four shades
• A CPU running at about 4.19 MHz
• 8 KB of work RAM
• 8 KB of video RAM

Everything shown on that screen is built from 8 by 8 pixel tiles. The Game Boy can have at most 40 sprites at once. Only 10 sprites can share one horizontal line before the hardware drops some of them. This is where ambitious character line-ups go to die.

Memory has another hard edge. Bigger games cannot fit into the available address space all at once, so the cartridge switches memory banks in and out. Think of it as keeping the whole game in a filing cabinet while the CPU is allowed to open only the drawer it currently needs. Bank switching gives a game more room, but it adds rules about where data and program code live. More space is not the same thing as no limits. The corpse has a larger coffin.

From the player’s side, the process begins with a few sentences. You can optionally add a sketch. Then you approve concept pictures for things such as a splash screen, a menu and a scene. These pictures let you check the direction before the hardware gets its little square teeth into everything.

And it will. The concept pictures are not the game. They must be turned into tiles that obey the four shades and the 8 by 8 grid. Curves become stepped edges. Details compete for pixels. Two areas that looked distinct may collapse into the same shade. Showing you what the hardware forced is, in my opinion, more honest than hiding the conversion and pretending nothing was lost.

The game itself is a real program written in C for the real hardware. It is compiled into one `.gb` file. That file is the ROM. It isn’t a video of a game or a picture pretending to be interactive. It is the program the Game Boy runs.

Before you see the result, the ROM is played automatically to check that it starts, shows its screens and reacts to button input. This matters because a successful build process can still produce a useless game. A file existing on disk is not proof that the title screen appears or that pressing a button does anything. Software is generous that way.

If a build fails before the ROM exists, its credits are returned. A failed attempt should not be mistaken for a finished game merely because several complicated steps happened in the vicinity.

Once the ROM works, the same `.gb` file plays in the browser on the game page, downloads to your device, runs from a flash cartridge in a real Game Boy and can be ordered as a cartridge with a printed box. One file crosses all of those cases. I like that. There is very little room for hand-waving when the final test is putting the program into the original machine and pressing the power switch.

Game Boy Color came next. It keeps the same 160 by 144 screen and the same kind of file, but adds real color palettes. The ROM remains bootable on an original Game Boy. That compatibility creates another useful boundary: color can improve the presentation, but the game still has to survive on the older machine.

The main lesson so far is my opinion rather than a law of nature: hardware limits make better first games than unlimited engines. Limits reduce the number of decisions and make each remaining decision concrete. Four shades is a problem you can see. An infinite list of possible visual styles is fog.

I also think a working ROM beats a pretty promise. The full path deserves more space than I can give it here, so it has its own post: How a sentence becomes a ROM. The short version is less romantic: every attractive picture eventually has to answer to an 8 by 8 grid.

What I’m planning for November 2026

The next items are planned for November 2026. They are not shipped yet. I prefer that sentence to the more traditional approach of quietly letting a future feature wear a fake moustache and pose as a current one.

NES and SNES game development and generation are coming. They have different CPUs, different cartridge designs and different limits. I’ll document those constraints in the same way as the Game Boy: what the machine can do, where it refuses and what those facts mean for the game you’re making.

The Retroable Android app is also planned to launch in November. It will let you play your games, create new ones, keep your collection and read the Codex on your phone. The goal is straightforward: the same work should remain useful when you’re away from a desktop.

Retroable is independent of Nintendo and Sega, and their trademarks belong to their respective owners. The machines provide the rules. They do not provide an endorsement, which is probably sensible.

The next boxes to document are the NES and SNES. They have different ways to say no.