If you’ve followed my previous adventures, you know that coding on MO5 is… intense ;)

Between tools from another era, hardware constraints that are not always well documented, and different behaviors between emulator and real hardware, I spent quite some time fighting my environment.

At some point, I realized something simple: I was spending more time fixing my tools than coding my game, and that is frustrating.

The real problem

At first, I thought the problem came from the MO5: old machine, strong constraints, makes sense.

But in reality, the problem mostly came from me: I was developing like in 1985… in 2026

manual installation, hacked scripts, blind debugging

While today we have: cloud, automated pipelines, AI capable of writing code

There was clearly a mismatch.

From hacking to a real SDK

So I made a radical decision: stop hacking things together, and build a proper foundation

I grouped everything I was doing into an SDK.The goal was not to build a perfect library, just something that hides hardware complexity, avoids common pitfalls, allows focusing on the game.

For example, all video handling is encapsulated. No need to manipulate memory banks or the $A7C0 register directly.

You initialize the screen, wait for VBL, and draw.

mo5_video_init(COLOR(C_BLACK, C_BLACK));
while (1) {
    mo5_wait_vbl();
    // logic + rendering
}

Simple 😉

Sprites without headaches

Where I really saved time is with sprites.

Between MO5 constraints, color handling and VRAM, things get messy quickly.

So I built several levels: simple sprites on solid background, transparent sprites on a scene, sprites with background save (dirty rectangle).

The dirty rectangle mode is probably the most interesting (but also the most expensive in terms of performance). Before drawing, we save the area, then restore it on the next frame.Result, sprites can overlap without artifacts, and that on MO5 is really not trivial.

The real hack: assets

The biggest productivity gain actually comes from something very simple: stop drawing sprites by hand.

I wrote a script that converts a PNG into a directly usable C structure.

And most importantly… I generate my sprites (well, the images) with Claude.

I ask Claude to generate an image (with constraints), I pass it through the script, I compile, and the sprite appears on screen.

Without worrying about memory format, color constraints, or VRAM layout.

Honestly, it feels a bit like magic 😉

The lazy template

Then I tackled another problem.

👉 installation

Because reinstalling cmoc, lwtools and friends on every machine is a no.

So I built a template + Codespaces.

make setup-codespace
make install
make

And that’s it.

environment ready, binary generated, disk image ready

All of this inside GitHub Codespaces.

AI that finally understands the MO5

At first, I was using AI like everyone else.

I asked questions, it answered… more or less correctly.

The problem is that it does not understand MO5 constraints.

So I did something a bit different: I plugged a MCP server with a RAG behind it.I injected my SDK documentation, 6809 constraints, and my own notes.

👉 now the AI no longer guesses👉 it knows

And that changes everything.

And now?

Well… this is all nice… but the real question is:

👉 does it actually work?

That’s what I’m going to test (actually, at the time I’m writing this, I already did 😉).

I’m starting a series of videos to build a complete game step by step.

A small classic shoot’em up, with a ship, enemies, bullets, a score.

Starting from scratch.

Just with the template, the SDK… and a bit (a lot) of AI 😉

Conclusion

I never thought I would say this one day.

But today… coding on MO5 is becoming almost modern!

And most importantly, it’s becoming really fun 😉