Wake up! 16b

 (hellmood.111mb.de)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Wake up! 16b é uma intro DOS x86 em modo real de 16 bytes, apresentada na Outline Demoparty, que gera ao mesmo tempo um fractal de Sierpinski e som usando o buffer de texto
  • Com int 10h e a configuração ds=0xb800, ela usa o padrão inicial da modo texto 40x25 como espaço de cálculo, e os bytes de espaço e cor influenciam a saída
  • xor [si], al funciona como uma soma sem carry, criando a estrutura de Sierpinski no bit 1, e o mesmo byte é enviado ao alto-falante do PC com out 61h, al
  • O loop real avança -56 bytes a cada repetição e é reiniciado após 8.192 passos; o som desce uma oitava e o padrão aparece na tela inclinado em 10 colunas de caracteres
  • O patch 0xB000 para MDA/Hercules e diferenças no BIOS e no estado da RAM mudam o resultado da execução, tornando os artefatos naturais do hardware parte do sizecoding

Estrutura central de uma intro x86 de 16 bytes

  • Wake up! 16b é uma intro em assembly DOS x86 de 16 bytes em modo real, apresentada em maio de 2026 na Outline Demoparty, em Ommen, na Holanda
  • Ela usa o buffer de texto VGA/CGA como espaço de cálculo para criar um fractal de Sierpinski infinito na tela e envia os mesmos dados para a porta do alto-falante do PC para gerar som
  • O código completo tem 16 bytes 
    int 10h          ; 2바이트
mov bh, 0xb8     ; 2바이트
mov ds, bx       ; 2바이트
L:
lodsb            ; 1바이트
sub si, byte 57  ; 3바이트
xor [si], al     ; 2바이트
out 61h, al      ; 2바이트
jmp short L      ; 2바이트
  • No processo de desenvolvimento, foram exploradas técnicas de sizecoding como usar autômatos celulares tanto nos gráficos quanto no som, a instrução polimórfica de assembly add [bx+si],al, que vira 0x0000, e a reutilização de bytes e opcodes por meio de saltos para o meio de instruções
  • O trabalho anterior, "M8trix", era uma intro de 8 bytes e 7 bytes de 2014 que espalhava caracteres pseudoaleatórios pela tela; em Wake up! 16b, o som vem primeiro e depois o efeito visual se encaixa

A tela de texto inicializada

  • int 10h define o modo de vídeo 0, criando uma grade de modo texto 40x25
  • mov bh, 0xb8 e mov ds, bx ajustam o segmento de dados ds para o endereço do buffer de texto VGA/CGA, 0xb800
  • Quando a BIOS limpa a tela, ela não preenche a memória com zero; em vez disso, preenche os 2.000 slots de caractere com o byte de caractere 0x20 (espaço) e o atributo de cor 0x07 (cinza-claro sobre fundo preto)
  • A tela parece vazia, mas um padrão uniforme permanece na memória, e esse estado inicial afeta a saída sonora e visual
  • Dados antes e depois da memória de vídeo visível, além do próprio método de inicialização após o “clear screen”, acabam entrando no resultado e produzem um som mais áspero e peculiar do que o esperado

Soma acumulada e estrutura binomial

  • Considerando apenas a estrutura matemática, pode-se assumir que o estado começa em 0 em vez de 0x20, que add é usado no lugar de xor, que o avanço é de 16 bytes por vez e que al começa em 2
  • Um segmento DOS tem exatamente 65.536 bytes, e avançar 16 bytes por vez exige 4.096 passos para percorrer o segmento inteiro
  • Como 4.096 é múltiplo de 256, o tamanho de um registrador de 8 bits, o carryover se alinha quando o segmento dá wrap, e al volta para 2 no início de cada varredura
  • Ao continuar somando os valores entre as células, forma-se uma soma prefixada (prefix sum), e os valores se expandem como uma sequência de coeficientes binomiais escalada por 2
  • Observando vários passes das 16 primeiras células, os valores se acumulam por linha e, como são valores de 8 bits, tudo o que passa de 256 dá wrap e reaparece como valores pequenos

XOR e a estrutura de Sierpinski

  • Pelas propriedades combinatórias módulo 2, surge o triângulo de Sierpinski, e esse bit é enviado diretamente ao alto-falante do PC
  • No nível de bits, soma sem carry é XOR, por isso o código usa xor [si], al em vez de add
  • O valor inicial 2 é o binário 00000010, então apenas o bit 1 alterna entre 0x00 e 0x02
  • Esse padrão corresponde à rule 60 dos autômatos celulares elementares
  • Pelo teorema de Lucas, esse padrão coincide com o bit 1 da tabela de adição, e na tabela as posições com o bit 1 ativado aparecem como 2

Como os dados viram som

  • out 61h, al envia o byte calculado para a porta 61h, ligada ao alto-falante do PC
  • O bit 1 da porta 61h determina se o cone do alto-falante é empurrado para fora ou puxado para dentro
  • O código calcula o fractal com XOR, grava o resultado na memória e em seguida envia imediatamente o mesmo byte para a porta do alto-falante
  • Os 1s e 0s gerados pelo fractal formam uma onda quadrada (square wave) com largura de pulso e frequência variando naturalmente; reproduzida linha a linha, ela vira um bytebeat auto-semelhante e quase invariável em relação ao tempo
  • O som de saída mistura não só o buffer de texto, mas também os demais bytes do segmento de 64 KB, e por causa do código da video ROM BIOS sombreada ali presente, o resultado fica diferente do esperado Sierpinski line-based overlayed rectangle wave bytebeat, com um som mais áspero e funky

Passo de 56 bytes: oitava e cisalhamento diagonal

  • O código real não avança 16 bytes por vez; com a combinação de lodsb e sub si, byte 57, ele recua 56 bytes a cada repetição
  • Esse deslocamento preenche a tela de forma esparsa sem deixar o buffer de som grande demais, e foi usado para recriar um efeito visual como o de M8trix

  • Áudio

    • 56 não divide 65.536 exatamente
    • O código visita apenas offsets múltiplos de 8 e só se reinicia depois de 8.192 passos, após dar wrap 7 vezes
    • Como o comprimento do ciclo dobra, a frequência fundamental cai pela metade e o som desce uma oitava

  • Visual

    • Numa tela de 80 bytes de largura, mover -56 bytes equivale a avançar 24 bytes, ou seja, 12 colunas
    • Apenas 10 colunas distintas são visitadas
    • O fractal não aparece como uma imagem preenchida, mas cisalhado na diagonal em 10 colunas de caracteres que se movem para a parte superior da tela
    • O triângulo real tem largura de 8.192 “pixels”, mas uma linha de caracteres tem só 80 bytes, então é possível perceber o movimento, mas difícil ver diretamente a estrutura inteira
    • Se os pixels fossem desenhados de uma vez, sem pular posições, ou em uma tela muito maior, daria para ver o triângulo

Execução em hardware real

  • O scener miragept executou a intro em hardware real, aplicando um patch no endereço de 0xB800 para 0xB000, usado por MDA, para obter texto verde mais apropriado a MDA/Hercules
  • O equipamento usado não era um IBM exato, mas um 286 com placa EGA capaz de emular MDA/Hercules e um monitor MDA real
  • No áudio capturado, entrou o ruído contínuo da própria máquina, e o monitor IBM 5151 tem persistência longa de fósforo, o que o torna pouco adequado para exibição muito rápida
  • A mudança do byte de endereço alterou ligeiramente o som, mas o programa funcionou como pretendido, e na parte final a estrutura de Sierpinski aparece melhor do que na versão original
  • Dependendo do emulador e da versão da BIOS, os artefatos que ficam na RAM variam, e como o código faz XOR sobre esse estado de memória, a saída é sensível ao ambiente de execução
  • É possível obter uma saída uniforme limpando a memória antes, mas isso exigiria bytes adicionais; aceitar o estado natural do hardware continua sendo parte do charme do sizecoding

Materiais relacionados

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News
  • Fui seguindo isso e acabei caindo num buraco de coelho de uma hora; no fim, até vi um vídeo de duas pessoas criando um triângulo de Sierpinski com uma apresentação recursiva de PowerPoint
    https://youtu.be/b-Fa6HtvGtQ?si=LpQszgA9_K-m3V3-
    • Matt Parker e Steve Mould estão entre os melhores educadores de STEM no YouTube
      Os dois são espirituosos e experimentais. Parker pende mais para a matemática tradicional, enquanto Mould transita por várias áreas e acerta em cheio nessa vontade de fazer experimentos/DIY
      Se você gostar deste vídeo, recomendo fortemente ver mais dos dois canais
      https://www.youtube.com/@standupmaths
      https://www.youtube.com/@SteveMould
  • Eu realmente achava que a demo de 32 bytes que vi tempos atrás era o limite de quão pequeno um binário podia ficar sem deixar de ser agradável de ver
    Aquela demo nem tinha som
    Isto é um trabalho realmente impressionante, uma obra-prima digna de servir como trabalho de aposentadoria. Sendo mais realista, porém, provavelmente vão atrás disso de novo em outra arquitetura
  • Quando vejo esse tipo de código generativo extremamente pequeno, dá vontade de gritar: “é bruxaria!”
    Bravo
  • Fiquei completamente hipnotizado pela demo rainbow surf entre as que foram linkadas
    https://www.youtube.com/watch?v=QKLhH_ANwIc
    • É a pessoa que fez "wake up". Sim, aquela demo me fez voltar à ativa
      Nossa comunidade de size coding achava que já tinha descoberto todos os truques de autômatos celulares anos atrás, mas aí apareceu Plex e mostrou que não ♥
  • Muito legal
    Não sei se já houve algum texto sobre a obra anterior chamada m8trix, mas eu dei uma analisada nela quando saiu, em 2014: https://scot.tg/2014/05/31/amazing-code-density/
  • São criações incríveis como esta que fazem a gente se empolgar com tecnologia
  • No começo achei que isto não era uma demo de 16 bytes, e sim um LLM com 16B de parâmetros
    • Eu também. Só que isto é muito mais legal
    • Uma diferença de 9 dígitos
  • Fiquei realmente maravilhado. Coisas assim são o motivo de eu ter passado a gostar de programação e computação
    É tudo bonito demais, verdadeira arte. É uma pena que, na indústria, com tanto foco em IA e afins, normalmente quase não haja chance de fazer coisas desse tipo
    • Se tivesse sido feito em Electron, provavelmente seria um download de 300 MB e consumiria algo como 1 GB de RAM
  • Ainda estou tentando assimilar que isto é possível