目覚める16b

 (hellmood.111mb.de)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Wake up! 16b は Outline Demoparty で公開された 16バイト x86 リアルモード DOS イントロで、テキストバッファを使って Sierpinski フラクタルとサウンドを同時に生成する
  • int 10h と ds=0xb800 の設定により、40x25 テキストモードの初期画面パターンを計算空間として使い、空白文字と色属性バイトが出力に影響する
  • xor [si], al は キャリーなし加算 のように動作して bit 1 の Sierpinski 構造を作り、同じバイトを out 61h, al で PC スピーカーにも送る
  • 実際のループは反復ごとに -56バイト 移動し、8,192ステップ後にリセットされ、音は 1オクターブ低くなり、画面には 10本の文字列の柱にせん断されたパターンが現れる
  • 0xB000 への MDA/Hercules 用パッチや 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],al が 0x0000 になる多相的アセンブリ命令、命令の途中へジャンプしてバイトと opcode を再利用する sizecoding 手法などが探求された
  • 以前の作品 "M8trix" は 2014年に疑似乱数文字を画面へにじませる 8バイト・7バイトイントロだったが、Wake up! 16b では先にサウンドが現れ、その後に視覚効果が噛み合ってくる

初期化されたテキスト画面

  • int 10h は ビデオモード 0 を設定し、40x25 テキストモードのグリッドを作る
  • mov bh, 0xb8 と mov ds, bx はデータセグメント ds を VGA/CGA テキストバッファのアドレス 0xb800 に合わせる
  • BIOS が画面を消去するとき、メモリを 0 で埋めるのではなく、2,000個の文字スロットを文字バイト 0x20（space）と色属性 0x07（黒背景に明るいグレー）で埋める
  • 画面は空に見えても、メモリ上には均一なパターンが残っており、この初期状態がサウンドと視覚出力に影響する
  • 可視ビデオメモリの前後にあるデータや、“clear screen” 後の初期化方法までも結果に混ざり、予想以上に荒々しく個性的な音が生まれる

累積和と二項構造

  • 数学的構造だけを見るなら、状態を 0x20 の代わりに 0 とし、xor の代わりに add を使い、一度に 16バイト ずつ進み、al が 2 から始まると考えられる
  • DOS セグメントはちょうど 65,536バイト で、16バイトずつ進むとセグメント全体を一周するのに 4,096ステップ かかる
  • 4,096 は 8ビットレジスタサイズ 256 の倍数なので、セグメントがラップするときにキャリーオーバーが整列し、各 sweep の開始点で al は 2 に戻る
  • セル間の値を加え続けると 部分和 (prefix sum) が生まれ、その値は 2倍スケールされた二項係数列のように展開する
  • 最初の16セルで複数パスを見ると、値は行単位で蓄積され、8ビット値なので 256 を超えた部分はラップして再び小さな値として現れる

XOR と Sierpinski 構造

  • mod 2 における組合せ論的性質により Sierpinski 三角形 が現れ、このビットがそのまま PC スピーカーへ出力される
  • ビット単位ではキャリーなし加算は XOR なので、コードでは add の代わりに xor [si], al が使われている
  • 初期値 2 は 2進数で 00000010 なので、bit 1 だけが 0x00 と 0x02 の間でトグルする
  • このパターンは初等セル・オートマトンの rule 60 に対応する
  • Lucas の定理により、このパターンは加算テーブルの bit 1 と一致し、表では bit 1 が立つ位置が 2 として現れる

データが音になる仕組み

  • out 61h, al は計算されたバイトを PC スピーカー に接続されたポート 61h へ送る
  • ポート 61h の bit 1 は、スピーカーのコーンを外側へ押すか内側へ引くかの状態を決める
  • コードは XOR でフラクタルを計算し、結果をメモリに書き込んだ後、その同じバイトを即座にスピーカーポートへ送る
  • フラクタルから生じた 1 と 0 は、パルス幅と周波数が自然に変化する 方形波 (square wave) を作り、行単位で再生すると自己相似的で、ほぼテンポ不変に近い bytebeat になる
  • 出力サウンドにはテキストバッファだけでなく 64KB セグメントの残りのバイトも混ざり、その中の shadowed video ROM BIOS コードのため、想定していた Sierpinski line ベースの overlayed rectangle wave bytebeat とは異なる、荒々しくファンキーな音になる

56バイトステップ: オクターブと対角せん断

  • 実際のコードは 16バイトずつ移動せず、lodsb と sub si, byte 57 の組み合わせによって反復ごとに -56バイト ずつ後退する
  • この移動幅は画面を疎に埋めつつ、サウンドバッファが大きくなりすぎないようにし、M8trix のような視覚効果を再現するために使われる

  • オーディオ

    • 56 は 65,536 を正確には割り切らない
    • コードは 8 の倍数オフセットだけを訪れ、8,192ステップ を経て 7回ラップしてからようやくリセットされる
    • サイクル長が 2倍になることで基音周波数は半分に下がり、音は 1オクターブ低くなる

  • ビジュアル

    • 幅 80バイトの画面で -56バイト移動は、前方へ 24バイト、つまり 12列 移動するのと同じ
    • 訪問される異なる列は 10列 しかない
    • フラクタルは埋め尽くされた画像ではなく、画面上方へ動く 10本の文字柱として対角方向にせん断されて現れる
    • 実際の三角形は 8,192 “ピクセル” 幅だが、1行の文字は 80バイトしかないため、動きは感じられても全体構造を直接見るのは難しい
    • ピクセルを飛ばさずにまとめて描くか、はるかに大きな画面を使えば三角形を確認できる

実機での実行

  • scener miragept は、MDA/Hercules に合う緑色テキスト表示のため、アドレスを 0xB800 から MDA が使う 0xB000 にパッチして実機で動作させた
  • 使用機材は厳密な IBM 純正機ではないが、MDA/Hercules エミュレーション可能な EGA カードを備えた 286 と、実物の MDA モニターだった
  • キャプチャ音声にはマシン自体の持続的なノイズが混ざり、IBM 5151 モニターは 長い残光 を持つため、非常に高速な表示には不利だった
  • アドレスバイト変更のため音は少し変わったが、意図どおりに動作し、後半では Sierpinski 構造が元のバージョンよりもよく見える
  • エミュレータや BIOS バージョンによって RAM に残るアーティファクトが変わり、コードはそのメモリ状態に対して XOR を行うため、出力は実行環境に敏感である
  • メモリを先に消去すれば均一な出力を得られるが、追加バイトが必要になり、自然なハードウェア状態を受け入れるやり方が sizecoding の魅力として残る

関連資料

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsのコメント
  • これを追っていたら1時間ものラビットホールに落ちてしまい、最後には2人が再帰的なPowerPointプレゼンテーションでシェルピンスキーの三角形を作る動画まで見ることになった
    https://youtu.be/b-Fa6HtvGtQ?si=LpQszgA9_K-m3V3-
    • Matt ParkerとSteve MouldはYouTubeでも指折りのSTEM教育者だ
      2人とも機知に富んでいて実験的だ。Parkerはより純粋な数学寄りで、Mouldはさまざまな分野をまたぎながら実験/DIY欲をしっかり満たしてくれる
      この動画が気に入ったなら、2つのチャンネルをさらに見ることを強く勧める
      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くらい食っていただろう
  • これが可能だということを、ようやく受け止めつつある