1P by GN⁺ | ★ favorite | 댓글 1개
  • Wake up! 16b는 Outline Demoparty에서 공개된 16바이트 x86 리얼 모드 DOS 인트로로, 텍스트 버퍼로 Sierpinski 프랙털과 소리를 동시에 만듦
  • int 10hds=0xb800 설정으로 40x25 텍스트 모드의 초기 화면 패턴을 계산 공간으로 쓰며, 공백·색상 바이트가 출력에 영향을 줌
  • xor [si], al캐리 없는 덧셈처럼 작동해 bit 1의 Sierpinski 구조를 만들고, 같은 바이트를 out 61h, al로 PC 스피커에 보냄
  • 실제 루프는 반복마다 -56바이트 이동해 8,192스텝 뒤 리셋되며, 소리는 한 옥타브 낮아지고 화면에는 10개 문자 기둥으로 전단된 패턴이 나타남
  • MDA/Hercules용 0xB000 패치와 BIOS·RAM 상태 차이처럼 실행 환경이 결과를 바꾸며, 자연스러운 하드웨어 아티팩트가 sizecoding의 일부가 됨

16바이트 x86 인트로의 핵심 구조

  • Wake up! 16b는 2026년 5월 네덜란드 Ommen의 Outline Demoparty에서 공개된 16바이트 x86 리얼 모드 DOS 어셈블리 인트로
  • VGA/CGA 텍스트 버퍼를 계산 공간으로 사용해 무한 Sierpinski 프랙털을 화면에 만들고, 같은 데이터를 PC 스피커 포트로 보내 소리를 냄
  • 전체 코드는 16바이트로 구성됨
    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바이트
    
  • 개발 과정에서는 셀룰러 오토마타를 그래픽과 사운드에 함께 쓰고, add [bx+si],al0x0000이 되는 다형적 어셈블리 명령, 명령 중간 점프로 바이트와 opcode를 재사용하는 크기 코딩 기법을 탐색함
  • 이전 작업인 "M8trix"는 2014년에 의사난수 문자를 화면에 번지게 만든 8바이트·7바이트 인트로였고, Wake up! 16b에서는 사운드가 먼저 나온 뒤 시각 효과가 맞물림

초기화된 텍스트 화면

  • int 10h비디오 모드 0을 설정해 40x25 텍스트 모드 격자를 만듦
  • mov bh, 0xb8mov ds, bx는 데이터 세그먼트 ds를 VGA/CGA 텍스트 버퍼 주소인 0xb800 으로 맞춤
  • BIOS가 화면을 지울 때 메모리를 0으로 채우지 않고, 2,000개의 문자 슬롯을 문자 바이트 0x20(space)과 색상 속성 0x07(검은 배경의 밝은 회색)로 채움
  • 화면은 비어 보이지만 메모리에는 균일한 패턴이 남아 있고, 이 초기 상태가 사운드와 시각 출력에 영향을 줌
  • 보이는 비디오 메모리 앞뒤의 데이터와 “clear screen” 이후의 초기화 방식까지 결과에 섞여, 예상보다 거칠고 독특한 소리가 만들어짐

누적 합과 이항 구조

  • 수학적 구조만 보면 상태를 0x20 대신 0으로 두고, xor 대신 add를 쓰며, 한 번에 16바이트씩 전진하고 al2에서 시작한다고 가정할 수 있음
  • DOS 세그먼트는 정확히 65,536바이트이고, 16바이트씩 이동하면 세그먼트 전체를 도는 데 4,096스텝이 걸림
  • 4,096은 8비트 레지스터 크기인 256의 배수라서 세그먼트가 래핑될 때 캐리오버가 정렬되고, 각 sweep 시작점에서 al이 2로 돌아감
  • 셀 사이의 값을 계속 더하면 부분합(prefix sum) 이 만들어지고, 값은 2배 스케일된 이항 계수열처럼 전개됨
  • 처음 16개 셀의 여러 pass를 보면 값이 행 단위로 누적되며, 8비트 값이라 256을 넘는 부분은 래핑되어 다시 작은 값으로 나타남

XOR와 Sierpinski 구조

  • 모듈로 2의 조합론적 성질에 따라 Sierpinski 삼각형이 나타나며, 이 비트가 PC 스피커로 직접 출력됨
  • 비트 단위에서 캐리 없는 덧셈은 XOR이므로, 코드에는 add 대신 xor [si], al이 들어감
  • 시작값 2는 이진수 00000010이어서 bit 10x000x02 사이에서 토글됨
  • 이 패턴은 초등 셀룰러 오토마타의 rule 60에 대응함
  • Lucas의 정리에 따라 이 패턴은 덧셈 테이블의 bit 1과 일치하며, 표에서는 bit 1이 켜진 위치가 2로 나타남

데이터가 소리가 되는 방식

  • out 61h, al은 계산된 바이트를 PC 스피커와 연결된 포트 61h로 보냄
  • 포트 61hbit 1은 스피커 콘을 바깥쪽으로 밀거나 안쪽으로 당기는 상태를 결정함
  • 코드는 XOR로 프랙털을 계산하고, 결과를 메모리에 쓴 뒤 같은 바이트를 즉시 스피커 포트로 보냄
  • 프랙털에서 나온 1과 0은 펄스 폭과 주파수가 자연스럽게 변하는 구형파(square wave) 를 만들고, linewise로 재생되면 자기유사적이고 거의 템포 불변에 가까운 bytebeat가 됨
  • 출력 사운드에는 텍스트 버퍼뿐 아니라 64KB 세그먼트의 나머지 바이트도 섞이며, 그 안의 shadowed video ROM BIOS 코드 때문에 예상한 Sierpinski line 기반 overlayed rectangle wave bytebeat와 다른 거칠고 펑키한 소리가 남음

56바이트 스텝: 옥타브와 대각선 전단

  • 실제 코드는 16바이트씩 이동하지 않고, lodsbsub si, byte 57의 조합으로 반복마다 -56바이트씩 뒤로 이동함
  • 이 이동폭은 화면을 희박하게 채우면서도 사운드 버퍼가 너무 커지지 않게 하며, M8trix 같은 시각 효과를 재현하기 위해 쓰임
  • 오디오

    • 56은 65,536을 정확히 나누지 않음
    • 코드는 8의 배수 오프셋만 방문하며, 8,192스텝을 거치고 7번 래핑한 뒤에야 리셋됨
    • 사이클 길이가 두 배가 되면서 기본 주파수가 절반으로 낮아져 소리가 한 옥타브 내려감
  • 비주얼

    • 80바이트 폭 화면에서 -56바이트 이동은 앞으로 24바이트, 즉 12열 이동하는 것과 같음
    • 방문되는 서로 다른 열은 10개뿐임
    • 프랙털은 꽉 찬 이미지가 아니라, 화면 위쪽으로 움직이는 10개의 문자 기둥에 대각선으로 전단되어 나타남
    • 실제 삼각형은 8,192 “픽셀” 폭이지만 한 줄의 문자는 80바이트뿐이라 움직임은 느껴져도 전체 구조는 직접 보이기 어려움
    • 픽셀을 건너뛰지 않고 한꺼번에 그리거나 훨씬 큰 화면을 쓰면 삼각형을 볼 수 있음

실제 하드웨어에서의 실행

  • scener miragept는 MDA/Hercules에 어울리는 녹색 텍스트를 위해 주소를 0xB800에서 MDA가 쓰는 0xB000 으로 패치해 실제 하드웨어에서 실행함
  • 사용된 장비는 정확한 IBM 컴퓨터는 아니지만, MDA/Hercules 에뮬레이션이 가능한 EGA 카드가 있는 286과 실제 MDA 모니터였음
  • 캡처 오디오에는 기계 자체의 지속적인 노이즈가 섞였고, IBM 5151 모니터는 긴 형광체 잔상이 있어 매우 빠른 표시에 불리하게 작용함
  • 주소 바이트 변경 때문에 소리가 약간 달라졌지만 의도대로 동작했고, 후반부에는 Sierpinski 구조가 원래 버전보다 더 잘 보임
  • 에뮬레이터와 BIOS 버전에 따라 RAM에 남는 아티팩트가 달라지고, 코드는 그 메모리 상태에 XOR를 수행하므로 출력은 실행 환경에 민감함
  • 메모리를 먼저 지우면 균일한 출력을 얻을 수 있지만 추가 바이트가 필요하며, 자연스러운 하드웨어 상태를 받아들이는 방식이 sizecoding의 매력으로 남음

관련 자료

댓글과 토론

Hacker News 의견들
  • 이걸 따라가다 보니 한 시간짜리 토끼굴에 빠졌고, 마지막에는 두 사람이 재귀적인 PowerPoint 프레젠테이션으로 시에르핀스키 삼각형을 만드는 영상까지 보게 됨
    https://youtu.be/b-Fa6HtvGtQ?si=LpQszgA9_K-m3V3-
    • Matt Parker와 Steve Mould는 YouTube에서 손꼽히는 STEM 교육자들임
      둘 다 재치 있고 실험적임. Parker는 정통 수학 쪽에 가깝고, Mould는 여러 분야를 넘나들며 실험/DIY 욕구를 제대로 긁어줌
      이 영상이 마음에 들면 두 채널을 더 보는 걸 강력히 추천함
      https://www.youtube.com/@standupmaths
      https://www.youtube.com/@SteveMould
  • 예전에 본 32바이트 데모가 바이너리를 이 정도로 작게 만들면서도 보기 좋게 유지할 수 있는 한계라고 진심으로 생각했음
    그 데모에는 소리조차 없었음
    이건 정말 엄청난 작업이고, 은퇴작으로 삼아도 될 걸작임. 더 현실적으로는 다른 아키텍처에서 또 쫓아가게 되겠지만
  • 이런 극도로 작은 생성 코드를 보면 “마녀다!”라고 외치게 됨
    브라보
  • 링크된 데모 중 rainbow surf에 완전히 홀린 듯 봤음
    https://www.youtube.com/watch?v=QKLhH_ANwIc
    • "wake up"을 만든 사람임. 맞음, 그 데모가 나를 다시 활동하게 만들었음
      우리 size coding 커뮤니티는 세포 자동자 트릭을 몇 년 전에 전부 찾아냈다고 생각했는데, Plex가 나타나서 그게 아니란 걸 보여줌 ♥
  • 정말 멋짐
    m8trix라는 선행작에 대한 글이 있었는지는 모르겠지만, 나왔을 무렵인 2014년에 내가 한번 뜯어본 적 있음: https://scot.tg/2014/05/31/amazing-code-density/
  • 이런 멋진 창작물 때문에 우리가 기술에 설레는 것임
  • 처음엔 이게 16바이트 데모가 아니라 16B 파라미터 LLM인 줄 알았음
    • 나도 그랬음. 그런데 이게 훨씬 더 멋짐
    • 9자릿수 차이임
  • 정말 감탄했음. 이런 것들이 내가 프로그래밍과 컴퓨팅을 좋아하게 만든 이유임
    전부 너무 아름답고, 진짜 예술임. 업계에서는 AI니 뭐니 하면서 보통 이런 걸 만들 기회가 별로 없다는 게 아쉬움
    • Electron으로 만들었다면 아마 300MB 다운로드에 RAM은 1GB쯤 먹었을 듯
  • 이게 가능하다는 걸 겨우 받아들이는 중임