やっとC-GRACEのメインプログラムであるエグゼキューターとサンプルCGデータの打ち込みが終わったので実行してみました。

MZ-2000も320×200ドットまたは640×200ドットのグラフィック能力を持ってました。しかし、標準BASICのグラフィック命令は貧弱で、PAINTにFM-7やPC-8801などで使えたタイル機能が無かったので中間色ペイントが出来なくて、ここまでの絵を出すのはかなりの労力が必要でした。他機種のCGプログラムを移植しようとしても、躓くのは色を塗りつぶすところでした。
なので、当時テクノポリスに掲載されたこのプログラムを実行したときは心底驚きました。グラフィックツールなども存在してたのですが、購入にまで至らなかったので、この手のCGを実際に見る機会はまずありませんでしたので。

久々に見ると細かい色合いがなかなかいい感じです。フルカラーCGがあふれかえる今日ではドットの荒い絵だと感じると思いますけど、まあ、そういう時代があったのでした。

ASCIIの最後の１本を打ち込み終わったので、マイコンゲームの本４の続きを。MUSIC MANは音階毎にプログラムが似通ってるので、値の違いを直すだけで簡単に終わりましたが、F.B.Iで少し苦戦しました。こちらは掲載ソースに印刷されないグラフィック文字があってそれを特定するのに時間がかかりました。実行してみると、グラフィックが崩れてる部分が多く見つかり、打ち間違いかな？とか思ってたら間違いは見つからず。PRINT LEN(変数)で実際の長さを調べて欠落してそうな部分を特定していき、記事の写真を参考にしながら手直ししていきました。ペイントにスクリーンショットをペーストしてドットの構成を調べたりして、印刷されてないのがCHR$(31)に相当するチェッカーマークとCHR$(32)の黒四角文字と気づいて何とかそれっぽく手直しできました。狙撃時の画面がもしかすると大きく違う可能性がありますけど、もう手直しはお手上げなので諦めです。この時代のＩ／Ｏのde BUGを調べてみましたけど、掲載はなさそうです。マイコンゲームの本には過去のデバッグ情報はないので情報があれば欲しいです。

続けてWICS関係も入力してます。WICSだとソースをコンパイルすれば文法エラーととび先が無い箇所は特定できます。問題は変数名の打ち間違いとかのオペランド部分の間違いがわかりにくいので、結局ソースを見比べて直すしかないです。後は動かして挙動のおかしい部分を見直すとか。()と[]の打ち間違いも見つけにくいので苦戦しました。READ~DATAの機能がないので、データは配列を経由してメモリに書き込む形で、これがA[0]=1というような代入がずらずらと続くという。行の節約でマルチステートメントになるのですが、これがまた打ち間違いの発見を遅らせる要因だったり。素直にダンプリストで公開されてる方がミスが少ないかもって思いました。

あとは長いプログラムがいくつか残ってるのですが、地道に打ち込んでいこうと思ってます。並行してC-GRACE辺りも何とかしたいです。