Zero-Code Project: Building a Tetris Game on a Microcontroller with Cursor + Claude

Introduction: The Era of AI-Written Code Is Here

While we're still debating whether AI can replace programmers, someone has already used AI to implement a complete Tetris game on a microcontroller — without writing a single line of code. This isn't a concept demo; it's a fully functional game running on real hardware, complete with block rotation, movement, accelerated dropping, line clearing, and scoring.

bilibili source: Not writing a single line of code, letting AI build a game on a microcontroller

This article provides a detailed breakdown of the process, examining just how far AI programming tools can go in the embedded development space.

Hardware Preparation and Project Setup

Hardware Configuration

The hardware used for this project is remarkably simple:

Microcontroller board: STC8H learning board (24MHz clock)
Display: 0.96-inch OLED screen, 128×64 resolution, SSD1306 driver chip
Communication: SPI interface
Input devices: 4 buttons mapped to IO ports P3.2, P3.3, P3.4, P3.5

Pin connections: CS→P5.4, RST→P4.4, DC→P6.0, SCLK→P4.3, MOSI→P4.0.

The STC8H series is an enhanced 8051-core microcontroller from STC Micro. It uses a 1T (single clock cycle) architecture, which provides approximately 8-12x faster execution at the same clock frequency compared to the traditional 12T 8051 architecture. A 24MHz clock is more than sufficient for a Tetris game that doesn't require high real-time performance. The 8051 architecture dates back to the 1980s and remains one of the most classic architectures in embedded education and industrial control. Its simple instruction set, rich peripherals, and mature development tools keep it relevant today, with many new chips still based on this architecture. The STC8H series integrates hardware SPI, I2C, multi-channel ADC, and other peripherals, enabling direct driving of various sensors and displays without external chips.

The SSD1306 is an OLED driver controller manufactured by Solomon Systech, widely used in small-format 128×64 resolution OLED screens. It has built-in display memory (GDDRAM) of 128×64 bits (1KB), where each bit corresponds to the on/off state of a pixel on the screen. The microcontroller simply writes frame buffer data to the GDDRAM via SPI or I2C, and the SSD1306 automatically scans and drives the OLED panel. The SPI interface is faster than I2C (up to 10MHz clock), making it suitable for game applications that require frequent screen refreshes. The DC (Data/Command) pin distinguishes between display data and control commands — a critical detail in SSD1306 driver development.

Base Project Setup

The author started with a nearly empty Keil C51 project, retaining only the most basic framework: an empty main function and a config.h header file configuring the 24MHz clock. After compilation passed with zero errors and zero warnings — this was the starting point handed to the AI.

Keil C51 is an integrated development environment for 8051 series microcontrollers provided by ARM (now part of Analog Devices), including a C compiler, assembler, linker, and debugger. It generates Intel HEX format files — an ASCII text-based binary image containing address and data information for the program code. STC microcontrollers use serial ISP (In-System Programming) for flashing, downloading hex files to the chip's Flash memory via USB-to-serial using the STC-ISP tool software, without requiring a dedicated programmer. This significantly lowers the development barrier. The entire flashing process takes only a few seconds, and combined with AI's rapid code generation capability, it enables an extremely short "modify-compile-flash-test" iteration cycle.

The Complete AI Programming Process: From Requirements to Running Code

First Conversation: Describing Complete Requirements in Natural Language

The AI tool used was the Cursor editor in Agent mode, with Claude 3.5 as the underlying model.

Cursor is a deeply customized AI-native code editor based on VS Code, developed by Anysphere. Its Agent mode differs from ordinary code completion or chat modes — the Agent has autonomous planning capabilities, can proactively read project files, understand project structure, create new files, execute terminal commands, and perform multi-step reasoning based on context. This means developers can provide high-level task descriptions, and the Agent will independently decompose them into specific coding steps and execute them one by one. The Claude 3.5 Sonnet model performs exceptionally well on code generation tasks, consistently ranking at the top of benchmarks like SWE-bench, with strong understanding of C language and embedded development scenarios.

The first step was having the AI read the existing code. It quickly identified this as a Keil C51 project for the STC8H microcontroller, targeting the 8H4K64TLCD chip, with an essentially empty application layer.

Next, the author described the complete requirements in natural language:

"I want to implement a Tetris game using this microcontroller learning board and a 128×64 resolution OLED screen. The driver chip is SSD1306, four buttons correspond to P32/P33/P34/P35, communication is via SPI interface..."

The key point: you must clearly specify the hardware connection information. The AI doesn't know which interface or which pins you're using — this physical-layer information must be provided manually.

AI's Code Generation Process

After receiving the requirements, the AI executed the following steps:

Confirmed that the existing library had SPI interface and button-related implementations
Planned the code structure: SSD1306 driver, button debouncing, block collision detection, line clearing and scoring, main loop
Implemented all code directly in main.c

The entire process took about ten minutes. The AI generated complete code including rotation states for all 7 block types, collision detection, lock-and-clear logic, and score display. Compilation result: zero errors, zero warnings, hex file generated directly.

After downloading to the microcontroller, the game ran immediately — blocks fell normally, left/right movement and rotation worked perfectly, and there was even a score display.

Iterative Optimization: Polishing Game Experience in Three Rounds

Round Two: OLED Display Rotation Optimization

The initial version had a game area that was too small because the 128×64 screen is landscape-oriented, while Tetris is better suited for portrait display. The author requested:

"Rotate the main display 90 degrees clockwise, making the game area fill the entire screen as much as possible."

The AI understood and changed the rendering coordinates to a virtual portrait screen, then mapped it to the physical screen with a 90-degree clockwise rotation, enlarging cells to fill the 10×20 game area. The display improved significantly after the modification.

The technical implementation involves virtual frame buffers and coordinate transformation: a 64×128 virtual frame buffer (width 64, height 128) is established at the software level, game logic runs in the virtual coordinate system, and after rendering is complete, the entire frame buffer is rotated 90 degrees clockwise before being written to the SSD1306's GDDRAM. The transformation formula is: physical coordinates (x_phys, y_phys) = (virtual_y, virtual_width - 1 - virtual_x). This approach requires attention to memory usage on resource-constrained microcontrollers — a 128×64 frame buffer requires 1024 bytes of RAM, which is a significant but acceptable portion of the STC8H's 4KB RAM.

Round Three: Button Sensitivity and Debounce Tuning

During testing, button presses were found to be unresponsive, with rapid presses going undetected. After feedback, the AI changed the input system to stable debouncing with auto-repeat on hold:

Auto-repeat begins after holding beyond a set threshold
Repeat interval approximately 30-70 milliseconds
Left/right movement supports continuous movement on hold

Mechanical buttons produce bounce during press and release — the voltage level fluctuates multiple times within a few milliseconds. Without handling, the microcontroller would misinterpret this as multiple presses. A common software debounce method is to wait 10-20 milliseconds after detecting a level change and then sample again to confirm. The auto-repeat mechanism borrows from PC keyboard design: after a key is held beyond a certain duration (typically 200-500 milliseconds), it enters repeat mode, continuously triggering key events at a fixed interval (30-100 milliseconds). This is particularly important in Tetris — players need to hold direction keys to quickly move blocks to target positions. Without auto-repeat, each movement requires repeated tapping, severely degrading the gaming experience.

Round Four: Accelerated Drop Experience Optimization

The long-press auto-repeat worked great for left/right movement, but the accelerated drop experience was poor. The author requested that the down key use the exact same auto-repeat mechanism as left/right movement. After the AI's modification, accelerated dropping finally achieved a smooth feel.

Advanced Operations: Screen Swap and Code Refactoring

After video recording was complete, the author performed two more important iterations:

Switching to an I2C larger screen: A larger screen with an I2C interface was swapped in. After telling the AI the new driver chip model and interface type, it automatically modified the driver code while keeping all other game logic unchanged. I2C (Inter-Integrated Circuit) is a two-wire serial bus protocol requiring only SDA (data line) and SCL (clock line) for communication. Wiring is simpler than SPI, but transfer rates are typically lower (100kHz standard mode, 400kHz fast mode). The AI's ability to correctly handle the driver layer switch from SPI to I2C demonstrates its understanding of hardware abstraction layer design principles — decoupling upper-level game logic from lower-level communication protocols.
Multi-file code refactoring: The initial version had all code crammed into a single main.c. The author asked the AI to reorganize using a multi-file structure — drivers in a Driver directory, business code in an APP directory. After refactoring, the code structure was clean, compiling with zero errors and zero warnings.

Key Insights: Capabilities and Boundaries of AI in Embedded Programming

What AI Can Do in Embedded Development

This case demonstrates several important capabilities of AI programming tools in the embedded domain:

Can directly generate compilable microcontroller code, including low-level drivers and application logic
Can understand hardware constraints, generating correct IO operations based on pin configurations
Can perform iterative optimization, adjusting parameters based on real-world testing feedback
Can perform code refactoring, organizing file structures according to engineering standards

It's worth noting that these capabilities depend on a prerequisite: the 8051/C51 ecosystem has decades of open-source code accumulation, and SSD1306 drivers, Tetris algorithms, and similar implementations are abundantly available on the internet. Large language models have "seen" massive amounts of similar code during training, enabling them to correctly combine and adapt code for specific hardware configurations. For more obscure chips or proprietary protocols, AI performance may be significantly diminished.

The Human Role Hasn't Disappeared

Although not a single line of code was written manually, the author did several things AI cannot replace:

Determining the hardware solution and wiring
Accurately describing requirements and hardware parameters
Actually flashing, testing, and providing feedback on issues
Judging whether the experience meets standards

This reflects a new paradigm of human-AI collaboration: humans handle "perception and judgment in the physical world," while AI handles "implementation and optimization in the digital world." Many issues in hardware debugging (such as signal interference, timing violations, cold solder joints, etc.) still require humans to troubleshoot using oscilloscopes, multimeters, and other tools — areas that AI currently cannot touch at all.

How Much Did Development Efficiency Improve?

The author estimated that writing this Tetris game manually would take at least three days, with no guarantee of completion. Using AI from scratch to finish took about half an hour, and including subsequent optimizations, no more than one hour. This isn't a 10% efficiency improvement — it's an order-of-magnitude difference.

From a broader perspective, this efficiency gain could have profound implications for the embedded industry. The traditionally high barrier to embedded development (requiring simultaneous mastery of hardware principles, low-level drivers, communication protocols, and application algorithms) has long limited the innovation speed of makers and small teams. AI tools are dramatically lowering this barrier, enabling hardware engineers who "have ideas but limited coding ability" to rapidly validate prototypes.

Conclusion

This case proves that AI programming tools already possess the capability to independently complete medium-complexity projects in the embedded domain. For developers, the core competitive advantage is shifting from "being able to write code" to "being able to describe requirements, validate results, and think systematically." Tools are evolving, and the way we use them must evolve accordingly.

Key Takeaways

Using Cursor (Claude 3.5 model) in Agent mode, the AI generated complete Tetris game code in approximately 10 minutes through natural language requirements description, compiling with zero errors on the first attempt
The key is accurately providing hardware information: chip model, pin connections, communication interfaces, and other physical-layer parameters that AI cannot obtain on its own
Through 3-4 rounds of iterative dialogue, display rotation, button sensitivity, and long-press auto-repeat optimizations were completed, with the entire process taking no more than 1 hour
AI also handled advanced tasks like screen adapter switching and code refactoring, demonstrating strong engineering comprehension
The human role has shifted from writing code to requirements description, hardware decisions, real-world testing validation, and experience judgment