Limits

The O8 machine is finished hardware, and hardware has a face. These are all the limits, in one place — and the argument for why they are the product, not the price of it.

The machine, complete

Cart payload is 32KB total; the code budget is what remains after the sprite sheet, map, sfx, flags, and music sections take their fixed shares. The editor enforces the limit — you cannot save an oversized cart — and the size is bytes of UTF-8, not characters.

The code budget is a design tool

Eleven kilobytes is roughly 300 to 600 lines of Lua, formatted like a human wrote it. The seed cart bro — a complete platformer with music, a timer, lives, coin blocks, and a flagpole — is 248 lines, under 6KB. That is the calibration point: the budget is not something you fight, it is the size of a finished small game.

When code does run short, the standard squeezes, in order of respectability: delete dead branches, fold repeated logic into functions, shorten identifiers, and only then get terse. Half the charm of small-cart culture is reading a dense cart and finding it clean.

Instructions, not milliseconds

There is no fast or slow code on O8 — there is only within budget or over it. The machine counts 4,000,000 Lua instructions per frame; go over and the frame fails deterministically with instruction budget exceeded, identically on every host. A cart that fits on your laptop fits on a phone, on the CI runner, in ten years. There is no performance portability question because there is no performance — only the count.

Practical shape: a full-screen redraw of 128x128 pixels through Lua pset will not fit; the drawing calls (spr, map, rectfill) are native and will. Draw with the API, compute in Lua.

Determinism is the feature

The contract: (cart bytes, input log) -> frames + state hash is bit-identical across the tested engine targets. Same cart, same inputs, same hash — your machine, my machine, the browser, the CLI, a CI job in 2036.

That single property buys the rest of the platform:

• Replays and verified speedruns for free — an input log is a

walk-through, and the hash proves it.

• Agent authorship you can trust — a bot builds a cart, runs it

headless, and the hash is a receipt. See the agent guide.

• No save-state corruption, no version drift, no "works on my

machine". The corpus, the machine's permanent test suite, pins the behavior with golden hashes on every push.

Randomness is part of the deal: rnd is a seeded xorshift, so a cart's dice rolls replay exactly. srand(seed) at the top of _init is how you make a roguelike verifiable.

Compatibility

O8, O16 and O32 are separate machine profiles within one host. Their fixed limits are part of the design. The project is currently pre-release; a final 1.0 freeze has not been published.

The compatibility goal is stable cart decoding and covered machine behavior. Existing golden expectations remain pinned; new tests extend coverage. Host fixes, browser changes and any future specification correction still require compatibility review. See support and limits for the current product scope.

Working inside the box

Every limit above has a well-worn technique on the other side of it:

• 128 sprites: flips and pal recolors instead of variants; sspr

sub-rectangles of larger art.

• 128x64 map: cell values are bytes — reuse a tile as ground, wall,

and hazard via sprite flags (fget) instead of new art.

• 4 channels: music and sfx share them; music patterns hold slots on

their channels, sfx() lands on free ones.

• 27KB user RAM: poke/peek arrays; 256 bytes of cartdata for

saves; strings in code space when RAM is tight.

• 16 colors: pal(c0, c1, 1) screen remaps re-tint the whole frame —

night, underwater, hit-flash — at zero budget cost.

The first game guide, the graphics guide, and the audio guide demonstrate each of these in running code. The API reference is the complete inventory — one page, no more surface than that.