PC-8001 NCHアトリビュート制御 : プログラミング指南

今回はアトリビュート制御の苦労話です。PC-8001 でがっつりゲーム制作をしようとすると、その制御は避けて通れないですよね…。

アトリビュート制御

最初はアトリビュートは画面上のキャラと1対1で用意して、画面切り替えの前に本来のアトリビュートコード形式に戻して BAN!と画面を切り替える予定だった。…だった。そう過去形です。画面切り替えを前提としていたこの方式は、cocopar の液晶モニタのせいで、不採用となってしまいました。

仕方がないのでリアルタイム制御に変更してみましたが、うん、やっぱり完全な実装は、かなり困難な道であることが分かりました。このブログをご覧の人ならある程度は理解しているかもですが、PC-8001 のアトリビュートは以下のような構造になっています。

この構造、想像以上に制御が面倒なのです。一番簡単なのは、距離なんてなくて、そのまま色も指定できる形式です。架空のアトリビュート構造を挙げるとしたら以下の感じでしょうか。
架空のATRB構造

上記二つは、色構造的には同じだったりします。赤が2つ続いて、次に白が2つ続いて、さらに赤が4つ続いて…という内容で全く同じ構造です。詰まるところコレは連長圧縮されている状態になります。つまり、アトリビュートの書き換えとは、圧縮状態のまま、その中の数値情報を書き換える動作なのです。速度的にもこれはかなり無理だわｗ

※限定された状況を除く

発想を変える

アトリビュートの書き換えが難しいのであれば、発想を変えよう。そうだよ、書き換えなきゃいいんだと。連長圧縮方式最大のメリットは高速に展開と圧縮が出来る事です。で、あれば、アトリビュート情報を解凍して、色などの情報を変更してから、もう一度圧縮し直せば良いのではないかと。

早速プログラムを組んで試してみました。重い…が、ギリギリ許容範囲か。そこで高速化のために必要最小限でデータ圧縮してみて、アトリビュートに反映させてみました。が、これがゴミるんです。なぜだ？と調べたところ、意外な事実が分かりました。

アトリビュートは左側からの距離と色コードのペアで構成されています。最初は何を書いても$00にみなされました。左側から位置を指定してるから、これは分かります。画面幅は最大80文字だから$50が最後になる。これも分かります。

アトリビュートエリアは、1行に40バイトあります。例えば、色変更が2か所しか無ければ…

6バイトで表現としては終わります。では、後ろに余った14バイト、どうなると思います？驚いた事になんと機能しとりやがるんですわ！

なので、必要な分を正しく設定しても、後方に余分な設定値が残っていると意図しない画面表示になってしまうのです。上記はそのテストでアトリビュートが崩れた状態です。

この実験結果から、アトリビュートエリアは各行40バイト分全てを正しく設定する必要がある事が分かりました。全部設定しなきゃならない。こんな仕様じゃ手間かかるだけだから、あとたったの 1KBをメインRAMから割り当ててあればと、泣きたくなりました💦

ということで、後ろは $50, $00, で埋め尽くす事になりました。