ascii.jpこれを機会に、ぴゅう太のプログラミングに興味を持った方々に向けて、元ユーザーの立場から、ささやかながらアドバイスさせていただきたく。
※実機が手元にないので、もし間違っていたらごめんなさい
ぴゅう太のグラフィックスについて
ぴゅう太のVDPはテキサス・インスツルメンツ社のTMS9918である。色数は少ないながらも、少ないメモリ(16KByte)でシステムを構成できることから、当時MSX、ソードM5、セガSGシリーズ等にも採用された。
ぴゅう太のグラフィックは、MSXでいうところのスクリーン2に相当する。8×8ドットのPCG(ぴゅう太では「セル」と呼称)を32×24、計768個が並べられ、全てのセルに対し個別にドットパターンを設定可能。
スプライト(ぴゅう太では「アニメ」と呼称)は32個あるが、BASICで制御可能なのは4つのみ。倍角固定であるため、サイズ的には32×32ドットである。
ぴゅう太のアーキテクチャとして特徴的かつ一番のアドバンテージであった点として、標準でグラフィックエディタを内蔵していた点が挙げられる。まずグラフィックエディタで画像を作成し、その画像に対しBASICによりプログラミングで操作する。これは当時としては画期的かつユニークなアーキテクチャであった。当時の多くのパソコンでは、グラフィックの描画を行うために、LINEやPAINTといったBASICのコマンドを駆使し、苦労の割に中途半端な表現しかできなかったのに対し、ぴゅう太ならばグラフィックエディタで時間をかければかけるほど凝ったグラフィックを作ることが出来た。
ぴゅう太のBASICコマンドについて
前述のグラフィックモードで絵を描き終わり、これ以上編集する必要はないと覚悟を決めた時点で初めて、BASICコマンドを入力するモードに移行することが出来る。
(ぴゅう太ではメモリの制約上、一度BASICモードに移行した場合、再度グラフィックエディタに戻るとそれまで打ち込んだプログラムは消去されてしまうため)
グラフィックモードからG-BASICの入力モードに移行するには、MODキーから呼び出せるシステムコマンドモードから「GBAS」と入力する。コマンドの正式名称は「GBASIC」であるが、ぴゅう太のコマンドは全て最大4文字で構成されているため、「GBAS」のみ入力すれば良い。同様に、プログラムを実行するためのコマンド「シ゛ツコウ」(一般的なBASICのRUNに相当)も、「シ゛ツコ」のみ入力すれば良い。
ぴゅう太のBASICコマンドは、当時の一般的なBASICを日本語に変換したものにほぼ準ずるが、より簡略になっている。
・変数への代入「シキ(LET相当。一般的なLETと同様、「シキ」は省略可能)」
・IF～THEN～GOTOに相当する「モシ＜式＞ナラバ＜行番号＞ニイケ」
・FORループに相当する「マワレ ＜行番号＞ ＜変数＞＝＜初期値＞ カラ ＜最終値＞ カンカク＜変数への加算値。1ならば省略可能＞ 」
・セル間のグラフィックパターンのコピー「セル(ｘ)＝セル(ｙ)」
・スプライト座標操作「アニメ＜1～4＞＝イチ（ｘ，ｙ）」
・8文字分の数値もしくは文字列の表示(PRINT文相当)「カケ(セル番号)，＜変数名＞」
・4種類の内蔵音声の再生「オト ＜イチオン｜ニオン｜サンオン｜シオン＞」※それぞれ「ピッ|ブー|ピロン|爆発音」に対応
・タイマー制御による割り込み処理「タイマｘオン～モシ タイマｘ＝＜時間(1/100単位)＞ナラバ＜行番号＞ニイケ」
・ペリフェラル入力の取得(ジョイパッド、もしくはキーボード)「キイ＜1|2＞」
メモリの関係上、入力可能なステップ数は少ないにもかかわらず、IF～THENの後にはGOTO文しか指定できない、マルチステートメント記述不可、配列変数が使用できない(仮に2プレイヤーでの対戦ゲームを実装する場合、同じプログラムを2重に書かなければならない)等の厳しい制約がある。限られたメモリでプログラミングするために、相応のテクニックが必要(後述)。
一方、ぴゅう太でのみ使用可能なユニークな機能として、1/100秒単位で計測可能なタイマー割り込みを最大7つまで使用できる機能があった。具体的には、自機と弾を異なる速度で制御しつつ、1秒ごとにタイマーをカウントダウンするといったような処理を簡単に記述することが出来た。
ぴゅう太の計算能力
ぴゅう太で使用可能な数値はMSXと同様16ビットであるが、MSXが-32768～32767までの範囲を表現できたのに対し、ぴゅう太では「-32768～32767」と「0～65535」との2種類の解釈が可能であった。この矛盾した解釈による弊害として、マイナスの値の掛け算の結果が正常に取得できないという「仕様」が存在した(一見バグっぽいが、理由も含めてマニュアルに表記されていたため、仕様と解釈するのが妥当であろう)。
CPUのTMS9995には乗除算命令もあり、加算しか無かった当時の主な8ビットCPUよりは優れていると思われる。実装次第ではワイヤーフレーム程度の3D表現ならば可能であったのではないかと推測される。
VRAM上に描かれたグラフィックパターンを識別する方法
現代のゲームにおいては、地形コリジョン(当たり判定)を処理するために、表示とは別に専用のデータを持つことが一般的である。しかしメモリが貴重だった時代においては、VRAMに描画されたグラフィックを直接読み込んで判定するというテクニックは一般的であった。
ぴゅう太に付属されていたマニュアルには、VRAMを直接読み込む方法は解説されていなかったが、後にユーザーによって発見された。私自身も、当時のマイコンBASICマガジンの余白に掲載されていた投稿「画面を読み取る方法を発見した」を見て、独学でやっとその方法を発見した。
この機能が使えるのと使えないのとでは、ゲームデザインに大きな違いが生じる。床や壁を判定できるというだけでも、作れるゲームのデザインは飛躍的に向上する。
方法自体はさほど難しくなく、＜変数名＞＝セル(＜セル番号＞)を実行する事により、セルのビットマップパターンを変数に代入することが出来るため、IF(モシ)文による比較が可能となる。
当時はこの変数に何が代入されるのか分からなかったのだが、どうやらセルの上位2ライン(上部の16ドット分)のビットパターンが代入されるようである。よって、正しく判定させるためにはグラフィックモードでのデザインを工夫する必要がある。例えば、パックマンのようなドットイートタイプのゲームを作る場合、セルの中央にエサのドットパターンを描くようなデザインでは、空白パターンとの区別がつかない。
ぴゅう太のプログラミング容量
BASICで入力可能な容量は、本体付属のマニュアルには「最大100ステップ前後」と記述されていた。これはプログラムの書式により異なり、ワーストケースでは80行程度で上限に達することもあった。
プログラム容量がオーバーした場合、画面上にたった一言「ハ゜ンク」と表示され、それまで入力していたプログラムが化けてしまう。
(私の経験では、英字だった変数などがカタカナに化けてしまった。その後リカバリ出来るかどうかは不明)
限りあるプログラム容量を有効活用するテクニックとして、「よく使うリテラルを変数として定義しておき、可能な限り変数を参照する」というものがある。
具体的には、
A=0
モシ B=0 ナラバ 10ニイケ
と書くところを、代わりに
S0=0
A=S0
モシ B=S0 ナラバ 10ニイケ
というように記述するというものである。S0の出現頻度が多いほど、効果は高くなると思われる。
手元に実機がないので確認はしていないのだが、当時メーカーから発売されていたBASICのプログラムでこのテクニックが使用されていることから、メモリ節約の効果があると推測される。モトローラ68系や日立SH系のアセンブラでプログラムを書いたことがある人ならば何となく予想できると思うが、16ビットのリテラルを直接表記するよりも、変数を8ビットのインデックスで指定したほうがメモリ消費が少なくて済むとか、おそらくそういうアーキテクチャだったのだろうと推測する。
以上をふまえた上で、ぴゅう太のプログラミングを楽しんでいただきたい。
(画像は昔描いた、ぴゅう太の擬人化キャラ)