[KongchangAI]
Research· 2 min read· 1,026 words

The Art of 16-Byte x86 Assembly: Technical Analysis of Extreme Sizecoding

Research

The Art of 16-Byte x86 Assembly: Techn…

Analyzing the demoscene art of achieving visual effects with just 16 bytes of x86 machine code

This article provides an in-depth analysis of extreme sizecoding art in the demoscene community, using Hellmood's 16-byte production "Wake up! 16b" as a case study. It covers the historical and cultural background of the demoscene, the technical foundations of DOS COM files and VGA Mode 13h, and core techniques for achieving dynamic visual effects within 16 bytes—including register initial state exploitation, STOSB instructions, and bitwise operations for generating fractal patterns.

Introduction

In the world of programmers, there's a group of people who don't pursue feature completeness, but rather the ultimate minimization of code. Sizecoding in the demoscene community is precisely this kind of art form—creating stunning visual effects with as few bytes as possible. "Wake up! 16b" is a demoscene production implemented in just 16 bytes of x86 machine code, created by renowned sizecoder Hellmood. This technical analysis will take you deep into every ingenious design decision behind extreme programming.

What Is a 16-Byte Demoscene Production

The History and Cultural Roots of Demoscene

Demoscene originated in 1980s Europe, initially as a byproduct of the software cracking community. Crackers inserted "crack intros" at the beginning of games to showcase their technical prowess, and these small programs gradually evolved into an independent art form. In the 1990s, as PCs became widespread, the demoscene flourished in Nordic countries (especially Finland, Norway, and Sweden), forming a unique underground cultural circle. Demo parties became the core gathering format, where participants brought their computers for live competition. Events like Revision (Germany) and Assembly (Finland) continue to this day, attracting thousands of developers and artists each year.

In 2020, Finland became the first country to inscribe demoscene on its national intangible cultural heritage list, followed by UNESCO recognition, marking the formal acknowledgment of this digital subculture by mainstream cultural institutions—an extremely rare occurrence for technology-based cultural forms.

Code Creation Under Extreme Constraints

What does 16 bytes mean? Just 16 bytes of machine instructions—fewer than the characters in a tweet—yet they must produce meaningful dynamic visual effects on screen. Under this constraint, every single bit is precious, and programmers need deep understanding of CPU architecture, video memory mapping mechanisms, register initial states, and other low-level details.

The demoscene community views this extreme programming as a competitive art. Contestants showcase their works at international demo parties like Revision and Assembly, where judging criteria cover both the aesthetic quality of visual effects and the cleverness of technical implementation. In sizecoding categories, common limitations include 256 bytes, 64 bytes, 32 bytes, and even 16 bytes—the smaller the size, the higher the difficulty. Some compare sizecoding to "code haiku"—expressing maximum meaning in minimal space—a metaphor widely circulated in the tech community.

Technical Foundation: DOS COM Files, x86 Real Mode, and VGA Mode

To understand these works, you first need to understand the memory model of x86 real mode. Real mode is the original operating mode of the Intel 8086 processor, and modern CPUs still start in real mode at boot. In real mode, memory addressing uses a "segment:offset" 20-bit address model, where physical address = segment register value × 16 + offset, with a maximum addressable space of 1MB. DOS COM files run in exactly this environment: programs are loaded at offset 0x100 of a memory segment (the first 256 bytes are the PSP—Program Segment Prefix), and the CS, DS, ES, and SS segment registers all point to the same segment, forming a "flat" 64KB address space with no need for segment-switching instructions.

These works typically run as DOS .COM files, leveraging several key advantages:

  • Zero file header overhead: COM files have no PE header or ELF header; all bytes are executable code
  • Predictable register initial states: When DOS loads a COM file, SP is initialized to 0xFFFE, BX and DX are set to 0, AX and other registers have known values, eliminating initialization code
  • VGA Mode 13h direct video memory mapping: Provides 320×200 pixels with a 256-color palette, video memory linearly mapped to physical address 0xA0000, corresponding to segment address 0xA000 in real mode, 1 byte per pixel, with total video memory of only 64000 bytes
  • Clever segment register manipulation: By modifying the ES segment register, you can write directly to video memory without calling system APIs

VGA Mode 13h (switched via INT 10h, AX=0013h) is a graphics mode introduced by the IBM VGA standard in 1987. Its linear video memory layout means pixel (x,y) corresponds to video memory offset y×320+x, with no need for complex plane switching (unlike EGA's 4-plane mode). This simplicity makes it the preferred choice for DOS games and the demoscene. The palette consists of 256 RGB triplets that can be programmatically modified through VGA ports 0x3C8/0x3C9. Sizecoders sometimes use palette animation to achieve color changes without redrawing the entire screen—another approach to implementing animation under extreme byte limits.

Core Technical Analysis: How 16 Bytes Generate Images

Clever Exploitation of Register States

Under the 16-byte limit, traditional programming approaches are completely inapplicable. The author leverages multiple tricks in x86 real mode:

  1. Reusing initial register states: When DOS loads a COM file, SP points to the top of the stack and DI has a specific value—these "free" values can directly participate in computations
  2. Instruction encoding length optimization: Choosing the shortest-encoded instruction combinations, such as using stosb (1 byte) instead of mov [es:di], al + inc di (multiple bytes)
  3. Arithmetic operations generating fractal patterns: Performing XOR, shifts, and other bitwise operations on pixel coordinates to generate Sierpinski triangles or interference fringe patterns
  4. Implicit loop structures: Using natural instruction pointer wraparound or the shortest encoding of conditional jumps to implement loops

STOSB: The Power of String Instruction Family

The string operation instructions in the x86 instruction set are a powerful weapon for sizecoding. STOSB (Store String Byte, opcode 0xAA) writes the value of the AL register to the memory address pointed to by ES:DI, then automatically increments DI according to the direction flag DF—the entire operation requires only 1 byte of encoding. Combined with the REP prefix (1 byte), REP STOSB can continuously fill ECX bytes, implementing memset functionality in just 2 bytes.

Related instructions in the same family include STOSW (store word), STOSD (store doubleword), LODSB (load from DS:SI), MOVSB (memory-to-memory copy), and more. The implicit operand design of these instructions (AL/AX/EAX as data source, ES:DI as destination, CX as counter) is creatively used in sizecoding for video memory filling and pixel drawing—key to understanding extremely minimized code.

The Mathematics Behind Fractal Patterns

The Sierpinski triangle commonly seen in sizecoding can be generated with a surprisingly concise formula

#sizecoding#demoscene#x86 assembly#16 bytes#VGA Mode 13h#DOS COM#STOSB
Share:

Related articles