Shenzhen I O Walkthrough

Getting Started with Shenzhen IO

Shenzhen IO is a programming puzzle game by Zachtronics that simulates writing embedded firmware for fictional microcontrollers. You receive schematic diagrams, component datasheets, and task requirements. Your job is to write assembly code that makes the hardware do what the spec sheet says. It is not a conventional game with narrative or hand-holding. You figure it out by reading documentation and testing. A proper walkthrough needs to address more than just solving puzzles. The game teaches you its own instruction set through trial and error, and most people hit the same walls. The core challenge is managing limited RAM, understanding timing constraints, and working with the simulated bus architecture. The game gives you a manual. It is dense and intentionally vague in places. You will reread it multiple times. I spent roughly forty hours on the early campaigns before things started clicking. The breakpoint between "this is impossibly abstract" and "I understand what is happening" usually comes after you solve the seventh or eighth challenge. Before that point, you are guessing. After it, you are reading the problem differently.

The game ships with a built-in assembler and debugger. You write code in its proprietary assembly language, then simulate it running on virtual hardware. The debugger lets you step through instructions one at a time, inspect register values, and watch I/O pins change state. This is your primary debugging tool. Do not skip learning how to use it efficiently. Set breakpoints, not single-stepping through every instruction. One thing beginners consistently miss: the eval function. You can write arbitrary expressions in your assembly code using eval syntax. This is not just a convenience. It fundamentally changes how you approach problems. Instead of calculating values at runtime, you precompute them at assembly time. A loop that runs a hundred iterations and does arithmetic in each cycle becomes a single constant value. This cuts execution time dramatically and frees up RAM for actual logic. Another counter-intuitive detail involves the chip pricing model. The game charges you based on chip cost, power consumption, and code size. Many players optimize purely for functionality first, then try to shrink the solution. That second phase is where most people fail. You should be considering cost and power from the start because the constraints shape the architecture. A solution that fits within the budget often requires a completely different approach than a brute-force working solution.

Here is a specific problem I ran into during the third act. I was building a UART transmitter that needed to handle variable-length strings with proper framing. The naive approach used a lookup table for baud rate calculations, but the table itself consumed too much memory. The workaround was to use eval to compute the timing constants at assemble time instead of storing them as data. I wrote a small Python script that generated the assembly constants from my preferred baud rates, then pasted them into the program. This reduced my code size from around two hundred words to under eighty, which dropped the chip cost enough to pass the evaluation. The community aspect matters more than the game itself. The forums and Discord servers have extensive documentation that the base game does not provide. People have mapped out every instruction's cycle cost, documented edge cases in the simulator, and shared techniques for common patterns like state machines, ring buffers, and protocol implementations. The official manual treats some behaviors as obvious. They are not obvious. Common pitfalls worth noting upfront. First, the simulator does not model electrical behavior accurately. Signal bounce, noise, and timing overlap are not simulated. If your solution depends on precise nanosecond timing between two peripherals, it will likely fail in practice even if it passes the game's tests. Second, the memory model is simpler than real embedded systems. There is no cache, no DMA, and no interrupts in the traditional sense. Designing for this environment means accepting limitations that do not exist in actual hardware development.

For those who find the puzzle structure too rigid, the game includes a sandbox mode where you can connect any components and test arbitrary configurations. This is where most of the actual learning happens. Build a simple peripheral. Write a driver for it. Test it against another piece of hardware you designed. This mirrors real embedded work better than the campaign challenges do. If you want a downloadable reference guide, the community-maintained instruction set reference at shenzhenio.zachtronics.com covers every opcode with timing data. It is not official documentation, but it is more detailed than what the game provides. The game itself does not include a direct download link for external resources, but the built-in manual exporter creates a PDF you can reference offline. The campaign contains approximately thirty challenges across four acts, each introducing new hardware components and constraints. Act one covers basic GPIO and simple sequencing. Act two introduces timers and interrupts. Act three adds UART and SPI communication. Act four combines everything into multi-chip systems. The difficulty curve is steep but fair. Each new concept builds on the previous ones, though the later challenges assume you have internalized concepts from much earlier in the game.

My recommendation for approach order: complete the campaign in sequence without skipping, use the sandbox freely alongside it, read the community references when you are stuck rather than guessing, and keep a notebook of patterns you discover. Writing down why a particular approach worked or failed saves significant time when you encounter similar problems later. The patterns repeat with different constraints.