わたれ！国道三号線 1
マシン語の本を手に入れて、早速マシン語に着手する輪太郎。さてどんなものを作りますか。
あれからさらに1か月。
今は11月末。正確には11月24日だ。
さっそく10月以降の進捗を話しておこう。
アセンブラ関連の書籍を手に入れた俺はさっそく友達の家でZ80向けアセンブラのテストを始めた。
最初のターゲットは高木君のX1、正確にはX1F(CZ-811C)だ。
木村君のMSX、Casio PV-16はメインメモリが16KBなのに対して、高木君のX1はメインメモリが64KB。
CPUはほぼ同じなので、メモリが多いほうがプログラム作成上のハードルは低くて済む。
完成したら木村君のMSXにも移植することを前提に高木君を優先する許可をもらった。
早速、プログラムを開始する。
と言っても、MS-DOS環境じゃないので単体で実行ファイルが作れるわけじゃない。
なにしろ、OSが無いのだから。
じゃあどうするか？
ここで行うのはBASICからマシン語を呼び出しする方法だ。
一度BASICで完成形のプログラムを作る。
BASICで作るので、一部の処理については大変に遅くなるのだが、この遅い部分を順番にマシン語の関数に書き換えていく。
そして、作ったマシン語の関数をメモリ上に登録しておいて、BASICから呼び出し、遅い部分を高速化するという手順である。
仕組みとしてはPythonからCのライブラリ呼んで処理を高速化するような感じである。
プログラムとしての見通しは悪くなるし、Pythonの場合と違い、分割して単体テストというのも構造上難しい。
しかし、無料のROM BASICから起動できるし、速度は劇的に向上することが見込める。
また、X1ではマシン語ルーチンが１０種類まで呼び出せたので、処理単位でテストして１つにまとめるなどが行いやすく、柔軟に組むことができた。
大変メリットの多い方法だと言える。
デメリットとしては、プログラム自体が丸ごと失われる確率が結構あること。
マシン語プログラム中にミスすると、起動中のシステム自体を破壊できる。
なにしろ、BASICとは違ってマシン語は何でもできてしまう。
データを書き込む際、ミスをすると壊してはいけない部分にも容易に書き込みを出来てしまう。
メモリ上にあるBASIC本体の記録されている領域への書き込みさえ可能なのだ。
そのため、書き込み先のアドレスを間違うと簡単に暴走し、リセットせざるを得なくなる。
そうなった場合、事前にプログラム本体を保存しておかない限り、リセットと同時に作成していたプログラムはきれいさっぱりさよならバイバイだ。
だから、マシン語ルーチンを呼び出すタイプのBASICプログラムは、まずはノート(ノートパソコンではなく、キャンパスノートの方のノートだ)上でプログラミングを行い、それをBASIC用のエディタで入力し、必ずメディア(X1やMSXの場合、基本的にカセットテープになる）へと保存し、それから実行テストを行う段取りとなる。
ここで保存を忘れると、バグがあったとき取り返しがつかなくなる。
作ったプログラムを修正する場合も、マシンをリセットして、テープから前のソースをロードして、そのソースを書き換えて、再度保存した後実行をという手順になる。
当たり前だと思うだろうが、ついつい保存せずにやらかしてデータを消すのが人間ってものである。
俺の事だね。
ちなみに、"クリーン設計"のX1の場合は、他のパソコンだとROMから読み出すBASICすらカセットテープから読み出すので、通常の手順のほかに、BASICを呼び出すという手順がもう1手追加になる。
余計な時間が増えるのはちょっと面倒だが、X1ではカセットからのデータの読み込みが高速だし、そもそも仕様だから仕方ない。
というわけで、状況的にただでさえプログラムに時間がかかるようになったのだが、それより不評なのは不具合を出してしまったときだ。
俺がプログラムでミスをするたびに、X1が異音を上げて停止したり、画面が壊れたまま固まったりしてしまう。
そのたびに、プログラムを読みだしては処理の途中まで実行させ、どこまで正しいかを調べ、固まった場所と症状を見て、不具合をあぶりだす必要がある。
当然、その回数分だけ異音をあげて停止したり、画面がおかしくなって固まったりが発生する。
この暴走を繰り返すコーディングは高木君からの評判が大変に悪く、おまえうちのパソコン壊しに来てるんじゃないだろうなと言われる始末だ。
とはいえ、それもプログラムが進むまで。
最初は画面に白の点を打つことから始まり、まずはVRAMを全部単色でクリアしてみる。
それがすんだら、グラフィック用のプレーンに簡単な(LINE文で描けるような）グラフィックを表示したり、TEXTプレーンのフォント形状を書き換えて画面いっぱいにキャラを並べたりする。
そこまで行くとあとは大きなミスもなく、大きめの2等身のキャラがアニメーションするようになった。
その後、カーソルキーで上下左右に移動できるようになったり、前後左右を向くたびキャラクタの画像が変化したりと作業が進むにしたがってみんなワクワクした目で画面を見るようになった。
完成したのはフロッガーもどきのゲーム。
女の子が複数車線ある道を行きつ戻りつしながら車をよけて大通りを渡るだけのゲームだ。
各車線には長さの異なる車が走っており、車と車の隙間を狙ってよけながら渡るというもの。
よくあるタイプのゲームだが、一応、簡単に歩くアニメーションを入れたので、それなりに動いて見える。
車のタイヤも回るし、手足が動くし、髪の毛も揺れるし、スカートも”ひらっ”とかする。
ただ、残念なことにX1はRGB3色のオンオフでしか色表現が出来ない。
つまり、色数は決め打ちの８色しかない。
ドット絵自体はかなり頑張って作ったのだが、どうしても色数が足りず、キャラの服装がなんとなくうちの小学校の女子の制服みたいなデザインになってしまった。
だいぶ頑張ったんだが、泣く子と色数には勝てない。
まあ、前向きに考えると見知らぬ色の制服よりはいいかなと。
いっそのこと似せてしまえと、あえて制服風にしてしまったりする。
ただ、俺の友達二人がスカートの色を見てから、やけにひそひそ話をし出した挙句、謎の盛り上がりを見せていたのがすごく気になる。
なんだ？2次元萌えの新しい扉でも開かせてしまったのかしらん。
日数を経るにつれ、プログラムはどんどんマシン語に書き換えられていった。
最終的に、キー入力と背景音並びにキャラの移動する位置情報はBASICで、それ以外、つまり主に画面を描画する部分についてはすべてマシン語で、という構造になった。
まあ、BASICを使ったマシン語プログラミングの場合、だいたいこのような形に落ち着くんじゃないだろうか。
理想を言うならBASIC側はマシン語ルーチンをメモリ上に読み込むだけ、あとは全部マシン語でプログラムするのが速度だけを考えれば一番なのだが、さすがにそこまで全部マシン語にすると今度はデバッグのほうが面倒くさい。
マシン語を使った最初のゲームとしてはこんなもんじゃないかと思う
完成したゲームを見て高木君と木村君は大喜び。
早速、クラスの友達を呼んでゲームを発表しようと言い出した。
とは言え、まだ起動したらタイトル画面もなく、いきなり道路と女の子が表示される状況、車にぶつかってもビープ音を鳴らすだけ、クリアできてもご褒美無しの状況だ。
俺としては出来れば、その辺を何とかしたい。
何しろゲーム名すら決まっていないんだから。
