Retro vs. Modern: Designing New MSX Games with a 2023 Twist

It began with a lonely CRT hum and a promise: “Make a new game for MSX that doesn’t feel like a museum piece.” I plugged an original cartridge into an MSX1, booted a disk image in an emulator, and realized the problem was not the machine - it was our imagination.

The MSX is not only silicon and quirks; it’s a voice. If you shout modern design at it, you get an awkward echo. If you learn to speak in its rhythm and then teach it a few new words - save-anywhere, context-aware prompts, subtle branching - the result can be surprising: something that feels authentic and fresh at once.

In this article I’ll walk through why building new MSX games is still worth your time, the technical constraints you’ll respect (and work around), modern mechanics that make sense on MSX, story techniques that fit 8-bit aesthetics, concrete design patterns, development tools and workflows, and a few realistic project plans with trade-offs you should expect.

Why design for MSX in 2023?

Because limitations force clarity. Tight memory and simple graphics focus gameplay and reveal design intent.
Because the MSX community is vibrant - there’s an appetite for well-made homebrew, not just flash-in-the-pan gimmicks. See the MSX community hub at the MSX Resource Center: https://www.msx.org/.
Because doing “retro” well means blending authenticity with the comforts modern players expect - ergonomics, pacing, and meaningful player agency.

If you want to make something that feels like a lost classic, fine. If you want to make a modern experience that happens to run on old silicon, even better.

The hardware you’re courting (short and blunt)

CPU - Z‑80 @ ~3.58 MHz (MSX1 typical). Slow by modern standards, decisive in design.
RAM - many MSX1 machines ship with 64 KB system RAM. VRAM for the VDP (TMS9918 family) commonly 16 KB on MSX1; MSX2 raised capabilities - see
Video - tile-based 8×8 tiles, sprites (TMS9918A supports 32 sprites but only 4 per scanline in MSX1), limited palettes, attribute clash to respect.
Sound - AY‑3‑8910 PSG (MSX1) with optional MSX‑MUSIC (OPL2) on MSX2+/cartridges, plus Konami SCC mapper on some cartridges offers richer sound. See

If you want exact technical specs, treat official docs and emulator pages as your friends: https://openmsx.org/ (emulator and docs), https://www.msx.org/ (community).

Design principle #1: Choose the right truth

There are two distinct goals, and they demand different compromises:

Authentic truth - Make something that could have shipped in 1985. Strictly obey hardware limits (no SRAM saves unless via battery cart), heavy emphasis on score, short loops, difficulty curve.
Modern truth - Use MSX as a canvas for contemporary gameplay and narrative. Add conveniences (save systems, optional text logs, achievements), better UX, and mechanics like procedural events - while keeping the look and sound convincing.

Pick one. You can do both, but don’t pretend your game is “authentic” if you plaster it with modern conveniences and then complain it’s not retro enough.

What modern mechanics make sense on MSX (and how to implement them)

Save systems - Cartridges with battery-backed SRAM or Fordisk save files in emulators let you implement save-anywhere. If hardware prevention matters, use a password system as a middle ground.
- Cartridge SRAM - simplest for real hardware. Emulation-friendly too.
- Passwords - low-tech, elegant, and era-appropriate, but clumsy for large worlds.
Short-term procedural generation - Use deterministic RNG seeded by level or seed code to create variety without big memory costs (e.g., randomized enemy placement within handcrafted rooms).
Quality-of-life HUDs - Minimal, context-aware HUDs that fade when not needed. Use a single tile row for status to preserve resolution.
Metroidvania-lite with sparse maps - Use non-overlapping room tiles and clever reuse to give a sense of scale without consuming VRAM.
Accessibility options - Color-blind palettes and difficulty modes. You can implement palette swapping in a few bytes of code and a table.
Modern combat UX - Intuitive hit feedback, invulnerability frames, and short stun animations. These are cheap CPU-wise and feel polished.
Soft tutorials - Contextual one-line hints (“Press B to…”) shown only the first time. Store a tiny bitmask to remember shown tips.

Storytelling on MSX: less text, more implication

You cannot dump pages of prose on a TMS9918 screen without fatiguing players. So tell stories like a novelist who has only a handful of paragraphs.

Environmental storytelling - Use tile placement, broken scenery, and scaling of a recurring motif to communicate history.
Item-based reveals - A logbook, occasional NPC message, or audio cue (a motif on the PSG or SCC) that triggers when players pick up tokens.
Branching via state flags - Simple boolean flags can unlock different text or endings and fit easily in RAM.

Example: in an MSX RPG-lite, finding the “blue collar” toggles a bit that changes NPC lines and unlocks a different final scene. That’s storytelling economy.

Concrete design recipes (pick one and ship)

Below are three compact recipes that blend retro look with modern feel. Each includes the core idea, constraints, modern twist, and expected development effort.

1) Arcade Reimagined - “Neon Courier”

Core: Fast single-screen runs delivering packages. The arcade feel is authentic; modern twist is meta-progression.

Scope - 8–12 levels, 3 ship upgrades, daily challenge mode via seed.
Limits respected - 1-screen levels, 4 sprites per scanline planning, 8×8 tile reuse.
Modern features - persistent upgrade tree (SRAM), daily seed challenges (deterministic RNG), achievements.
Dev time (small team) - 3–6 months.

Why it works: Short loops reward skill, while meta-progression keeps players returning.

2) Micro-Metroidvania - “Canals of Kerv”

Core: Connected rooms, light backtracking, a few abilities that open new paths.

Scope - ~50 rooms, 4 abilities, map and teleport points.
Limits addressed - Reuse tiles for rooms, store room layouts compressed (RLE/LZ), use palette swaps for variety.
Modern features - Save-anywhere (cartridge or disk-based), minimap overlay toggled, optional accessibility mode.
Dev time - 6–12 months.

Why it works: Controls stay tight; modern conveniences keep frustration down while preserving discovery.

3) Narrative Roguelite - “Sparks of Autumn”

Core: Short runs with a small persistent meta (choices affect later runs).

Scope - Runs ~8–10 minutes each, 10 permanent relics possible.
Limits addressed - Procedural rooms made from handcrafted chunks; music is short loops using PSG with variations.
Modern features - Unlockable narrative fragments, short per-run branching, persistent states via SRAM.
Dev time - 4–8 months.

Why it works: Players get a modern ‘run-and-improve’ hook compatible with retro presentation.

Asset pipeline: how to create art, audio, and code that plays nice with MSX

Pixel art - Work in 8×8 tiles. Keep character sprites to 16×16 or 24×24 using multi-tile composition. Respect sprite per-scanline limits - plan composite sprites and fallback for overlap.
Palettes - For MSX1 (TMS9918A), colors are limited and attributes cause clash. Design with limited shared background colors. Consider MSX2 only if you need higher resolution and more colors.
Tile maps - Use a tile atlas and a small compression step. Many homebrewers implement RLE or LZ variants to save VRAM.
Sound - Compose short loops and motifs for PSG. Tools like DefleMask can compose AY tunes and export data:

Tools to use:

Compiler/toolchain - SDCC (Small Device C Compiler) for C along with asm for performance-critical sections:
Assemblers - pasmo, WLA-DX (classic for Z80):
Emulators - openMSX and blueMSX for testing on various MSX flavors:
Music trackers - DefleMask for AY and SCC; other tools exist in the MSX community.

Memory and performance heuristics (not a spec, but realistic budgets)

System RAM - target 64 KB compatible baseline. If you require MSX2 features (more VRAM, better VDP), state it clearly.
VRAM - aim for < 16 KB tile usage on MSX1; move tiles dynamically when necessary.
Sprites - keep important actors as sprites; background decor should be tiles.
CPU - optimize collision and AI; keep expensive loops in assembly and schedule background tasks over multiple frames.

Tiny example budget for a Micro‑Metroidvania on MSX1:

Room tileset - 4 KB (tileset banked or swapped per area)
Map data - 8–12 KB compressed (RLE)
Sprite frames - 3–4 KB (compressed)
Music & SFX - 1–2 KB patterns + player code
Game code & variables - remaining ~40 KB (code, game state, compression routines)

These are ballpark numbers; your mileage will vary with engine choices.

UX matters: modern ergonomics that cost almost nothing

Instant feedback - flash sprite, small sound bite on hit.
Soft checkpoints and quick restarts (fade out, don’t make players see the loading screen more than once).
Contextual prompts, not a wall of text.
Accessibility - palette choices and difficulty toggles.

These features improve retention and perception far beyond their technical cost.

Testing on hardware vs emulator: the timeline

Prototype early on an emulator for iteration speed (openMSX has good debug tools).
Test on real hardware frequently - the MSX quirks (timing, sprite clipping) will bite late and ruin surprises.
If you plan to publish a physical cartridge, test with a flash cartridge and confirm SRAM behavior.

Release formats and community expectations

ROM image for emulators (.rom or .rom.gz)
Disk image (.dsk) if targeting floppy users
Cartridge - homebrew cartridges for collectors (requires a small manufacturing run)
Physical packaging - lovingly fetishized in the scene - good box art and manual are a selling point.

Community platforms: share development logs on MSX.org and itch.io (there’s a welcoming retro community there). Many recent homebrews publish their source or tools so others learn and contribute.

A brief postmortem checklist (what you’ll wish you’d done before shipping)

Did you test sprite overlap on real hardware?
Is the save system robust under power-off conditions?
Are sounds short but expressive? Do they loop without getting annoying?
Does the game communicate goals within the first 2 minutes?
Can players finish a meaningful play session in 15–25 minutes?

If the answer isn’t a confident yes, iterate.

Case studies & inspiration

Look at recent MSX homebrews and the design decisions they made. The MSX community page and forums list many new projects: https://www.msx.org/.
For sound composition, DefleMask and tracker threads from the scene offer reusable patterns: https://www.deflemask.com/.

Final verdict: how to choose your fight

If you want to make a truly retro title, embrace the cruelty of the original constraints and make a game that feels like a device of its era. If you want a modern, accessible experience that runs on MSX hardware, choose a narrow set of modern conveniences and be explicit about what you add and why.

Either way, respect the machine and the player. The best new MSX games are those that wear their constraints like a costume, then reveal a modern mind underneath - a game that nods to the past but refuses to be trapped by it.

Stop apologizing for the platform. Use its voice. Then teach it a small vocabulary it never had.