さて、各部を解説していきたい。ついてこれる奴だけついて来い！
・CPU
Microchip PIC16F88/20MHz。メジャーな８ビットマイコンを採用。全てアセンブラで記述。
プログラム領域は２ページ４Ｋワード、でギリギリ状態。幕間デモとかネームエントリーとか入れる余裕はまったく無くなった。サイズを減らすためにサブルーチン化をやりすぎると、スタック８段をすぐにオーバーして突然動かなくなる。ＣＡＬＬの深さに注意しながらサブルーチン化を行なった。
入出力ピンはポートＢ０〜７をデータバス用として、その他制御用にポートＡ０〜６を使用。
水平走査線数を数えるためにタイマー割り込みを使用。
・表示システム
スクリーンは３２ｘ３２個のキャラクターで構成される。
１キャラクターは８ｘ８ドット３プレーン、１ドット８色。パレットなし。
各キャラクターは１バイトで指定。よってキャラクターの種類は２５６種類。
ＲＡＭのアドレスマップは以下。
| 開始 |
終了 |
用途 |
サイズ(KB) |
| 0x0000 |
0x07FF |
スクリーンデータ/ワーク |
2 |
| 0x0800 |
0x0FFF |
キャラクターデータ（赤） |
2 |
| 0x1000 |
0x17FF |
キャラクターデータ（緑） |
2 |
| 0x1800 |
0x1FFF |
キャラクターデータ（青） |
2 |
| 0x2000 |
0x7FFF |
非接続 |
24 |
キャラクターデータはＲＯＭから読み込んでＲＡＭに書き込む。
キャラクターＲＯＭは３２Ｋバイト。同時に使える２５６個のキャラクターデータが５ページ分は入るが、タイトル用とゲーム用の２ページ分しか使用していない。
ＢＭＰファイルからＲＯＭバイナリを生成するプログラムも作成。こういうのはＣ＃で書くと超楽。
同期信号は、ＶＥＳＡ規格に合わせて、640x480@60Hz(VESA
STD) H:31.469kHz V:59.940Hz に近い信号を生成している。
ＲＡＭのアクセススピードは５５ｎｓで、２０ＭＨｚの１周期は５０ｎｓなので、アクセスに２クロック必要になる。もう少し速いクロックを使用すれば１クロックで間に合って、いろいろ余裕ができてドット比１：１も実現できたかもしれない。
・走査線同期手法
１フレーム内の更新はＶブランク期間では間に合わない。
ダブルバッファにするメモリもハードリソースもない。
なので、キャラクターを書き変えるときは水平走査の位置を調べて、書き変え中に走査線をまたがないように、水平走査線の通過待ちをしている。これでティアリングを回避できる。
・ＣＰＬＤの処理
１、同期信号を生成し、逐次ＲＡＭからデータを読み出し出力する。
画面は単純なビットマップ構成ではなく、キャラクター面構成になっているので、
１度目にキャラクター番号を読み、２度目にそのキャラクタービットマップデータを読む必要があるため、ＲＡＭのアクセススピード５５ｎｓ、ドットクロック２０ＭＨｚでは横３２０ドット程度が限界だった。６４０ｘ４８０の解像度は、ＲＡＭ容量やＲＡＭアドレッシング用のバス幅の関係で断念した。なので、水平同期信号は31.5ｋＨｚのまま、２ライン同じものを表示している。
１キャラクターは８ｘ８ドットで、横８ドットが１バイトのデータとして８バイト連続して並び、それが２５６キャラクター分並んでいる。そしてその２５６キャラクター分がＲＧＢ３チャンネル分並んでいる。
キャラクターデータをＲＧＢ各１バイトＲＡＭから読み出してドットクロックに合わせてＲＧＢ１ビットずつ出力する部分が９５１０８に入らなくなったため、９５７２側にその処理を移した。
９５１０８側はギリギリのところで合成されている。ずーっと入らなくて苦労していた部分である。
９５７２では色データを再構成する処理の他に、ジョイスティック読み込み、サブＣＰＵコマンド送信、キャラクターＲＯＭ制御などを行なっている。
２、ＣＰＵからのＲＡＭ読み書きリクエストに応じる。
ＣＰＵはまずＣＰＬＤにアドレスを書き込む。これは非同期に行なえる。
次に読み込みの場合、ＲＷを読み込みにしてリクエストフラグを立てる。データがＣＰＵ側に出力されたらレディフラグが立つのでデータを読み込む。リクエストフラグを下げる。
書き込みの場合はＣＰＵはデータを出力したままＲＷを書き込みにしリクエストフラグを立てる。ＣＰＬＤがデータをＲＡＭに書き込んだらレディフラグが立つ。リクエストフラグを下げる。
ＣＰＬＤ内部ではドットクロックに合わせて逐次ＲＡＭから読み出しているスキに、ＣＰＵからのリクエスト応じて読み書きしなければならない。ビデオデータの読み出し側が待つわけにはいかない。
ＣＰＬＤはキャラクターデータを横８ドット分まとめて処理するので、その期間をフェイズに分けるとかろうじて読みか書きのどちらか１回だけ実行可能なスキができる。その空いたフェーズにＣＰＵのリクエストを調べて読み書きの処理を行なっている。
・音声発生システム
サブＣＰＵでは音声を生成している。
ＲＯＭからＰＣＭデータをストリーミングしたチャンネルが１つと、矩形波で線形減衰する波形をシーケンス再生するチャンネル２つの計３チャンネルをミックスして出力している。
ＰＣＭはモノラルで量子化ビットは符号なし８ビット、サンプリング周波数は22050/11050/8269/5500Hzの４種類。音のタイプによってサンプリング周波数を変えている。低い音ほど低いサンプリング周波数にして容量を稼いでいる。ＲＯＭ容量は１２８Ｋバイト。効果音数は１３音で１２８Ｋバイトの容量をきっちり使い果たしている。
ポップコーン（ＢＧＭ）はシーケンスデータから矩形波を生成して鳴らしている。シーケンスデータは自分の耳コピーなのでまったくもって自信がない。つくづく音感がないことに絶望した！出力も８ビットで、ラダー抵抗でＤ／Ａ変換。その後３８６で増幅。ボリュームとスピーカに接続されている。
・筐体
今回どうしてもご覧のごついジョイスティックが使いたかったため、ケースを選択する余地が無くなった。ジョイスティックの深さ分の高さを持つケースなどほとんどなかったのである。唯一存在した高さ７５ｍｍのケースを採用した。実物を手にしたときは、けっこうでけえとか思ったりした。ケースの加工は、アルミ板をドリル、リーマー、ヤスリでひたすら削る削る削る。ハンドニブラの出番は残念ながら今回もなかった。ここでジョイスティックとスピーカが干渉する設計ミスが発生。スピーカを予定していたものより一回り小さいものにすることで回避した。
・アプリケーションソフトウェア
ゲームはペンゴである。題材としては最適。見た目は違うけど中身は同じものを作るよりは、中身は違うけど見た目は同じものを作ろうと思った｡移植する感覚か。なので、まったく同じものではないという意味でもタイトルに「ＴＲＩＢＵＴＥ」を追加した。
以下、オリジナルとの相違点を中心に解説。
オリジナルはスプライトを搭載しているのでその辺のシステム変更は大きい。全てをキャラクター単位で表現しなければならない。
オリジナルのペンゴは縦画面。横画面になってもゲーム性に影響はないだろう。
オリジナル操作は４方向１ボタン。ボタンでアイスブロックを押す、壊す、壁を揺らす。本ゲームでは
ボタンを排除して、ボタン操作を対象物方向への移動操作で代用した。ペンゴの向きはゲーム性に関係ないので、全体のゲーム性は大きく変わってはいないだろう。
デモ画面、リザルト画面、幕間デモ、ネームエントリー画面はＣＰＵプログラム容量の関係で割愛した。
滑るブロックと敵のコリジョンはオリジナルに比べて相当甘い。半キャラずれは当たりになっているから、気持ちよく敵を潰しまくれるようになっている。
敵の卵まわりの使用がオリジナルといろいろ違う。卵の入っているブロックを壊しても卵が割れる絵は出ない。また、卵から生まれている最中でもブロックで潰すことができてしまう。
オリジナルでは最後の１匹は逃げ出すが、本ゲームでは逃げない。
１ＵＰなし。
敵のＡＩもあまり凝ることができなくて残念な部分ではある。
・まとめ
アセンブラのコーディングは面白い面もありつつ、キツイ部分もあったりして。ゲーム機製作プロジェクトは当分いいわって感じ。次にやるときは順当にスプライトエンジン（ラインバッファ）の実現がテーマになると思われ。また長い構想期間に入るとしよう。
さて、これでようやくモニタをＸＢＯＸ３６０に繋ぎなおせるということでもあるわけであります。
久しぶりに火を入れてみようかな。
・・・
・・・
しまった、
