TIS-100 costs $15 and an install. This one is just a link.

Feed it [2, 3, 4] and it wants [2, 5, 9] back, the running total after each number. Here is a program that passes:

loop:
  ADD IN       ; ACC += the next input value
  MOV ACC OUT  ; emit the total so far
  JMP loop

Three instructions, eight cycles, which happens to be this level's documented minimum. You can also read the input into ACC with a separate MOV first, or leave a stray NOP in the loop, and it still passes, it just runs longer and the score screen tells on you. Closing that gap, on level after level, is the entire game.

What it is

Signalworks is a browser puzzle game for people who love TIS-100 and EXAPUNKS. You get a tiny chip, a small real assembly instruction set (MOV, ADD, SUB, JMP, JEZ, JNZ, NOP, plus IN/OUT ports and one ACC register), and a puzzle that defines an input stream and the output you have to produce. You write the program, run it one cycle at a time, and watch the value hop across the board. When your output matches, you pass, and your score is the number of cycles it took. Lower is better.

The reason it exists is a gap. Those assembly-golf games are some of the best puzzle games ever made for programmers, and every one of them is a paid, installed desktop app. There is no version you can hand a friend as a link and say "try this one level, right now, in your tab." The visual block-coding toys fill the beginner gap, but they are not the real thing: no registers, no cycle counting, no assembly. This is the real thing, minus the Steam purchase.

Why the score is honest

The whole appeal of cycle golf is that the score is a single hard number, and that only works if the number never wobbles. So the CPU is deterministic: exactly one instruction per cycle, no pipeline, no cache, no wall-clock timing anywhere. The same program always takes the same number of cycles and emits the same sequence. Eight cycles is eight cycles on your laptop and on mine, which is what makes "beat my score" a fair challenge instead of a benchmark you have to run five times and average.

There is a small free trick baked into that model, too: the program counter wraps past the last line on its own, so in the right shape of program you can drop the trailing JMP and pocket the cycle it would have cost. Details like that are why the debugger ships with the first puzzle rather than as later polish. Watching ACC, PC, and the cycle count tick over, with the active instruction lit up in the trace, is how you actually see where your cycles are going.

Proving it always stops

Jumps mean a player can write an infinite loop, and the game has to run that code every time you hit Run. A cycle-accurate VM that hangs the tab on a bad JMP loop is worse than useless. You cannot decide in general whether an arbitrary program halts, that is the halting problem, so Signalworks does not try. The CPU carries a documented step limit: past the bound it stops and reports, instead of spinning forever.

The part I like is how that guarantee gets tested. The assembler and CPU are pure, DOM-free TypeScript, so the suite uses fast-check property tests that generate random token soup, run it through the assembler, and assert that whatever comes out, the CPU always terminates. Not "these three example programs halt" but "no program we can generate runs past the limit." Fuzzing your own interpreter to prove it cannot hang is the kind of thing you set up once and then stop worrying about.

Try it

The first level is a single instruction, MOV IN OUT, so you are running real code inside ten seconds. Solve a few, then go back to one you already passed and try to knock a cycle off. When you beat your best, the win screen hands you a share link that encodes the score with no backend behind it. The source is on GitHub if you want to see how the assembler and VM fit together.