How to make a Neo Geo game

What the hardware asks of you

The Neo Geo is a 1990 arcade board: a 68000 at 12 MHz for the game, a Z80 at 4 MHz that does nothing but sound, and a 320×224 screen in NTSC (320×256 in PAL). Three of its habits shape every project.

• Everything visible is a sprite. There are no scroll layers in the usual sense — backgrounds are sprites too, so a “decor” and a “character” are the same kind of object, and each band can scroll at its own rate. But a sprite is a 16-pixel-wide vertical strip, a character costs several chained together, and the hard limit is 96 sprites per scanline — transparent pixels included. A full-width background band spends 20 of them. Parallax is free in shape, not in budget.
• Colour comes in fifteens. Palettes hold sixteen entries and entry 0 is transparency, so you draw with fifteen. There are 256 palettes to spend across a whole stage. More on palettes.
• Sound is a real chip with a real budget. Four FM channels, three SSG, six sample voices for drums and one for streamed audio. More on the YM2610.

Two routes, and how to pick

Write C against ngdevkit. Damien Ciabrini’s ngdevkit is a complete open-source SDK: a gcc cross-compiler for the 68000, hardware headers, a sound driver, graphics tools and a debugger. You install it, build the examples, and go from there. It gives you everything and asks that you know C and the hardware. A large share of recent Neo Geo homebrew is built this way.

Use an editor. Paint scenes, place actors, wire the rules visually, and let the tool emit the code. You trade some control for a much shorter path from an idea to something you can play. This is the route Sprixe Neo Studio takes — and what it emits is ngdevkit C, so the two are not opposed so much as stacked.

The honest deciding question is not which is better but what you want to spend your attention on. If the hardware is the project — if you want to know why a raster effect costs what it costs — write the C. If the game is the project, an editor gets you to a playable stage in an afternoon.

The parts you will end up making

• The program itself, compiled to a 68000 binary — the P-ROM.
• Sprites, as 16×16 tiles packed into the C-ROM — the format.
• A fix layer of 8×8 tiles for text and the HUD — the S-ROM.
• A sound program for the Z80 — the M-ROM — and samples for the YM2610, in the V-ROM.
• Palettes, which have no ROM region of their own: they are data inside the program, written into palette RAM while the game runs. Plan them anyway — they are level design, not an export setting.

Everything but the palettes lands in the five ROM regions that make up a cartridge. That is the moment the project stops being files on a disk and becomes a game.

Getting it running

Develop against an emulator — MAME is the reference, and it is a good one — then move to hardware when the thing is worth the trip. A NeoSD flashcart takes a .neo file straight from the card, so the last mile is a file copy rather than a burn.

Two things reliably surprise newcomers: an emulator will refuse to boot without a system BIOS, which is separate from your cartridge, and a homebrew ROM can ship with the open nullbios instead of anything owned by SNK. Neither is a bug in your build.

What to expect

It matters more that this gets read accurately than that it gets read encouragingly.

• The audience is small. People who own an AES or an MVS are a fraction of the retro scene, and the hardware is not cheap. Build for the Neo Geo because you want to, not because it is the widest door.
• The documentation is scattered. There is no single manual. Much of what is known lives in emulator source, in forum threads, and in the heads of a few dozen people.
• The constraints are the fun part. Fifteen colours and four FM voices are not obstacles between you and the game — on this machine they are most of the style.