Game dev & streaming

Retro Game ROM / RAM Budget Calculator

Free retro game-dev calculator for GB Studio / NESmaker / Genesis homebrew. Inputs: target system, sprite tile count, background maps, audio tracks, code lines. Outputs: color-coded ROM gauge, bank-boundary warnings, optimization tips.

Built and maintained by Paul Clark, Redmoon Software

When to use this

Use when prototyping a homebrew retro game in GB Studio, NESmaker, or SGDK. Surface the budget problem before you build it.

How it compares

Compiler error messages tell you after the fact. This tool warns you during planning.

Enter your values below. Calculations run locally as you type.

Project

System Sprite tiles Background maps Audio tracks Lines of code

ROM budget

Used

37.1 KB

115.9% of 32 KB

Remaining

0.0 KB

Over capacity — strip background maps or compress audio.

How it works

Bytes used ≈ tiles × 16 + maps × 1024 + audio tracks × 4096 + code × 4. A coarse but useful planning estimate.

Each system has a fixed ROM capacity — Game Boy 32 KB, NES 128 KB, SNES 1 MB, Genesis 4 MB.

Above the ceiling? Bank-switch your tilesets or compress your audio.

FAQs

How does the estimate work?

Tiles × 16 bytes, maps × 1 KB, audio × 4 KB, code × 4 bytes/line. It's a planning estimate, not a compiled-binary calculation.

Why do GB tilesets have a ceiling?

Game Boy VRAM holds ~384 tiles. Above that, you must bank-swap or share tilesets across screens.

What is a bank-boundary warning?

Older cartridge systems split ROM into fixed-size banks (often 8KB or 16KB), and code or graphics cannot freely cross a boundary without bank-switching logic. The warning flags when your content is about to overflow the current bank.

How much ROM did these systems typically have?

Original Game Boy and NES cartridges commonly ranged from 32KB up to a few hundred KB, while Genesis cartridges scaled into several megabytes. Homebrew tools like GB Studio often impose tighter limits than the hardware maximum.

Worked example

Input

Game Boy (32 KB), 200 tiles, 8 maps, 6 audio tracks, 500 lines of code.

Output

~37 KB used — over budget!

200 × 16 (tiles) + 8 × 1024 (maps) + 6 × 4096 (audio) + 500 × 4 (code) = 35,392 bytes — already over the 32 KB cartridge limit.

Common pitfalls

Heuristic byte counts — real bytes depend on compression and tooling.
Bank switching adds capacity but introduces code complexity.
Doesn't model VRAM (separate from ROM) — Game Boy VRAM is the more common bottleneck.

Cartridge budgets were brutally small

The system sizes here are the real ones: 32 KB for an original Game Boy cartridge, 128 KB for NES, 256 KB for Game Boy Color. Those are kilobytes — a single modern PNG routinely exceeds an entire NES game.

That constraint shaped everything about how those games look. Tile reuse, small palettes, mirrored sprites and procedurally repeated level layouts were not aesthetic choices first; they were what fit. Budgeting a homebrew project against these figures is the fastest way to understand why the era looks the way it does.

Where the space actually goes

Graphics and audio dominate, and audio is the one that surprises people. Sampled audio is impossible at these sizes, which is why the era used sequenced music driving a sound chip — the data is a list of notes and instrument definitions rather than a waveform, and it is orders of magnitude smaller.

Code is usually the smallest of the three. Compression and bank switching both extend the budget, at the cost of decompression time and considerable complexity in the memory map, which is a trade every cartridge of the period was making explicitly.

Related tools