donno2048/snake: A 54-byte x86 DOS Game

Why donno2048/snake reduces Snake to 54 bytes

donno2048/snake solves a deliberately narrow problem: fitting a playable Snake game into the smallest possible x86 binary. It is for code-golf readers, x86 assembly programmers, DOS enthusiasts, and people interested in the relationship between machine code size and the instructions available on early hardware. It is not presented as a general game framework or a development foundation.

The repository identifies the result as a 54-byte compiled binary and says that it fits into a single QR code. Its size comparison places this build at 54 bytes, compared with MattKC's roughly 1,400 bytes when compressed, ibara's 2,024 bytes, and EimaMei's 2,953 bytes. Those figures describe binary footprint, not gameplay quality or ease of maintenance. The README describes the project as an exploration of extreme binary-size optimization on x86.

The motivation is explicit: create the smallest fun game possible, inspired by MattKC's question about fitting a whole game into a QR code. The repository also distinguishes this implementation from jinX's snake64. According to the README, donno2048/snake uses the arrow keys, while jinX's snake64 uses `4`, `6`, `8`, and `2` and has different startup and screen requirements. Those constraints define the project's code-golf target more precisely than a feature checklist does.

The result is striking mainly because the scope is narrow. A 54-byte game leaves almost no room for explanatory metadata, conventional error handling, or a source layout designed for modification. Binary size is the central engineering objective, so readability and extensibility are secondary considerations.

The 16-bit real-mode architecture behind the tiny binary

The project is written in 16-bit x86 assembly and assembled with NASM. It runs in DOS real mode and is described as compatible with all x86 CPUs, although the README includes an important qualification. Some processors may not support `salc`, or `aam` and `aad` with argument values other than `0x0A`, because those forms were documented later. The source must therefore be inspected if behavior on a particular CPU matters.

The README publishes the complete binary as hexadecimal:

c57800b80a20
9992cd105b89
fc00cc96300c
7af9bed007e4
60f6ead414d5
44989301c301
f0ab103074e3
7b890c29d675
fa5e883479de

Those bytes encode the entire program, so there is no room for a conventional high-level runtime. The README does not provide a detailed architecture explanation beyond the language, execution mode, assembler, controls, and limitations. It also does not document a rollback procedure, a formal test suite, or a compatibility matrix for DOS environments. A line-by-line account of every instruction and screen update would therefore go beyond what the repository documents.

The QR-code presentation makes the size constraint tangible. The README says the binary fits in one version 4 QR code encoded with `qrencode`. This does not mean the QR code is the execution format. The normal online demo is tied to `snake.asm` and updates through GitHub Actions, while the QR image represents the unusually small compiled artifact.

A separate project, `snake-bios`, requires neither a BIOS, bootloader, nor operating system. That is a different target, not a feature of donno2048/snake itself.

Playing the online build and serving snake.asm locally

The least complicated first use is the online demo. The README says it updates for every change to `snake.asm`. Open the project homepage at `https://donno2048.github.io/snake/`, wait for the game to appear, and use the arrow keys. On a PC, the documented `pause` control pauses and resumes play. On mobile, the documented interaction is a swipe.

The repository also provides scripts for local hosting. The README gives `main.sh` for Unix-like environments and `main.bat` for Windows. It does not show their contents, dependencies, or supported interpreter versions, so those details should not be assumed. After running the appropriate script, open the documented local URL:

http://localhost:8000

On Unix-like systems, the README's direct instruction is to run `main.sh`:

main.sh

On Windows, the corresponding repository entry is `main.bat`:

main.bat

The expected result is a local server serving the demo at `http://localhost:8000`. The README does not document how to stop either script or which network interfaces they bind to, so it does not support claims about server exposure or cleanup behavior. For ordinary play, the hosted demo avoids assembly-toolchain setup. The local route is more useful when the reader is following changes to `snake.asm` and wants the same GitHub Actions build path without relying on the public site.

Input rules and constraints that shape the game

The control scheme is compact in the same way as the program. The README specifies arrow keys for movement and the keyboard `pause` key for pause and unpause on PC. Mobile users use a swipe. The repository's comparison with jinX's snake64 also identifies arrow-key control as one of the behavioral distinctions claimed for this version.

Snake has clear boundaries in this implementation. The README attributes the right-to-left but not top-to-bottom passage behavior to jinX's snake64, so that contrast should not be treated as a specification of donno2048/snake's boundaries. The comparison section describes the snake's size in pixel units, but the README does not provide a complete rule set for growth, food generation, collision, scoring, or termination. Those rules should not be inferred merely from the game genre.

The README contrasts the compared implementations over startup conditions. It says jinX's version can place up to 30 food items at once, may turn random pixels white, accepts `4`, `6`, `8`, and `2` for movement, must start by moving downward, requires the screen to be cleared, and requires the correct video mode to be initialized ahead of time. Those points are presented as reasons why the projects do not follow identical restrictions. They are useful context for judging this implementation's code-golf class, but they are not a complete specification of donno2048/snake.

For adoption, testing the exact DOS environment matters more than reading a conventional user manual. The README does not document which DOSBox configurations work, how timing behaves on slower systems, or whether keyboard behavior is identical across compatible machines.

Why snake.asm is the wrong base for a normal game

The strongest limitation is visible in the project's purpose. A 54-byte binary is an optimization result with a deliberately constrained environment. It is the wrong base for a normal game application that needs documented source structure, settings, accessibility support, score persistence, replay behavior, or portable installation across operating systems.

The source is available as `snake.asm`, but the README does not provide a line-by-line explanation of the program. It does not document a build command, assembler flags, linker settings, or verification procedure beyond saying that NASM is used. Consequently, reproducing the exact binary is not fully specified by the README alone. A developer who changes one instruction may alter instruction availability, timing, input handling, or the final binary size.

Hardware compatibility also has a documented edge case around `salc`, `aam`, and `aad`. The README's statement that the game is compatible with all x86 CPUs includes that warning, so broad compatibility should not be interpreted as unconditional support for every later processor without checking the actual instructions.

The project is also not a substitute for a conventional engine if the goal is cross-platform deployment. Its execution model is DOS real mode, while the mobile interaction is handled by the web demo rather than by a native mobile implementation in `snake.asm`. This distinction matters when deciding whether the project is an artifact to study, a program to run in DOS, or a codebase to extend.

Comparing the DOS program with the BIOS-only alternative

The repository directly names `snake-bios` as an alternative with a different boot contract. According to the README, that version requires no BIOS, bootloader, or operating system. donno2048/snake, by contrast, is described as a minimal x86 assembly game for DOS and runs in real mode. The distinction is the dependency boundary: one project targets a DOS environment, while the other aims to operate below those layers.

That makes the choice depend on the environment being studied. `snake-bios` is the relevant comparison for low-level environments that omit DOS. donno2048/snake is the relevant choice for examining a 54-byte DOS real-mode implementation and its web demo. The README does not provide the alternative's byte size, source explanation, controls, release history, or compatibility notes, so no broader ranking between the projects is justified.

The four-entry comparison table also shows why code size should not be treated as a general quality score. MattKC's entry is roughly 1,400 bytes compressed, while the other listed versions are measured in the thousands. donno2048/snake is smaller, but the table contains no evidence that it offers more features, better graphics, broader hardware support, or easier maintenance. Its adoption case is specifically its tiny footprint.

The comparison should also be read narrowly. A compressed figure and an uncompressed figure do not necessarily represent identical packaging, so the numbers illustrate project-specific scale rather than a universal performance ranking. For this repository, the documented achievement is the unusually small DOS binary and the web demonstration that makes it accessible without assembling it locally.

Maintenance signals, releases, and MIT licensing

The repository is not archived, and the last push was on 2026-10-03. That is a recent repository change, but recency does not establish that the program has a conventional maintenance workflow. The release history lists v32 on 2025-10-22, v31 on 2025-01-12, and v30 on 2024-12-06. The README does not describe release notes, compatibility changes, or a policy for future releases.

The repository's update workflow is tied to the online demo: the README says the demo updates for every change to `snake.asm`, with deployment through GitHub Actions and hosting through GitHub Pages. Local hosting uses Python according to the technical details, but the repository entries do not include a dependency file or a documented Python version requirement. An evaluator should not assume that local setup and the hosted deployment are identical.

The project is distributed under the MIT License. That identifier records the repository's declared license, but the README excerpt does not reproduce the license text, and no legal interpretation should be inferred from the short summary alone. For a code-golf project, the main maintenance cost is likely to be found in preserving the exact size constraint, checking instruction compatibility, and documenting changes that affect boot assumptions or input behavior. The README does not quantify that cost.

Upgrading this project is also not equivalent to adopting a normal dependency update process. The repository records releases, but it does not document semantic versioning, migration notes, or a compatibility promise for existing DOS machines. Those omissions matter to anyone planning to distribute a modified build.

Editorial conclusion

donno2048/snake is suitable for readers studying extreme x86 code-golf, operating systems history, and tiny binary artifacts, while it is a poor fit for developers seeking documented controls, conventional source explanations, portability guarantees, or a maintained game engine. Before adopting its code, verify the exact boot and hardware assumptions for the target DOS environment, inspect `snake.asm` for instructions you can audit, and confirm that the MIT license satisfies your distribution requirements. For this project, the deciding fact is that its 54-byte footprint is inseparable from its low-level DOS constraints.

Frequently asked questions

Official sources

1. donno2048/snake on GitHub
2. License: MIT
3. Project website
4. README
5. Releases