Despertando 16b

 (hellmood.111mb.de)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Wake up! 16b es una intro DOS de 16 bytes para x86 en modo real, presentada en la Outline Demoparty, que genera simultáneamente un fractal de Sierpinski y sonido usando el búfer de texto
  • Con int 10h y la configuración ds=0xb800, usa el patrón inicial de la pantalla en modo texto 40x25 como espacio de cálculo, y los bytes de espacios y colores influyen en la salida
  • xor [si], al funciona como una suma sin acarreo, creando la estructura de Sierpinski en el bit 1, y ese mismo byte se envía al altavoz de la PC con out 61h, al
  • El bucle real se desplaza -56 bytes en cada iteración y se reinicia tras 8,192 pasos; el sonido baja una octava y en pantalla aparece un patrón sesgado en 10 columnas de caracteres
  • El parche 0xB000 para MDA/Hercules y diferencias como el estado del BIOS y la RAM cambian el resultado, y esos artefactos naturales del hardware pasan a formar parte del sizecoding

Estructura central de una intro x86 de 16 bytes

  • Wake up! 16b es una intro en ensamblador DOS x86 de 16 bytes en modo real, presentada en mayo de 2026 en la Outline Demoparty de Ommen, Países Bajos
  • Usa el búfer de texto VGA/CGA como espacio de cálculo para generar en pantalla un fractal infinito de Sierpinski, y envía esos mismos datos al puerto del altavoz de la PC para producir sonido
  • El código completo consta de 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바이트
  • Durante el desarrollo se exploraron técnicas de autómatas celulares para usar conjuntamente en gráficos y sonido, una instrucción de ensamblador polimórfica donde add [bx+si],al se vuelve 0x0000, y técnicas de sizecoding que reutilizan bytes y opcodes saltando al medio de una instrucción
  • El trabajo previo "M8trix" era una intro de 8 bytes y 7 bytes de 2014 que hacía que caracteres seudorrandom se propagaran por la pantalla; en Wake up! 16b el sonido aparece primero y luego se acopla el efecto visual

La pantalla de texto inicializada

  • int 10h establece el modo de video 0, creando una cuadrícula de texto de 40x25
  • mov bh, 0xb8 y mov ds, bx ajustan el segmento de datos ds a la dirección del búfer de texto VGA/CGA: 0xb800
  • Cuando el BIOS limpia la pantalla, no llena la memoria con ceros, sino que pone en las 2,000 posiciones de caracteres el byte de carácter 0x20 (espacio) y el atributo de color 0x07 (gris claro sobre fondo negro)
  • La pantalla parece vacía, pero en memoria queda un patrón uniforme, y ese estado inicial afecta tanto al sonido como a la salida visual
  • Incluso los datos antes y después de la memoria de video visible y la manera en que se inicializa tras “clear screen” terminan mezclándose en el resultado, produciendo un sonido más áspero y distintivo de lo esperado

Sumas acumuladas y estructura binomial

  • Si se mira solo la estructura matemática, se puede suponer que el estado empieza en 0 en vez de 0x20, que se usa add en lugar de xor, que se avanza 16 bytes por vez y que al empieza en 2
  • Un segmento DOS tiene exactamente 65,536 bytes, y al moverse de 16 en 16 se tarda 4,096 pasos en recorrer todo el segmento
  • Como 4,096 es múltiplo de 256, el tamaño de un registro de 8 bits, el acarreo se alinea cuando el segmento hace wrap, y al vuelve a 2 al inicio de cada barrido
  • Al seguir sumando los valores entre celdas se genera una suma acumulada (prefix sum), y los valores se desarrollan como una sucesión de coeficientes binomiales escalados por 2
  • Si se observan varios pases sobre las primeras 16 celdas, los valores se van acumulando por filas, y como son valores de 8 bits, lo que supera 256 hace wrap y vuelve a aparecer como valores pequeños

XOR y la estructura de Sierpinski

  • Por las propiedades combinatorias módulo 2, aparece el triángulo de Sierpinski, y ese bit se envía directamente al altavoz de la PC
  • A nivel de bits, la suma sin acarreo es XOR, por eso el código usa xor [si], al en lugar de add
  • El valor inicial 2 es 00000010 en binario, así que solo el bit 1 alterna entre 0x00 y 0x02
  • Este patrón corresponde a la regla 60 de los autómatas celulares elementales
  • Según el teorema de Lucas, este patrón coincide con el bit 1 de la tabla de suma, y en la tabla las posiciones donde el bit 1 está activo aparecen como 2

Cómo los datos se convierten en sonido

  • out 61h, al envía el byte calculado al puerto 61h, conectado al altavoz de la PC
  • El bit 1 del puerto 61h determina si el cono del altavoz se empuja hacia afuera o se jala hacia adentro
  • El código calcula el fractal con XOR, escribe el resultado en memoria y luego envía inmediatamente ese mismo byte al puerto del altavoz
  • Los unos y ceros que salen del fractal forman una onda cuadrada (square wave) con ancho de pulso y frecuencia que cambian de manera natural; al reproducirse por líneas, se vuelve un bytebeat autosimilar y casi invariante en tempo
  • En el sonido de salida no solo interviene el búfer de texto, sino también el resto de los bytes del segmento de 64 KB; debido al código shadowed del video ROM BIOS presente allí, el resultado termina siendo más áspero y funky que el bytebeat de onda rectangular superpuesta basado en líneas de Sierpinski que se esperaba

Paso de 56 bytes: octava y cizallamiento diagonal

  • El código real no avanza 16 bytes cada vez, sino que, con la combinación de lodsb y sub si, byte 57, se mueve -56 bytes hacia atrás en cada iteración
  • Ese desplazamiento llena la pantalla de forma dispersa sin hacer demasiado grande el búfer de sonido, y se usa para reproducir un efecto visual similar al de M8trix

  • Audio

    • 56 no divide exactamente a 65,536
    • El código solo visita offsets múltiplos de 8 y no se reinicia hasta pasar por 8,192 pasos y hacer wrap 7 veces
    • Como la longitud del ciclo se duplica, la frecuencia fundamental se reduce a la mitad y el sonido baja una octava

  • Visuales

    • En una pantalla de 80 bytes de ancho, moverse -56 bytes equivale a avanzar 24 bytes, es decir, 12 columnas
    • Solo se visitan 10 columnas distintas
    • El fractal no aparece como una imagen llena, sino cizallado en diagonal sobre 10 columnas de caracteres que se desplazan hacia la parte superior de la pantalla
    • El triángulo real tiene 8,192 “píxeles” de ancho, pero una línea de texto solo tiene 80 bytes, así que aunque se percibe el movimiento, la estructura completa es difícil de ver directamente
    • Si se dibujara todo de una vez sin saltarse píxeles, o se usara una pantalla mucho más grande, sí podría verse el triángulo

Ejecución en hardware real

  • El scener miragept lo ejecutó en hardware real parcheando la dirección de 0xB800 a 0xB000, usada por MDA, para obtener texto verde acorde con MDA/Hercules
  • El equipo usado no era una máquina IBM exacta, sino una 286 con tarjeta EGA capaz de emular MDA/Hercules y un monitor MDA real
  • El audio capturado incluía ruido constante propio de la máquina, y el monitor IBM 5151 tiene una persistencia de fósforo larga, lo que juega en contra de visualizaciones tan rápidas
  • El cambio en el byte de dirección alteró un poco el sonido, pero funcionó como se esperaba, y en la parte final la estructura de Sierpinski se ve mejor que en la versión original
  • Según el emulador y la versión del BIOS, los artefactos residuales en RAM cambian, y como el código aplica XOR sobre ese estado de memoria, la salida es sensible al entorno de ejecución
  • Se podría obtener una salida uniforme limpiando primero la memoria, pero eso requeriría bytes extra; aceptar el estado natural del hardware sigue siendo parte del encanto del sizecoding

Material relacionado

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios de Hacker News
  • Seguir esto me metió en una madriguera de conejo de una hora, y al final terminé viendo un video de dos personas creando un triángulo de Sierpinski con una presentación recursiva de PowerPoint
    https://youtu.be/b-Fa6HtvGtQ?si=LpQszgA9_K-m3V3-
    • Matt Parker y Steve Mould están entre los mejores educadores STEM de YouTube
      Ambos son ingeniosos y experimentales. Parker va más por las matemáticas puras, y Mould se mueve entre varias disciplinas y realmente satisface ese impulso por los experimentos/DIY
      Si te gustó este video, recomiendo muchísimo ver más de ambos canales
      https://www.youtube.com/@standupmaths
      https://www.youtube.com/@SteveMould
  • Sinceramente pensaba que la demo de 32 bytes que vi hace tiempo era el límite de lo pequeño que podía hacerse un binario sin dejar de verse bien
    Esa demo ni siquiera tenía sonido
    Esto es un trabajo verdaderamente impresionante, una obra maestra como para retirarse con ella. Siendo más realistas, seguramente terminarán persiguiéndolo otra vez en otra arquitectura
  • Ver este tipo de código generativo extremadamente pequeño me hace querer gritar: “¡Es una bruja!”
    Bravo
  • Me quedé completamente hipnotizado viendo rainbow surf entre las demos enlazadas
    https://www.youtube.com/watch?v=QKLhH_ANwIc
    • Es la persona que hizo "wake up". Sí, esa demo fue la que me hizo volver a la actividad
      Nuestra comunidad de size coding pensaba que ya había descubierto todos los trucos de autómatas celulares hace años, pero apareció Plex y nos demostró que no ♥
  • Está realmente genial
    No sé si hubo algún artículo sobre un trabajo previo llamado m8trix, pero yo lo diseccioné un poco cuando salió, en 2014: https://scot.tg/2014/05/31/amazing-code-density/
  • Este tipo de creaciones geniales son la razón por la que nos emociona la tecnología
  • Al principio pensé que esto no era una demo de 16 bytes, sino un LLM de 16B parámetros
    • Yo también. Pero esto es muchísimo más genial
    • Son nueve órdenes de magnitud de diferencia
  • De verdad me dejó maravillado. Este tipo de cosas son la razón por la que me empezó a gustar la programación y la computación
    Todo es tan hermoso, es arte de verdad. Da pena que en la industria normalmente haya tan pocas oportunidades de crear cosas así con todo el tema de la IA y demás
    • Si lo hubieran hecho con Electron, probablemente habría sido una descarga de 300 MB y usaría como 1 GB de RAM
  • Apenas estoy logrando aceptar que esto sea posible