博士

ロボ子、今回のニュースはC64、つまりコモドール64のプログラミングコンテストの話じゃ。

ロボ子

コモドール64ですか！懐かしいですね。どんなコンテストだったんですか？

博士

2本の線を描画するPRG（実行ファイル）を、できるだけ少ないバイト数で作るというものじゃ。いかにコードを最適化するかの勝負じゃった。

ロボ子

なるほど。限られたリソースの中で、いかに効率的なコードを書くか、ですね。優勝者は何バイトだったんですか？

博士

Philip Heronという人が34バイトで優勝したぞ。すごいじゃろ？

ロボ子

34バイト！信じられないくらい小さいですね。どんなテクニックを使ったんでしょう？

博士

色々あるんじゃ。例えば、C64の画面RAMは`$0400`、カラーRAMは`$d800`にあることを利用して、直接メモリを操作したり。

ロボ子

画面RAMとカラーRAMのアドレスを直接指定して、描画するんですね。

博士

そうじゃ。他にも、画面全体をスクロールアップさせるROM関数 (`JSR $E8EA`) を使って、最後の行に線を描画したり、コード自身を書き換える自己書き換えコード (SMC) なんてテクニックもあるぞ。

ロボ子

自己書き換えコードですか！すごいですね。そんなことまでできるんですね。

博士

さらに、C64の起動時の状態を利用するのも重要じゃ。例えば、ゼロページのアドレス `$d5` には線分の長さ - 1 が、`$22` には線の傾きカウンタの初期値が格納されていることを利用したりするんじゃ。

ロボ子

初期状態を前提にすることで、初期化コードを省略できるんですね。でも、それってちょっと危険じゃないですか？

博士

確かに、環境に依存してしまうから、移植性は低くなるのじゃ。でも、今回のコンテストはあくまで「どれだけ小さくできるか」が重要だから、問題ないんじゃ。

ロボ子

なるほど。コンテストの目的に合わせた最適化が必要なんですね。

博士

BASICのスタートアップシーケンスを回避するために、スタックトリックやBASICウォームリセットベクトルトリックを使う人もいたみたいじゃ。

ロボ子

そんな裏技みたいな方法があるんですね！

博士

他にも、スクロールアップの呼び出しをループの先頭に移動してJMP命令を削減したり、線のパターンを8ビットにビットパックしたり、色々な工夫があるんじゃ。

ロボ子

皆さん、本当にすごいですね。限られた環境で、ここまで創意工夫を凝らすことができるなんて。

博士

コンテスト後も最適化は進んで、最終的には29バイトまで縮小されたらしいぞ。まさに職人技じゃ。

ロボ子

29バイト！もう何が何だか分かりませんね（笑）。

博士

昔のゲームは、こういう努力の結晶だったんじゃな。今のゲームは容量も大きいし、開発環境も整っているから、こういう最適化はあまり必要ないかもしれんけど、基礎を理解するには良い題材じゃ。

ロボ子

確かにそうですね。低レイヤーの知識は、どんな開発にも役立ちますからね。

博士

そういえばロボ子、今度、28バイトで動くAIを作ってくれないかの？

ロボ子

それは…、ちょっと無理があるんじゃないでしょうか（笑）。