A arte dos 16 bytes: como o código x86 cria áudio e vídeo infinitos

No universo do desenvolvimento de software contemporâneo, onde frameworks modernos exigem centenas de megabytes de memória RAM apenas para exibir uma interface simples, existe uma comunidade global que caminha na direção oposta, buscando a máxima eficiência nos menores espaços físicos possíveis. Em maio de 2026, na pacata cidade de Ommen, nos Países Baixos, a famosa Outline Demoparty serviu de palco para o lançamento de uma criação que desafia as leis convencionais da otimização de software. O programador conhecido no meio da computação retrô como HellMood apresentou ao mundo "Wake up!", uma obra de arte digital minimalista codificada em apenas 16 bytes de código assembly x86.

A produção é uma exploração profunda de densidade algorítmica aplicada ao hardware clássico compatível com a arquitetura original do IBM PC. Capaz de gerar gráficos infinitos baseados na geometria do fractal de Sierpinski e, simultaneamente, sintetizar áudio síncrono diretamente pelo alto-falante interno do computador (o clássico PC Speaker), o programa demonstra o poder extremo do desenvolvimento em nível de máquina. Para HellMood, que iniciou sua jornada na programação há mais de 30 anos em um computador IBM com monitor verde monocromático, a criação representa a realização de um desejo de infância e o ápice de 15 anos de dedicação ao cenário da demoscene, período no qual desenvolveu mais de uma centena de pequenas criações chamadas de intros.

Inspirado pelo trabalho de outro desenvolvedor conhecido como Plex, que lançou a extraordinária intro de 16 bytes chamada "Rainbow Surf", HellMood decidiu resgatar rascunhos matemáticos antigos e esquecidos para dar vida a este novo projeto. O resultado é um exemplo extremo de síntese multimídia onde som e imagem estão matematicamente integrados, permitindo que o usuário literalmente "veja o que está ouvindo" na tela do computador. Sob o codinome de "16 bytes que transformam o som de Sierpinski em chuva de Matrix", a demonstração tornou-se um marco instantâneo para a preservação de técnicas históricas de computação.

A cultura do sizecoding

O sizecoding é uma disciplina altamente especializada dentro da demoscene, na qual o objetivo principal é produzir o impacto visual e sonoro mais impressionante possível utilizando limites de armazenamento extremamente restritos. Com categorias que variam de 256 bytes a meros 16 bytes, esses desafios exigem dos desenvolvedores um conhecimento cirúrgico do processador, dos registradores de memória e do mapeamento físico de hardware. Para fins de comparação, uma imagem digital comum de smartphone ocupa milhões de bytes; condensar um sintetizador e um motor gráfico completo em 16 bytes exige uma engenharia que beira o impossível.

Para economizar cada bit de informação, os programadores de sizecoding utilizam truques pouco ortodoxos que seriam banidos de qualquer ambiente de desenvolvimento comercial moderno. Entre essas táticas estão o uso de instruções assembly polimórficas — como a instrução add [bx+si],al, codificada em hexadecimal pelo byte nulo 0x0000 — e a execução de saltos lógicos diretamente para o meio de outras instruções já existentes, permitindo reutilizar opcodes de máquina como se fossem novos comandos ou variáveis de dados. Essa exploração direta do hardware remove qualquer barreira de abstração intermediária entre a mente do desenvolvedor e o silício da CPU.

Análise técnica das instruções

Para decifrar o funcionamento de "Wake up!", é necessário analisar individualmente as instruções que compõem seus 16 bytes de código assembly x86 executados em modo real do sistema operacional DOS. A listagem completa de código revela uma economia impecável de recursos:

• int 10h (2 bytes): Executa a interrupção de vídeo padrão do BIOS do computador para configurar o sistema no modo de vídeo 0. Essa instrução redefine a tela para um modo de texto limpo de 40 colunas por 25 linhas, preparando o canvas digital.
• mov bh, 0xb8 (2 bytes) e mov ds, bx (2 bytes): Estas instruções associadas apontam o registrador de segmento de dados (ds) para o endereço de memória física 0xb800, que armazena diretamente o buffer de memória de vídeo de texto CGA/VGA.
• lodsb (1 byte): Carrega o byte localizado no endereço de memória apontado pelo registrador de índice si para o acumulador al, incrementando automaticamente o registrador si logo em seguida.
• sub si, byte 57 (3 bytes): Subtrai o valor 57 do registrador si. Combinada com o incremento de 1 byte gerado pela instrução lodsb anterior, esta operação resulta em um recuo líquido de exatamente 56 bytes a cada iteração, fazendo com que o programa leia e escreva de trás para frente na memória RAM do computador.
• xor [si], al (2 bytes): Realiza uma operação lógica Ou Exclusivo (XOR) entre o valor contido no endereço apontado por si e o acumulador al, atualizando os dados diretamente na memória de vídeo.
• out 61h, al (2 bytes): Transmite o valor atual de al diretamente para a porta física de hardware 61h, que controla o alto-falante interno do sistema.
• jmp short L (2 bytes): Cria um loop infinito de desvio que faz com que o fluxo do processador retorne continuamente à etiqueta L, mantendo o programa em execução perpétua.

O ponto de partida lógico do programa depende diretamente de como a memória de vídeo é limpa pelo BIOS após a execução da interrupção int 10h. Em computadores compatíveis com o padrão IBM PC, a limpeza de tela do modo de texto não insere zeros absolutos na memória de vídeo. Cada célula da tela de texto é estruturada em dois bytes: o código de caractere ASCII correspondente e o seu respectivo atributo de cor de exibição. O processo padrão do BIOS preenche todos os 2.000 slots da tela com o caractere de espaço (0x20) sob o atributo de cor cinza-claro sobre fundo preto (0x07). Essa organização de memória limpa, mas pré-populada com padrões regulares, atua como uma tela inicial estruturada que serve de base para as operações matemáticas que se seguem.

O funcionamento da matemática

A base algorítmica de "Wake up!" baseia-se na geração de somas de prefixos aditivos que, sob certas condições matemáticas, revelam estruturas geométricas autossimilares. Para ilustrar o conceito na matemática puramente abstrata: se imaginarmos um estado de memória inicializado inteiramente com zeros, usarmos somas simples (add) no lugar do operador lógico xor, avançarmos 16 bytes a cada passo e assumirmos que o acumulador al comece com o valor de partida 2, podemos desvendar a raiz matemática do software.

Um segmento padrão do DOS em modo real possui exatamente 65.536 bytes de comprimento. Ao nos movermos por passos de 16 bytes, o programa executa exatamente 4.096 iterações para atravessar o segmento inteiro (visto que 65536 dividido por 16 resulta em 4096), ponto no qual o registrador si sofre um estouro aritmético e retorna automaticamente ao início (no endereço 0x0000). Como o número total de passos é um múltiplo perfeito de 256 (a capacidade de armazenamento de um registrador de 8 bits), os valores que sobram de cada ciclo de varredura se alinham com precisão matemática, redefinindo o valor de al para 2 no início de cada varredura espacial de memória.

Os valores numéricos de acumulação de células seguem uma sequência baseada em coeficientes binomiais escalados pelo valor 2, descrita formalmente através da relação matemática:

A^(p)[k] ≡ 2 * binomial(k+p, p-1) mod 256

No entanto, a mágica visual e sonora acontece quando substituímos a soma aritmética convencional pela operação lógica XOR. Por ser uma operação de soma binária livre de transporte de bits, o operador XOR revela as propriedades do triângulo de Sierpinski nos planos de bits individuais da memória. Como o programa se inicia com o valor de dados 2 (equivalente a 00000010 em binário), apenas o bit de número 1 é ciclicamente alternado entre os estados lógicos 0x00 e 0x02. Esse processo imita de forma perfeita o comportamento de transição da Regra 60 na teoria dos autômatos celulares elementares:

Cell^(p)[k] = Cell^(p-1)[k] ⊕ Cell^(p)[k-1]

Através da aplicação prática do teorema matemático de Lucas, essa regra garante que a estrutura binária gravada na memória RAM coincida com o bit 1 da matriz de adições, desenhando as ramificações infinitas e simétricas do triângulo fractal de Sierpinski à medida que o loop avança indefinidamente.

A geração do som

A síntese sonora de "Wake up!" é gerada através do controle de modulação física fornecido pela instrução out 61h, al. No circuito clássico das placas-mãe de arquitetura x86, a porta física 61h controla o alto-falante integrado do computador. O bit 1 dessa porta está conectado diretamente à bobina eletromagnética do cone do alto-falante. Quando o bit é ativado com o valor 1, o cone é empurrado fisicamente para fora; quando o bit recebe o valor de dados 0, o cone se retrai para a posição original.

A rápida alternância entre os estados binários gerados pela evolução matemática do fractal de Sierpinski produz uma série rítmica de ondas quadradas analógicas. Conforme o autômato celular se espalha, a largura de pulso e as frequências fundamentais dessas ondas se alteram dinamicamente, produzindo um efeito sônico auto-semelhante e com andamento invariante, uma técnica que a cena de arte eletrônica classifica como composição de bytebeat.

O grande diferencial estético de "Wake up!" reside na textura do som gerado. Como o programa varre um segmento contínuo completo de 64 kilobytes de dados, o processador não lê apenas as células da RAM que representam o texto exibido no monitor. O loop acessa também os endereços de memória física que contêm o código de BIOS de sombra de vídeo carregado na RAM do sistema (shadowed video ROM BIOS). Esses dados de BIOS contêm instruções complexas e estáticas de programação que, ao serem traduzidas diretamente para o alto-falante como se fossem ondas de áudio, introduzem ruídos de fundo e sonoridades sujas de aspecto industrial. Essa interferência inesperada gera uma sonoridade crua, agressiva e com atitude punk, que difere drasticamente das ondas puras obtidas na reprodução abstrata do autômato de Sierpinski em ambientes isolados de emulação.

A geometria do visual

O efeito estético de cascata de caracteres, frequentemente comparado à icônica chuva de códigos verdes da série cinematográfica Matrix, decorre de uma escolha altamente geométrica implementada no cálculo de deslocamento espacial do registrador de índice. Em vez de avançar na memória utilizando incrementos ordenados de 16 bytes, a instrução sub si, byte 57 em conjunto com o carregamento lodsb faz com que a computação caminhe em saltos reversos de exatamente 56 bytes a cada iteração.

Esse passo geométrico de 56 bytes desempenha duas funções simultâneas cruciais para a estrutura visual e sonora da introdução de HellMood:

• O efeito acústico: Uma vez que o valor de passo 56 não é um divisor exato da capacidade total de 65.536 bytes do segmento de memória, o programa acessa apenas os endereços de memória física que são múltiplos exatos de 8. Esse comportamento força o loop a realizar exatamente 8.192 passos e completar 7 voltas completas de varredura pela memória do sistema antes de redefinir o seu estado inicial. Essa maior duração de ciclo divide pela metade a frequência acústica fundamental do som, rebaixando a saída de áudio em exatamente uma oitava e conferindo-lhe uma presença de graves muito mais profunda.
• O efeito visual na tela: Em uma tela de texto de 80 bytes de largura útil (considerando que cada coluna é representada por um byte de caractere e um byte de cor), recuar 56 bytes de memória equivale a avançar 24 bytes de distância física na linha subsequente (o que representa um avanço lateral de 12 colunas). Essa geometria de varredura espacial faz com que o algoritmo visite e atualize apenas 10 colunas verticais distintas ao longo de toda a largura do monitor. Como resultado, o triângulo clássico de Sierpinski é distorcido diagonalmente, fracionando a estrutura original do fractal em 10 colunas de caracteres independentes que sobem continuamente pela tela.

Se o programa fosse executado em uma tela com dimensões espaciais muito maiores, ou se as linhas do autômato celular fossem representadas de forma compacta e sequencial sem saltar colunas de texto, a estrutura bidimensional do triângulo de Sierpinski seria revelada perfeitamente ao espectador. Contudo, é a fragmentação espacial provocada pelo salto inverso de 56 bytes que confere ao visual a sua dinâmica fluida de chuva digital.

O teste em hardware

As peculiaridades operacionais de "Wake up!" motivaram membros da comunidade global de preservação histórica a testar o software diretamente em computadores antigos reais, permitindo confrontar o comportamento dinâmico do código físico com as aproximações fornecidas por emuladores modernos de DOS. O entusiasta de hardware conhecido como miragept realizou o teste clássico executando o programa em uma máquina equipada com um processador Intel 286 e uma placa de vídeo EGA configurada para emular o modo de vídeo MDA/Hercules, conectada a um autêntico monitor monocromático de fósforo verde IBM 5151.

Para viabilizar o teste em telas monocromáticas que respondem sob um mapeamento de endereços de vídeo diferente dos sistemas coloridos CGA/VGA, o programador executou uma pequena alteração (patch) de um byte no código binário original de HellMood. O endereço de segmento inicial do buffer de vídeo armazenado no registrador de hardware bh foi redirecionado de seu valor colorido padrão 0xb8 para o endereço 0xb0, utilizado para placas monocromáticas MDA.

"Isso é tão incrível que eu tive que tentar rodá-lo em hardware real. O texto verde é uma combinação natural para MDA/Hercules, então modifiquei o endereço de 0xB800 para 0xB000, que é o que a MDA utiliza. Eu não tenho o computador IBM exato, mas usei um 286 com placa EGA capaz de emular MDA/Hercules, e um monitor real MDA, então é muito próximo disso. Por favor, note que este monitor (IBM 5151) tem uma persistência de fósforo enorme, o que eu acho que prejudica a apresentação neste caso porque é muito rápido", explicou miragept em sua análise de hardware de época.

O criador da intro, HellMood, expressou grande entusiasmo diante do experimento em computadores de época, apontando um detalhe curioso: a persistência física prolongada de emissão do fósforo verde do monitor analógico IBM 5151, embora criasse rastros borrados na exibição rápida de texto na tela, acabou agindo como um filtro óptico integrador. Essa característica física analógica tornou o desenho geométrico do triângulo de Sierpinski muito mais visível e estável ao olho humano no final da execução, algo que é suavizado na atualização instantânea e fria das telas digitais dos emuladores por software.

Emuladores modernos e diferentes versões de circuitos integrados de BIOS antigos deixam rastros térmicos e lógicos sutilmente distintos na memória de trabalho no instante do boot. Como o algoritmo de "Wake up!" opera executando cálculos lógicos de XOR diretamente contra os resíduos de memória já presentes no circuito após a inicialização da máquina, os padrões finais de som e imagem produzidos são extremamente sensíveis ao ambiente operacional. Limpar formalmente toda a RAM antes do início das operações de cálculo garantiria um comportamento uniforme, porém custaria preciosos bytes extras que inviabilizariam o limite estrito de 16 bytes do executável.

Impacto no cenário nacional

No Brasil, o ecossistema de computação retrô e desenvolvimento de software sob restrições extremas vive uma fase de renovação ativa, estimulado por grupos de preservação histórica de equipamentos clássicos das décadas de 1970 e 1980 — como as plataformas nacionais baseadas nos processadores de 8 bits das famílias TK90X, Prológica e nos microcomputadores compatíveis com o padrão MSX. Para a comunidade brasileira de engenharia de software, o estudo de soluções minimalistas como a de HellMood oferece lições profundas sobre como entender os limites físicos do hardware de computadores e a eficiência máxima na escrita de rotinas lógicas.

O contraste entre as filosofias do movimento de sizecoding e os fluxos de trabalho do desenvolvimento comercial moderno brasileiro é notável. Enquanto a indústria nacional corporativa frequentemente adota arquiteturas pesadas, soluções distribuídas em nuvem e bibliotecas externas gigantescas que consomem volumes enormes de dados para processar funções simples, as técnicas aplicadas em pequenos intros lembram a importância do conhecimento profundo sobre a memória de baixo nível e o funcionamento íntimo das CPUs. A aplicação destas noções de otimização estrita em disciplinas de ciência da computação e de engenharia eletrônica ajuda os desenvolvedores locais a compreender como construir softwares mais eficientes, especialmente voltados a sistemas embarcados de internet das coisas (IoT), veículos autônomos e equipamentos que dependem de chips de baixo consumo energético.

Além disso, o desenvolvimento de códigos otimizados sob limitações severas de espaço e poder de cálculo compartilha do mesmo espírito de improvisação criativa associado à criatividade e adaptabilidade do desenvolvedor brasileiro. A capacidade histórica de contornar recursos físicos escassos e criar utilitários de alta performance a partir de sistemas legados reflete-se na forma como a comunidade tech nacional aprecia soluções de engenharia minimalistas.

O futuro do desenvolvimento

Considerando o horizonte tecnológico dos próximos cinco anos, a urgência em debater a eficiência computacional e a densidade energética dos softwares cresce continuamente. Com o crescimento da inteligência artificial operando nas pontas das redes físicas de transmissão (edge computing) e a proliferação acelerada de chips inteligentes instalados em objetos cotidianos operados por bateria, os conceitos clássicos de codificação otimizada em assembly e cálculos diretos por matemática pura retornam ao topo das discussões das indústrias de ponta.

O legado deixado por demonstrações artísticas radicais como "Wake up!" reside justamente em forçar o pensamento crítico sobre o real potencial de aproveitamento técnico das máquinas modernas. A obra ilustra que, sob os limites físicos adequados, a mente do desenvolvedor é plenamente capaz de extrair dinamismo visual rico e síntese acústica complexa de volumes de memória que seriam considerados invisíveis na computação diária corporativa atual.

Se apenas 16 bytes de código assembly x86 conseguem criar uma ponte matemática precisa para gerar uma composição contínua de áudio e cascatas de caracteres persistentes em uma máquina clássica, quanto do poder de processamento das CPUs modernas estamos desperdiçando diariamente em nossos ambientes de trabalho devido ao uso excessivo de abstrações de software? Você, programador ou entusiasta de novas tecnologias, já se perguntou quão veloz e responsivo o seu próprio software poderia se tornar se você buscasse compreender intimamente as restrições e o funcionamento físico dos chips que o executam?