物　置


img
ひとやすみ　ひとやすみ…
■　物　置

いつも通りだらだら書く。時系列はいいかげん。

PC88 でアクションゲームといえば、キャラクタの動きが 8 ドット単位の粗いものがほとんどだったが、
ドット単位でスムーズに動くものも少ないながら存在した。

しかし頑張っても MSX1 程度のものが出来るかどうかというレベルで、労力に見合わないだけでなく
処理は複雑になり速度やメモリにも制限が出てくるので、結果として少数にとどまったように思う。
雑誌広告で見る静止画像では動きまでは分からないので、実際の動作を見てがっかりするのは毎度のことであり、
それを踏まえてユーザー側もスペックに見合ったゲームでよしとする空気はあった。

加えて残念だったのが、移植の都合や販売上の問題で SR 世代(=4MHz) 縛りだったり、当時としては贅沢な拡張機能も積極的に使われずに終わった点。
有名なサウンドボードII にしても、左右にパンを振っただけのゲームは意外と多く、拡張 RAM もディスクキャッシュ程度の利用がせいぜいだった。
なので市販ゲームを基準に PC88 シリーズ全体の歴史的な性能評価が決まってしまうのは少々惜しい気がする。
変に神格化されるのも低すぎる評価も実感としてズレがあるというか。

というわけで、実機が動くうちに出来る範囲でいろいろやってみようと思った。
いくつか暖めてあるアイデアもあるので、その検証も兼ねて『実際のところどれくらいまでやれたのか』を確かめてみたい。
いうなれば、30年越しの宿題ってところか。遅すぎだよ。

ぶっちゃけ当時のアーケード移植モノの出来に納得いかなかったというのも理由のひとつ（小声）。


例によってこのページは気分次第でさっぱり消滅する。
個別の実験の成果はそのうち何らかの形でフィードバックするつもり。

対象機種は最後期の機種の予定。なので文中 PC88 とあるのは、おおむね 88MC (推奨)の意。
スクリーンショットを撮り直すのが面倒なので、文面と違う箇所がある。


以下つくりばなし。

見通しが明るくないので没になってもダメージが少なそうな所から開始。

何から手をつけていいか分からないときは、とりあえずフォントを作っておけば間違いない。



字間が狭めだけど文字を読むゲームじゃないし許容範囲かな。

ALU 論理演算をつかった書き込みでは単純な上書きが出来ない。
いったん消してから書くことになるので 3プレーン同時アクセスでも労力は 1/3 ではなく 2/3 程度になる。
フォント書くだけなのに微妙に手間が増えてしまうのはもやもやする。

画面の縦横比とパレット割り当てが決定してからなので、実際に画面に文字が出たのはしばらく後の話。


ALU 機能のおさらい。
モデルは赤毛の人。また髪の話してる･･･。



キャラクタ（大）の描画。
64x32 ドットサイズを ALU を使って背景と重ね合わせ。
32x32 でなくて 64x32 なのは、PC88 のドット比率が 1:2 で縦長だから。
横を2倍に太らせてやることで縦横比を合わせるのである。フル画面解像度は 640x200。

最初から 320x200 なら少しは楽できたかな ?
まあそれだとデジタル 8 色のタイリングみたいな文化は発達しなかったかもしれない。

スプライトなら座標や属性情報の数バイトで済むところが、画像データそのものを描画しなければならないので、これだけで 1KB が必要になる。
VRAM アドレス計算の手間など、PC88 で何をつくるにせよ描画が最大のネックになる。



ALU 描画の場合、マスクは左ではなく右のようにキャラクタ部分を 1として作っておく。
ものによっては RGB 3プレーンデータの OR でも良いが、ヌキ色でない黒が出せなくなるし手間がかかる分だけ遅くなる。

ALU で論理演算を挟む場合でも 3プレーン同時アクセスする場合でも、いずれも 8bit が単位となる。
なので、16bit ずつ pop で読み込んで VRAM to VRAM コピーするような高速化は期待通りには動かない。

PC98 の GRCG はもう少し高級なんだっけ。


PC88 は 640x200 ドットの画面で 横 8 ドット = 1byte なので 80byte * 200line = 16000byte の VRAM が $C000 以降に配置されている。
範囲でいうと $C000-$FE7F にあたるが、その後ろの $FE80-$FFFF は何なのか疑問に思ったので調べてみた。

結論としては、普通に VRAM だった。
384byte * RGB 3 プレーン分あり、画面に映ることは無いが、しっかり ALU 機能の対象にもなる。
厳密なアクセス速度などは不明。

まあ、律儀に 200ラインを超えた部分を除外する方が面倒なので、当たり前といえば当たり前なんだけど。


j80 のデバッグ機能をちょろっと使う。
筆者の環境では窓を沢山開いていくと画面が狭くなって少し不便なのだけれど、
色々ユニークな機能もあるのでこの機会に慣れておきたい。

範囲をドラッグで選択して逆汗というのは他では見たことが無い面白い機能だと思う。

サウンドボードII の $46,$47 側を操作中に $44,$45 側を弄ると、前者が影響を受けてしまうような気がする。
詳しくは調べていないけれど、ジョイスティック周りを弄っていると ADPCM メモリからの読み出しが化けてしまう。

検証プログラムを作ったので置いてみる。adpcm_test4.zip
j80 だと読み出した文字列が安定しない。実機だと問題なし。

修正済. thanks!

ここは地獄の激戦区エリア(PC)88。
ただしマッコイじいさんはいないので、メンテの怪しい機体で動くかどうかは本当に神(ｱﾗｰ?)次第である。
バックアップ電池くらいはそろそろ外しておくべきか。


実現できるかどうか全く自信がなかったので、当初の計画ではキャラクタを適当にでっちあげてテストするつもりだった。

･･･だったんだけど、よく考えてみるとキャラクタが表示される範囲や、背景の使用状況など
実際のゲーム画面に沿ったシステムにしなければ、うまくいかなさそうな気がしてきた。

とりあえず実物に近い画面を作ってからシステム方面に手を付けることにする。
ドット打ちは苦手だ。

画面が出来てしまうとテンションがそこでピークになってしまって、後の地味な作業がおろそかになってしまいがち。もしくはそこで挫折とか。
派手な見た目を作るのは楽しいしウケも狙えて制作過程の中で一番おいしい所でもあるけれど、実際はそれ以外の作業が 9 割方を占めるわけで。




こんなものか。


できらあ！！


別件だけど N88-Disk BASIC が 12KB もあって震えている。
そういえば使ったことのない命令が山ほどあったっけ。


タイトルロゴ(仮)。



メモリ圧迫しまくりなので置き場所に超困る。
マスクなしで約 16KB という巨大サイズ。これがビッグデータってやつか（違）
なお、この PNG 画像ファイルは 3KB である。

これがドット単位で上にずりずりと動く予定。


ゼ○イゼと似てるのは分かるけれど、そっくりとまでは思わなかったなぁ。


その昔、Namco History Vol.1 という Windows95 用のゲーム集が出ていて、
当時これを DX4-100MHz のマシンで動かしていた。
収録ゲームはマッピー・ゼビウス・モトス・スーパーゼビウス・トイポップ。

しかしこれがあまりにも遅く、CPU が貧弱ということを抜きにしても腑に落ちないレベルであったため調べたところ
どうやらエミュレーションで動いているらしいということが分かった。
それは、、、遅いよな。。。

まぁ遅いのを気にしなければ、ちゃんとエミュレーションできているのは当時としても頑張った出来だったと思う。
DirectX も 2 とか 3 の時代で、Windows 上でゲームらしいゲームが出来ること自体が嬉しかったのを覚えている。

0x00024C28


今のうちに実機でいろいろテスト。

デバッグ用にテキスト画面が使えると便利だ。
DMAC の設定で通常のテキスト VRAM の範囲 $F3C8-$FF7F を $80 だけ後ろにずらして $F448-$FFFF に変更。
アドレスの下位に x 座標(0-79)を足すときの繰り上がりが $48 だと無くなるので、少しだけシンプルにできる。


必要な諸々を揃えるかたわら、ディスク周りを改修する。
自作の簡易 DOS をそれなりに安定して運用できているので、大規模な書き直しは必要ないのだけれど
ディスク側のメモリに置いておきたいデータや、それをメイン側に転送する仕組みを備えておきたい、と。

ということで手をつけたものの激しくつまらない。完成形が見えないのがつらいのだろうなぁ。
どこまでやっても何か足りない気がするし、使わないものを付けてしまったかもという蛇足感もある。
テストしてみたら全てのルーチンで何かしらバグっていた。やる気なさすぎ。

そういえば、メイン/サブ CPU を両方とも常時駆動しておかないと書き込みに失敗する不具合に初めて遭遇した。
流れを追っていくと、ロジックが間違っているというよりタイミングの問題っぽくてしばらく悩んだ。


ディスクに書き込むまでもないプログラムは PC でコンパイル → 実機に転送・実行のサイクルが面倒くさい。
少しずつパラメータを変えながら、のような場合は特に手間がかかる。
シリアルポート経由でのテストが行えると便利だと思ったので、バイナリをローダー付き BASIC ファイルに変換するスクリプトを書いた。
ほとんど transdisk の真似である。



転送は Acknowrich で行う。編集→ファイル転送で送りたいファイルを「送信」で選ぶ。TeraTerm とかでもいいはず。
設定は 9600bps, Parity=NONE, StopBit=1.0, Length=8, あとは一応 BINARY モードにしておく。



転送するプログラムの方は、ASCII 形式。ファイルの最後に Direct Statement Error でエラー終了するようにゴミをわざと入れておく。
PC88 の方では load"COM:N81X"を実行する。転送レートは 9600bps で特に困らなかった。

bload でも COM デバイスのファイルディスクリプタは使えるようなのだけど、BASIC と違って見た目でちゃんとロードできたかどうかわかりにくい。
BASIC だと送った後での編集も楽だし。

D88 ディスクイメージへの BASIC ファイルの読み書きは D88SAVER でかなり楽になった（ステマ）。


画像データからキャラデータ作成。
あれこれスクリプトを書き散らかしたわりに得られた経験値はゼロに等しい。
すぐ忘れるので「バイナリ 読み込み」とかで毎回ググってしまう。

Z80 の命令もうろ覚えなのでよく間違える。ローテート命令関係はもはや覚える気すら無い。
今となっては全くの無駄知識だけど。

最近一番役に立った知識は「フランスパンの上手な切り方」くらいか。

msdos.exe や cpm.exe にも世話になった。良いツール類がレガシーになっていくのは切ないなぁ。


ワイ、ついにホストをエラー落ちさせる Z80 コードを書いてしまう。




現在の色の割り当て。PC88SR 以降では 512 色中 8 色を選択できる。
ちょっと失敗したのが、緑系の色を割り当てなかったこと。
中間色でやりくりしてみたものの、ザラザラ感があってイマイチ。

緑系の色は背景のベースパネルやアイコンの選択など結構使われており、目にする機会も多い。
似たような白系色に 2 色使ってしまったのがまずかったかもしれないが、ここを妥協するとメタリック感が死んじゃうからなぁ･･･。


カタログ IP オープン化プロジェクト

マッピー！

ディグダグ！

ゼビウス！

モ…も…もじぴったん！　えぇー

というかスマホ向けだし関係ないな･･･。




オールクリア画面を作る。
これを見るとフォントも 1 ライン削った方が良さそうな気がしてくる。
下手に弄るとバランスが崩れそうで怖いが、フォントはいくら弄っても容量は変わらないので本番までに考えておこう。


いつから横画面だと錯覚していた？




どうか。
かなり印象変わって見える。ロゴ隠してもどこのゲームかパッと見分かるのが、ちょっと怪しく。
まあこっちで行きますか。文字を読むゲームじゃないというのをポジティブに考えよう。

このあとオリジナル通りウェイトをかけつつ表示できるようにする。

グロブダーとデンジャラスシードのフォントは同じかな。
E-13B -> Moore Computer -> Data70 -> Orbit-B という系譜か。


いまさらだけど、デススマイルズようやくクリア。
ｶﾞﾝﾊﾞﾘﾏｽｯ の人でボム使いまくりのパワープレイ。稼ぎとは無縁。
ラスボスはキューブ飛んでくるとこ以降避けられる気がしない。
ﾊﾟﾊﾟﾝ までノーミス安定できるようになりたい。


制作記録編集してるけど、イミフな愚痴が多くて笑うやら呆れるやら。


存在だけは知っていた MZ-2500 のイース3 を動画で見る。
結構な速度で動いていて感心した。画面の上下にゴミが出るのは仕方ないのかな。
音量バランスがやや残念か。

調べたら 6MHz で M1 に 1 ウェイトだったのか。実質 4MHz くらい?


80SR のパックランドはセミグラフィック画面で多重スクロールを実現しているのか。
元のゲームがベタ絵っぽいのをうまく利用していて、なかなかいいアイデアだと思った。
動画で見ると、遊ぶにはちょっ〜と辛いゲームバランスに見える。

ファミコン版は筆者も超がっかりしたクチだが、あれ以外にやりようは無かったようにも思う。


X1 のファンタジーゾーンを見る。
買い物とボスラッシュは未実装？
効果音が無いと寂しいけど PSG 3 音だと厳しいかな。

ここからどうすれば 4 ドット単位にできるだろうか。


MZ-700 版メトロクロスを見る。
想像を超えすぎていてヘンな声が漏れた。
大ジャンプ中のキャラが惜しい。


SFC のロードブラスター with MSU-1 は普通に遊べそうな完成度。
以前 bsnes 関連でちらっと目にした覚えはあったけどノーチェックだった。
4GB までいけるそうな。他の処理に割けるパワーは残っているのだろうか。


MZ-1500 のドルアーガ。
8x8 フォントなのにストーリー画面が綺麗に横幅に収まってる、と思ったらオリジナルと配置を少し変えてあるようだ。
本来なら 224 ライン必要なので 200 ラインのままでは収まらない。
オリジナルの誤字も修正してある。私ならそのままにしただろう。

1UP の文字が点滅していないってのはちょっと細かいかな。
2P 側が無い場合には点滅させる意味は確かに無いんだけど･･･この問題は本件でもどうするか結構悩んでいる。


CDOS2 を読み書きする機能が欲しいので todo に加えておく。
ディレクトリの扱いはどうしようか。


X68k マッピー。
WSG リアルタイムエミュレーションはいつか真似したい。


X1 ゼビウス(new)。
自機が敵弾より速いので簡単そうに見える。


FC 互換機の新作についての記事やコメントを色々読む。
取り上げられ方や受け止められ方が興味深い。

記事はおおむね予想通りだがコメントは割と冷静な印象。


入力まわりを作る。キーボードとジョイスティック両対応にしたい。

PC88 のキーボード I/O は贅沢にも 10 本の I/O ポートが割り当てられている。

同時押しに強いという点では今の PC キーボードより優れているかもしれない。
起動時に特定の複数キーを押していると裏技が･･･みたいなのも当時流行った。

80/88 系機種はカーソルキーが十字に配置されていないどころか、ニコイチにされていたり
使いづらいものが多かったのでテンキーを移動に用いるゲームがほとんどだった。

P6 ではサブ CPU に押されているキーを教えてもらう方式になった。これが長年よく分からなかったのだった。

ジョイスティックとすりあわせるため、右上なら 6+8 の同時押しのみとし、9 キーは反応しないこととする。
上下or左右同時押しは無反応が正しいっぽいのだが、どうしようか。




入力まわりが出来たので、ネーム入れを作る。
加速付きキーリピートにも対応した。

緑っぽい色が出せているのは妥協の産物。

中間色で作ってみたら我慢できないくらい汚かったので、泣く泣くアナログパレットを削って 1 色潰した。
よく見ると、ベースパネルの枠の色がここだけ灰色になっている(本来はもっと暗い色）。
そうは見えないかもしれないが、この画面だけで 8 色すべて使い切っている。

ゲーム本編はまだ全然動いていない。
にもかかわらず、そろそろメインメモリの心配をしなければならなくなってきた。

そういえばオリジナルは異様に速くネーム入れが終わる。せっかちだなぁ。


メーカーロゴを作ったままフォントデータに統合するのを忘れていた。
表示するまで気づかなかった。


アナログパレットとブランク期間の関係について調査しないといけない。
H-Blank で反映されると面白いけど、普通に考えて V-Blank だろうな。


>> そして、「SP からの相対位置で」示されるアドレスからの読出しができる。SPレジスタ相対アドレッシングだ。

LD HL,[SP+e] というニーモニックだけを見て書かれたのだと思うが、そんなロマンのある動作はしない。

しないのだ･･･。


縦画面のゲームはこのようにして作られている。

　　　＿＿＿
　　/　||￣￣||　　　∧∧
　　| 　||＿＿||　　（　　　）
　　|￣￣＼三⊂/￣￣￣/
　　|　　　　|　( ./　　　　 /

　　　＿＿＿ 　　　ｺﾞｷｯ
　　/　||￣￣||　＜⌒ヽ ))
　　| 　||＿＿||　＜　 丿
　　|￣￣＼三⊂/￣￣￣/
　　|　　　　|　( ./　　　　 /

　　　＿＿＿
　　/　||￣￣||　　　∧∧
　　| 　||＿＿||　　（　　　）
　　|￣￣＼三⊂/￣￣￣/
　　|　　　　|　( ./　　　　 /

　　　＿＿＿
　　/　||￣￣||
　　| 　||＿＿||　　　　　　　 ミ　ｺﾞﾄｯ
　　|￣￣＼三⊂/￣￣￣/ﾐ　,'⌒＞
　　|　　　　|　( ./　　　　 /　　l､＿＞



背景が鮮やかな緑や紫の画像を見つけてしまうと、以後マスク付き画像にしか見えなくなる現象。


OPNA のレジスタは 2 バンク分あるけれど、演奏に必要なものは 254 個に収まる。ｺﾞｸﾘ･･･


（おしえて）ほしいものリストは積み上がるばかりである。
88に限らず、古書に頼り切りな面が多い。
調べて分からないものを放置しがちなのも良くない。あとになれば分かるというものでもないし。
既知の項目も、archive.org にありまぁす、ではなくてまとめ直す必要もあるのかもしれない。

他のマイナー機種はもっと大変だろうな。


ソースに自分の書いたコメントが『ただし、』で終わっていて非常に気になる。
書くのをやめたってことは勘違いか重要なことではないのか、ただし君に用があったのか･･･。


マップデータが出来たので画面の仮組み。
やはり見た目のインパクトは大きい。このままいけそうな気がしてくるがゲームのコードは全然書けていない。



中間色は大体こんな感じ。ベタ色にするとちょっと見るに堪えなかった。
面によってはパレットアニメーションするベースパネルがあるが、さすがにそれは厳しいのでパス。

外周の宇宙空間の乱数に Z80 の R レジスタを一部使っているんだけど、妙に周期的になってしまって往生した。


「やる夫と学ぶホビーパソコンの歴史」読了。
8bit 御三家のひとつである 88 だけど、スペックでみると際だって優れているわけでもないんだよなー。
コストパフォーマンスとか発売タイミングとか色々な要素が絡んだ結果なのだろうきっと。
でも今の知識を持って過去に戻っても、やっぱり 88 は欲しいかも。

スペックが横並びになってしまったのは当時の PC シーンとしては不幸だった気がする。
何も同じ FM 音源つまんでも、と思うよね。


CRTC & DMAC は実はよく分かっていなかったりして。
テキスト画面の行数を自由に増やしたりできれば色々と面白いことができそうなんだけど･･･。30行計画的な。

現役当時は CRT 壊すのが怖くてテストできなかったし、今は今で再現性に難ありな気がして二の足を踏む。
特定の CRT でしか再現できない謎エフェクトとかあるのかもしれない。

よく分からんといえば、グローディアのゲームとかいまだに仕組みが分からない。


似たようなプロジェクトを見てしまうと、つい比較してしまう。
ダラダラ進行はいつものことだけど、長期間やっていてもクオリティに反映されないと意味無いよなぁ。

オリジナルは短辺の解像度が 224 で PC88 の 200 では足りないので 7/8 サイズの 196 にしている。
フォントやマップキャラクタも 8x7 相当, 16x14 相当で作ってある。

内部的には 224 で座標を持っており、表示のみ 7/8 に変換している。
理屈の上では狭さを感じることは無いはずだが、実際に遊んでみるまでは感覚的な差は分からない。


それっぽいゲーム画面が出来てしまうと、あとは特にスクリーンショットを取るような場面は無い。


タイリングでの近似色作成アルゴリズムを少し変えてみた。
RGB ベースでやっていたのを Lab ベースにしてみたらなかなか良い感じに。

実は見えていない部分にもぎっしりキャラクタが詰め込まれている。



ゲームフィールドを構成するマップチップが、すべて同じ VRAM 上にあるデータだけでまかなえるようになっている。
これはいかにも PC88 的な常套手段で、VRAM 同士の転送が高速なのと、テキスト画面をグラフィック画面の上にかぶせて表示できる仕組みを利用している。
テキストの■を黒で描画してマスクし、隠れた領域から VRAM to VRAM の高速転送を実行するという寸法である。

マスクがどうなっているかというと以下の通り。
まだ若干スキマが見えるが、うまく活用するのは結構難しい。



これが可能なのは、1 面につき最大でもベースパネルの色が 3 種類までということが分かっているからで、
ゲームの仕様に沿った高速化といえる。

わかりやすくするために、ベースパネルのみを詰め込んだ最適化前の状態が以下。
実際には星のマップチップもバッファリングされている。



VRAM の余白を連続して確保できるアドレスはスクリプトで求めた。
昔なら方眼紙とにらめっこしていただろう。

VA 系の機種は CRTC の互換性に問題があるらしく、もしかしたらうまく動かないかもしれない。
まあ VA 持ってたら VA ネイティブで作った方がいいよね。
88 の上位機種ではあるけれど性能や制限など実際のところはよく知らない。


テキストのアトリビュートには「ブリンク(点滅）」があるので、これをマスクと併用することで VRAM に触ること無くグラフィックの点滅ができる。
しかし、マスクで「リバース(反転）」を部分的に使っているのでブリンクとは同時に使えない箇所がある。
CRTC を弄って文字のサイズを変更出来れば何とかなったかもしれないのだが･･･。

ブリンクが使えないので、たとえば HIGH SCORE の文字列が一定時間点滅するフィーチャーはテキストマスク「■」の ON/OFF で実現している。

パーツを取ったときにアイコンと数字が点滅するが、ここはテキストの操作がややこしくなるので素直にアイコンを描画しなおしている。
本当はここをこそ何とかしたかった。
2つ以上連続して取るとアイコンが同時に点滅したりするので適切な設定が難しいのである。


ベースパネルの状態を知るための処理を線形探索から二分木探索に変えた。

仮想マップにベースパネルの状態や宇宙空間を表す値を書き込んでおいて判定するのが普通なのだろうけれど、
メモリと速度が犠牲になる･･･ような気がしたので、マップチップの参照元のアドレスから判定している。
NES でいうところのネームテーブルに相当する部分を省略したつもり。

1KB と付随する追加処理を省略できた･･･はずなんだけど色々ひっかかるなぁ。

このシステムだんだん応用が効かなくなっていくな･･･。


フォントを一文字つくり漏らしているのに今になって気づく。
「→」はデモ画面のパーツ選択説明で使われている。というかそこだけ。。。
文字フォントはタイルチップでなくスプライトで持っているものが一部あるので、うっかり見過ごしてしまったようだ。


テキストアトリビュートをうまいことやりくりするルーチンを作る。

テキストマスクは一枚絵のような感じで、使う場面が決まっているので直接テキストVRAM に書いていたんだけど、
属性の適用順を考慮しないといけなかったりいろいろ面倒くさいので、よきに計らってくれるヘルパールーチンをひねり出した。

PC88 が本来横画面であることは避けられないので、縦一列に適用したい場合などは何かと面倒なのだ。

PC80/88 系はテキストに色を付けるだけでも結構大変で、回数制限があったり変な仕様があったりで、なかなか厳しい。
ネット上には資料もあまりなさそうなので何らかの解説があったほうがいいのかもしれない。

とりあえず、テキスト DMA を弄るときは vblank を待たないとまずかった気がする。無視されるだけならまだいいんだけど。


Windows 10 を Windows 7 に戻した。
不定期にフリーズして電源を切るしかなくなるので調べたところ、どうやらファンの速度が上がらないための熱暴走のようだった。
ACPI まわりの不具合なのだろうか。とても使えたものではない。




ネーム入れの前の、『パレットアニメするベースパネルを背景にタイトルロゴが上にスクロールする演出』をつくる。
作る前からわかってたけど、遅ーーーーーーーーーい。
せっかくドット単位で動くようにしたのに、遅すぎるので 4 ドットずつに変更。それでも遅い。
苦労したのになぁ。
一応、もう少し速くする案もあるにはあるんだけど･･･。

ベースパネルのパレットアニメ（もどき）はしてもしなくても速度に大きな差は無い。

この場面はパレット余っていないのと、他のシーンとの兼ね合いもあるので中間色ベースパネルはやむなし。

スクロールして画面外に完全に消える場面で、下図のようにバッファの幅が足りなくて少しだけ転送先に被ってしまうので特別処理になっている。
スプライトがあればこんな苦労はしなくて済むのだが。



ロゴはもうすこし修正が必要か。


NESASM の 64bit 版があることをついさっき知った。
ちょっとテストしたいときには便利なんだけど、これでゴリゴリ書く気にはなれないなぁ。
無限ループのうまい書き方が分からず、無駄にラベルが増え続けるのだった･･･。疑似命令の解説どこ。

ついでに 6809 のアセンブラ・逆アセンブラは何が定番なんだろうか。
テスト環境でよさそうなのはやはり FM-7?

究極の 8bit という触れ込みだけど、実際の速度がどんなものなのか想像が付かない。
大昔に FM-77 を使ったことはあるけれど、機械語レベルでは全くノータッチだった。
確かに命令が充実しているしアドレッシングは至れり尽くせりだけど、命令多すぎて覚えきれない。LEAx って何の略よ。

符号拡張命令の件は結構です。


dec 命令を毎回 del と書いてしまうのは頭がバグっているからなのか。


ウォッチドッグの存在をすっかり失念してリセットの原因を求めて存在しないバグをずっと探し回ってしまった･･･。
忘れた頃にひっかかる罠である。


知っている人にとっては常識だが、CPU にも裏技や隠しコマンドっぽいものがある。
そしてバグ技もある。


ゲーム中に使うキャラデータの一部は 0x0000-0x7FFF の拡張メモリに置いている。一方 VRAM は 0xC000-0xFE80。
なので「キャラデータを読み込んで VRAM に書き込む処理」はその隙間の 0x8000-0xBFFF の 16KB 空間に置きたい。
でないとバンク切り替えを考慮しなければならず面倒になる。

ということで 16KB を描画処理にめいっぱい使いたいのだが、
その他の割り込み関係やスタックエリアなど諸々つめこんでいくと 16KB あってもすぐに尽きてしまう。

描画処理の負担という面からも、320x200 あたりが 8bit PC の妥協点ではないかと思う。漢字は表示したいけどね。


BCD 数値で -1 にあたるのが 0x99 だということを今さら知る。
言われてみるとその通りなんだけど、30年前の缶詰を開けたかのような新鮮(?)な豆知識。
またどうでもいい知識が。


80mk2 版のテグザー移植を見る。
このころはメーカーロゴで音声合成は流れないんだったっけ。
重ね合わせは省略したのか元々だったのかオリジナルでの動作をあまり覚えていないが違和感は全くない。
凄くスムーズで遊びやすそうに見える。


P6mk2 の多色環境を生かしたい。



CIEDE2K で頑張ってみたが左で挫折。塗り絵かな??
やはり適切にディザをかけないとどうしようもなさそう。白と灰色のエネルギーが強すぎるのか他が弱いのか･･･。

といっても賢いツールを使っても右みたいな感じなので、うーん。
同じ色が連続する領域だけディザをかける適応型っぽい処理では駄目だろうか。
VRAM 2 枚使いたくなってきた。

肌色（って言っちゃいけないのか）は難しいのう。


あー、R レジスタは本番では使っていない。単に仮組の際に乱数代わりに使っただけ。




タイトルデモ。タイトル〜ランキング表示中に隕石が降ってきてベースパネルに穴が空く演出。
音はまだなので脳内再生で補完。ひゅるるるるるどかーん。

隕石の表示範囲はオリジナルと比べても非常に限定されている。
最後の隕石はヒットせず右下まで抜けるようになっているが、表示範囲外なので音だけ空しく響くことになる。
まぁテキストの ● が飛んでても案外気がつかなさそうだが。

バッファを置く位置がなさそうだが、以下のパズルのようなアクロバット配置でひねり出している。
配置をいじくり倒して上手く収まった時には変な笑いが漏れた。



本当は最下行に CREDIT 0 の表記を入れなければならないが、そこまでの余裕は無く断念。

このデモは一度独立したプログラムとして作ったあと、本編システムに合わせて大幅に書き直した。
その結果、速度は遅くサイズも大きくなってしまった。
本編との兼ね合いで、あちらを立てればこちらが立たずという感じ。

タイトル画面はゲームの顔なので何とかしたかったのだが、いまさら別のプログラムとするわけにもいかないのが苦しいところ。
音源ドライバが動いていない現時点でも遅いので、どのみち多少は手を加えなければならないだろう。



ノーミスオールクリア＋理論値最大(?)スコア 2,653,800pts
落ち着いたプレイで上手い。

このゲーム難易度高くて、ノーミスでなくともクリアは至難の業だと思う。
初登場の敵が出てくる面がよりによって妙に難しい。
練習しようにもコンティニューも面セレもないし、隕石降ってくるのもやたらと早いし。
開幕パターンの知識だけでなく、パターンをしくじったときにはアドリブ力も要求される。

連射あるとかなり楽なんだけど別の意味でゲームにならなくなるのも悩ましい。
なおビーコンは敵。圧倒的に敵。


Wikipedia に『斜め移動する際に、実はジグザグの移動を繰り返していて直線的に動いてはいない』とあるが、これはちょっと意味不明。

複雑な物理演算がゲームの核なのに、こんな雑な処理をするだろうかと筆者なら思う。
普通に斜め 45 度方向には地続きなので、x,y が共に繰り上がればパネルを渡ってしまう。
逆に x,y が共に繰り上がった結果、宇宙空間に飛び出してしまい敵が自滅することもよくある。

落下するかどうかは 4 点をサンプリングして 3 点以上が宇宙空間ならば落下と判定される。
たまに大きなキャラのメガ・ギガが端っこぎりぎりでひっかかってプルプル震えているのもこのあたりに原因がある。
落下はしていないが行き場所も無い、という状態。


Wikipedia に『ビーコン落下中にナビコンを破壊するとバグる』という記述がある。
確認したことはないが十分に起こりうると思う。

当該の処理に限らず様々な場面で、空いているワークメモリを探してそこにキャラクタをアサインするという処理を行っているが、
『空いている場所がなかったら』という想定をしていない箇所がいくつかあって、その場合無関係な場所にアサインしてしまうことになる。
結果、処理がおかしくなってリセットに至ることになる。


敵がパーツを弾くと宇宙空間に放り出されて落下してしまうことがある。
通常はパーツ全回収を目指すため、プレイヤーが目にする機会はあまりないのだが、
ジャンプパーツが落下したときの最初のパターンが、バグでタイトルロゴの一部になってしまっている。

貴重なジャンプパーツを落下させないと見ることができないうえに一瞬なのでコマ送りでもしないと確認できない。


難易度設定は Rank A と B があって、これは自機の基礎重量の違いである。
その差は 16 で、パワーパーツ 1 つが 12 なので、各面 1 個以上のハンデを背負って戦わなくてはならない。

この差はピューパなどの「押して落とす」タイプの雑魚敵に地味に効いてくる。


9 面は初心者の壁。
ここでパワーパーツごり押しから卒業できるかが、この後の面の攻略を左右する。

初登場のメガ 2 匹にナビコン 3 つというのもエグいが、さりげなく隕石落下タイマーテーブルもこの面で更新されている。
そろそろ死んでくれという意図を感じる。グロブダーの方がもっと遊ばせてくれるような。。。


青ピューパと赤ピューパは単なる色違いだが、黒ピューパは少しだけ性能が違う。

似たようなキャラでもギガに向きはあるが、メガには向きは無い。

同じ円形キャラでもポーラに向きはあるが、ビートルに向きは無い。


敵キャラは当たった相手と当たった回数をある程度覚えていて、それによって行動を変えてくる。
なので、がむしゃらに頭突きを繰り返すよりも、「ここで落とす」と決めた場所に誘導するまでは逃げ回って、一発で落とすようにすると案外うまくいく。


基板改造とな。
メモリ足りないのは内蔵デバッガの残骸を潰せば何とか。
RAM も多くはないけれど、そこそこ空きがあったような。
難しいのは超同意。コンティニュー無いのは鬼だと思う。


スプライトシステムを当初の案通り書いているが遅々として進まず。
重いのが分かりきってるから気が進まないんだよなぁ･･･。
コメントの「てにをは」を直すだけで終わったりしている。

スプライトシステムは事前に脳内シミュレーションをいろいろやってみて･･･

Ａ）ちらつきはあるが比較的シンプルな実装案
Ｂ）多少ちらつきが軽減されるが、さらに重くなる実装案

の二つがあって、今のところＡを採用している。
これに加え、重ね合わせが破綻してでも高速に描画する案(P6で使った)とか
偶数・奇数番号のスプライトを交互に描画してみる案だとかを考えてみたのだけれど、
脳内審議がいつまでたっても終わらないのでシンプルなものでいくことにした。

vblank はちらつき対策としては気休めにもならないと思うので描画処理に関わる形では見ていない。

ALU が絡んだとき演算と書き込みタイミングはどうなるのだろう。

そういえばアルフォスは vblank 待ってるんだったかな。それであの動きと速度はさすが。


思いつくことを全てやったとしてもハードウェアスプライトには全くかなわないのであった。
一周回って描画が遅いことが味になるくらいの差。


スプライトシステムを駆動。
意外と 案の定バグがあった。細かいミスだけで済んだのは幸い。



まだ敵の処理は動いていないので、単にフィールドに表示されただけの状態。
一応、目標地点に向く処理だけは走っている。

ラウンド開始時に、その面に必要な敵キャラデータ（常駐しているもの以外）をディスクから読み込む。
このスクリーンショットを撮った 57 面は、小型の敵が 4 種類登場する唯一の面である（厳密にはパーツ選択デモ時の赤ピューパで +1）。
メモリのやりくりは、すべてこの面に合わせて設計してある。
つまり 4 種類が最大で、あと 1 種類も増やすことはできない。

マップチップの置き場所と同様、メモリの制限があるので自由にマップを作ったり敵を配置したりするのは容易ではない。

一応、当時 I/O データ製の PC88 用拡張メモリボードが発売されていて、1枚につき 1MB or 2MB 使えたはずなので、
それがあれば別なやり方が出来たと思う。4 枚差しで合計 8MB あると相当な贅沢ができるはず。キャラデータ+描画処理をセットで置くとか。

落下キャラの最後のコマは他のキャラのものの流用になっていたりして、キャラ単位でデータセットを作っていたりすると詰む。というか詰んだ。

ところでビートルは黄色の十字ラインがキュートでかっこいいなぁ。
凄い勢いで床掃除してくれそう。


壊せないナビコンは出来れば背景扱いにしたい。
ただでさえ大きいスプライトなのに普段は動かないので、書き換え頻度も減らせるはずなんだけど
プライオリティが特殊なのと足下のベースパネルを壊せるのが問題をややこしくしている。

描画負担を減らせるアイデアはあるんだけど、苦労に見合うだけの効果が出るかどうか疑問。


VRAM プレーンは R,G,B の 3 つに分かれていてバンク構造になっている。現在どのプレーンを選択しているかは I/O ポート $5C で読み込める。
選択状態は RGB に対応した bit 0,1,2 のいずれかが 1 になる。

割り込みなどで作業を中断して復帰するとき、この選択状態を見て VRAM バンクを元の状態に戻したい。
元に戻すのは同じく RGB に対応する I/O ポート $5C,$5D,$5E のいずれかに何でもいいので値を書き込めば良い。

問題はつまり復帰時の選択のために 0,1,2 が欲しいのに、取得できる選択状態が 1,2,4（bit 0,1,2 のいずれかが 1）ということである。
これを条件分岐を使わずになんとかしたい。

	cp	3
	adc	a,$5C-2		
	ld	c,a
	out	(c),a
	ret

小さい方の数値にキャリーフラグを付けると上手い具合に 2,3,4 の並びになる。
実際は ポート $5C の読み込みは未使用ビットが立った状態 -8,-7,-6,-4 で返るので、もう一手間必要。


あぁぁ、キャラクタの影の付け方を間違えていたことに今更気づく。
適当に 90 度回転させて作ってたけど、本当は左右反転＋上下反転でないとダメなんだった。
あまりに低レベルなミス。

ドット打ち直し → コンバートし直し → ディスクへ書き込み直しの 3 連コンボを食らってしまった。


Wii のミュージアムにキャラクタをパックマンにアレンジしたものが入っているようだ。PSP 版の再アレンジかな?
体当たりで体力を減らす、というのがコンセプトを大きく変えた部分だと思う。


スプライトシステムを大きいサイズのキャラクタ用に拡張する。
ゲーム中に必要なものはジャンプ中の自機、メガ、ギガ、ナビコン。


パーツ選択。
オリジナルは画面とキャラクタが青くなって選択を促す演出が入るがパレットが余っていない PC88 版では当面このまま。
テキストマスクを高速に点滅させると暗く見えたりしないか？とやってみたがお粗末な結果だったのでボツ。



ゲームオーバーの文字はデモ中に点滅させなくてはならないが未実装。これ、プライオリティがなぁ･･･。
レバーとボタンの絵と説明はパーツ選択が終わったら、フィールドを復帰させなければならないが未実装。

あと、よく分からないがスプライトシステムがバグってそうな挙動をしている。
問題が山積みで憂鬱だ。


キャラクタの描画は、あるメモリから VRAM の所定の座標アドレスへ順次転送する処理に相当する。
この「順次転送」は通常 16bit インクリメントを伴う（VRAM は $C000-$FE7F の 16000byte のメモリ空間）。

しかし、16bit インクリメントが必要なのは、下位から上位へ繰り上がりをする場合のみである。
（たとえば $C0FF -> $C100 になる場合など）
これは 256 回につき 1 回の繰り上がりのためだけに 16bit インクリメントを必要とするということで、わりと無駄である。

VRAM 上で繰り上がりが発生するアドレス ($xxFF) を実際の画面上で示すと以下の通り。



上図の通り、特定の x 座標にキャラクタがひっかからない場合、繰り上がりが発生しないので、
その場合は 16bit インクリメントでなく 8bit インクリメントでよいことになる。
ゲームフィールドと合わせて見ると、5箇所のうち両端は無視できるので 3 箇所だけ見れば良いことが分かる。

16bit インクリメントは 6 クロック、8bit インクリメントは 4 クロック である。差はわずか 2 クロック。
しかし転送量が多いので、1キャラ分では 1152 クロック対 768 クロックと差が広がる。
キャラクタの数が増えると、その差はさらに効いてくる。

また、件の座標にひっかかっていたとしても、多少のやりくりで 16bit インクリメントだけを使う場合よりも若干高速化できる。
ただし相当うまくやらないと効果が上がらないどころか、処理を振り分ける段階で稼いだクロック数を使い切ってしまう。

様々な状況に応じて場合分けをしてループは全展開して･･･という風にやっているとメモリが幾らあっても足りないので、あまり思い切った実装はできなかった。
本当は テキストウインドウや LD-PUSH 方式とか試してみたかったんだけど、変則解像度とドット単位描画がネックで実現出来なかった。




起動時には環境診断を行って起動要件を満たしていない所を警告する。
こういうものは一度作っておけば使い回しできて便利だが、作るのにはずいぶん手間が掛かった。
問題は各機種・周辺機器についてろくにテストできていないこと。こればかりは地道に検証するしかない。

他にチェックできそうな項目としては、

8MHz-H と 8MHz-S の判別は、vblank 中に CPU をどれだけ回せるかを計測して行っている。
24KHz/15KHz、20行/25行、メモリウェイト有無によっても変わるが、24KHz/15KHz の区別しか見ていないので不完全。
実機で一通り確かめないとどうしようもない。というか 1/600 秒タイマとかで計測すれば済む話なんだけど。

V1/V2 をチェックしているのに V1 だったときは画面がぐちゃぐちゃになるのもどうにかしたい。

今回は一応 8MHz-H が推奨要件ではあるが、4MHz でもチェックは抜けるようにしてある。絶望しかない･･･

細かく機種を判別して何かメリットがあるのかと問われると、『自分のマシンが特定されて嬉しい』以外に実は何も思いつかない。

このチェック画面だけ横向きなのは違和感あるかも。


ワンダーモモ Typhoon Booster なんてのがあったのか。
しかも音楽が virt じゃないか。


結構気をつけて書いているつもりなんだけどうっかりミスは出るなぁ。




PCS-8007（ルンルンシンセ）が鳴った。どうやら 3.58MHz(1.785MHz) 基準らしい。あんまりルンルンじゃないぞ。

ついでに 12ch シンセユニットも鳴った･･･こっちは 4MHz(2MHz) らしい。
ということは 8MHz では使えない可能性が高い。うーむ。

レジスタの読み込みが出来ない(?)のも中々つらい。


PC88 のオプションの一つにサウンドボードII というものがあって、文字通りサウンド機能の強化、FM 音源を拡張することが出来た。
さらにサンプリング音声の録音再生機能のため 256KB メモリが搭載されていた。

CPU のメモリ空間が 64KB、フロッピーディスク 1枚が 320KB だから破格の大容量である。
88 の新世代機種の売りの一つだったので、青少年は意味も無くオーケストラヒットとか入れてみたり
ゲーム屋はゲーム屋で麻○優子のポエム朗読を入れたりしたものである。あー恥ずかしい。

で、本来は音声の録音再生用のメモリなのだが、本体 CPU 側から多少の不便はあるものの自由に読み書き出来たので
音声以外のデータを入れて使うこともあった。RAM ディスクとか。
なにしろ 256KB である。デカい。

今回はキャラクタデータなどの一部を、この 256KB メモリに配置している。
キャラデータなので、ゲーム本編ではアクセス速度が重要になってくる。

従来 256KB メモリのアクセスでは 1byte ごとに BRDY(Buffer Ready) フラグを見ながら読み書きするという手段が一般的に使われてきた。
筆者もバイブル本の通りの手順をずっと使ってきた。
Y 社のアプリケーションマニュアル(?)や巷の 88 ソフトも大体同じだと思う。
しかし、色々実験していてこの手順の一部が省略できることに気づいた。BRDY フラグを見なくてもいいのである。

具体的にどのくらい簡単になるかというと･･･

loop:
	in	a,($46)
	bit	3,a
	jr	z,loop		← BRDY=1 になるまで待つ

	ld	a,$08
	out	($46),a
	in	a,($47)		← ここで 1byte 読み込み
	ld	(hl),a
	inc	hl

	ld	a,$10
	out	($46),a		← ADPCM レジスタ $10 に $80 を書き込み
	ld	a,$80
	out	($47),a		← フラグコントロール 全てのステータスフラグを0に	
	djnz	loop

これが、

loop:
	in	a,($47)
	ld	(hl),a
	inc	hl
	djnz	loop

これだけで済むのである。フラグコントロールを弄る必要が無いので ADPCM のレジスタは $08 でループ前に固定できる。
なんだったら、c = $47 にしておいて、

loop:
	ini		
	jp	nz,loop

これが通ってしまう。
この方法の利点は、まずレジスタが恐ろしくフリーになることである。最小では a レジスタだけで転送できる。
余ったレジスタは転送先アドレスの加減算やループ制御に使える。

INI を使うと bc レジスタは潰れるが 1 命令で済み、かつ LDI と違って de レジスタはフリーである。
ADPCM にリセットを発行しない限り読み出し位置は維持されるので bc レジスタすら途中で弄ってもかまわない。

さらに、場合によってはメイン側の RAM to RAM よりも速い。これが第二の利点。
LDI 転送は速度は同等だが、de は潰れるし bc のデクリメントが使いづらい。
POP-LD 転送は割り込み禁止が必要になる（もっとも、FM4-6 を使って BGM 演奏するならこの方法も割り込み禁止必須）。

もうひとつ、c を介した読み込みでは一部のフラグレジスタが変化するので、
Z80 垂涎の(?) ロードから無手順でのコンディション分岐が可能。これは今回の高速読込に限ったことでは無いが。

なにより巨大なデータをメインメモリ空間を維持したまま転送できるのは大きい。

この方法は読み込みだけでなく、書き込みでも使える。
エミュレータでは、そもそも BRDY などのフラグをスルーしているものが多いようだ。

難点は、読み書きの前準備が必要なこと。これは大きなデータであればあるほど前述の通り速度差で隠蔽できる。
つぎに 256KB メモリの仕様として、途中からの読み書きが難しいこと。なのでランダムアクセスには向かない。
また、アクセス中は音源の FM4-6 チャンネルおよびリズム音源へのアクセスが出来なくなる。

本件はこの方法で大きなサイズのキャラクタやロゴデータなどの大容量データを高速に読み出している。


サウンドボードII の ADPCM メモリへの読み書き高速化は当然ながら ADPCM データをセットする際にも有効である。

試しに PMD88 ver.3.9 の ADPCM データロードを高速化してみた･･･が 1 秒前後しか速くならなかった。
ディスクからの物理的なロードにかかる時間の方が圧倒的に多いので明白な差は出ないのかもしれない。
おそらく ADPCM データに圧縮を掛けたほうが効果は高いだろう。

一応 Music LALF も改造してみたが、こちらも 3 秒程度の高速化。

というか、なぜ揃いも揃って x1 モードなんだ。


LALF は SB2 判定ときどき失敗しそうなんだけど大丈夫なのだろうか。

ADPCM も今なら量子化誤差を織り込んだ変換をすれば少しは高音質化できそうな気がする。
今ならって言うほどでもないか。

ふと思い出したが PMD や LALF の初代 PC88 対応を一緒にやっておけばよかった。
初代 PC88 + PC-8801-11 という構成で遊んでいた時期があったので思い入れがあるのだった。
でもしばらく BASIC には触りたくない。


メモリ必要量がおおよそ分かってきたので、そろそろ最適化っぽいことを考えたい。
しかし RST 命令に配置できそうなものが意外と無い。乱数と割り算くらいか。いまひとつ効果が薄いような。

音関係は全く着手していない。
誰かやってくれーと無責任に言い放ちたいが、そういうわけにもいかない。

プログラムと音楽はペースが違うので妙に足踏みしている感覚になるんだよなぁ。
毎度のことながら音楽をやる頃には力尽きているというのもある。つらい。


今回の目標の一つに多種多様な拡張音源に対応してみるというものがある。
PC88 は純正のオプションでサウンドボードがいくつか出ているのと、サードパーティの製品も数種類存在する。
その他、雑誌で発表された同人ハード的なものなどを含めると結構数が多い。
もっとも、他機種にも個人制作の拡張音源は色々あった。それだけ当時のユーザーの音楽に対するニーズは高かったということなのだろう。

とりあえず、j80 が拡張音源周りで一番マニアックな実装をしていると思われるので列挙してみる。
アップグレード的なものは除く(PC-8801-23, PC-8801-24)。
  1. 前期標準 YM-2203 (FM PSG)

  2. 後期標準 YM-2608 (FM PSG RHYTHM ADPCM)

  3. PC-8801-10 AY-8910 (PSG) ミュージックインターフェースボード。MIDI の制御が出来た。割り込み源はどうだったか･･･。

  4. PCG-8100/8800/8200 i8253 PCG 機能にサウンドがおまけで載っている。ほぼビープ音。

  5. GSX-8800 AY-8910 (PSGx2) 2枚刺し可能。8801-10 互換?

  6. ADCOM サウンドユニット SN76496 (PSGx2) 。

  7. PCS-8081 AY-8910 (PSG) 4枚刺し可能。

  8. PCS-8007 AY-8910 (PSGx2) 2枚刺し可能。

  9. HMB-20"響" YM-2151 (FM)

  10. PSG による自動演奏[I/O 81.12] AY-8912 (PSG) Z80CTC 付き(?)

  11. FAD-06 12ch シンセユニット[Oh!PC 82.8] AY-8910 (PSGx4)

  12. PPI+1bit PCM (PCM)

  13. ミュージックアダプタ SN76489 (PSG) プリンタポート接続。

  14. JAST SOUND (PCM) FM 音源搭載のバリエーションがある(?)。
さすがに全対応は難しいので、音源チップの種別毎に対応してみようと思う。
I/O ポートの出口だけ弄ればいろいろと応用は利くだろう。8255 接続の PSG なども多少手を加えれば。
今回対応しないものについても、制御方法のチュートリアル的なものは書いてみたい。


今回は関係ないが、実機での『全部載せ』は PC98 に次いで豪華なのではなかろうか。PSG 特盛りすると全機種で一番かも。
I/O ポートの被りが少ないのもポイント高い。


某ZINE が "Atari 2600 games" を「アタリの 2600 本のゲーム」と訳していた。ショック!


オリジナルの 15XX は 4bit * 32step 波形メモリ 8 声。ノイズはたぶん付いていない。
音程周波数は 20bit もあって音階間は上が広く下が狭い。狭いと言っても 20bit の中での話なので一番狭い音階でも相当な余裕がある。
ただし波形メモリ音源なので 20bit 分の音程がそのまま鳴るというわけではない。

このあたりは FPGA (?)で鳴らせるようにした方がおられて、その解析記事がずいぶん参考になった。URL 失念。
音色は SCC などとは違い、ハード側で切り替え。固定で 8 個だが、タイトルにもよるのかもしれない。

固定だとすると、Get Ready! とか Blast Off! なんかは波形としてサンプルを持っているのではなく、0xFF と 0x00 の切り替えで
出力していたのだろうか。機会があれば調べてみたい。

ところでオリジナルの曲データのバグっぽいのを見つけてしまった･･･。


OPM ドライバを作る。
PC88 なら OPN/OPNA というところだが、HAL 研究所から出た HMB-20 響 という拡張サウンドボードがあって、これに YM2151(OPM) が載っている。

音源ドライバは自作のひな形があるので、それを改造すればわりと楽にできてしまうのだが、
今回は少し変わった構成にしたかったので合計 3 回もドライバをつくることになってしまった。

1) 普通の OPM ドライバをつくる
2) 不要な機能を削除して必要な機能を追加したカスタム版ドライバをつくる
3) FDD サブシステム側とメイン側に分離した本番仕様ドライバをつくる

例の 3.58MHz <-> 4MHz 問題や KC の歯抜けのことを失念してすんなりとは鳴らなかったが、他は大した問題もなし。
音色はビルトイン固定でエフェクトはエンベロープくらいしか無いが、8ch 分のワークもあるのでサイズは大きい。

雑な作りだが鳴っているので良し、と思っていたらバグがぽろぽろと･･･。

FM 音源は音量の扱いがどうにも難しい。正弦波だけでも波形メモリ音源とFM 音源では違って聞こえる。
音量変化を直線的にとるにはアルゴリズム 4,5,7 あたりで工夫すべきなのだろうか。よくわからない。
X68k の DIGDUG/2 はホントよく出来てると思う。

あ、NRTDRV88 は暇が出来たら更新します。ﾊｲ｡


OPNA ドライバを作る。
長らく放置していた PC88 用の自作ドライバがあるので、それをカスタマイズするだけ。
リズム音源のポンコツっぷりに業を煮やしてお蔵入りにした覚えがある。

データとしては 8 声から 6 声に減少。PSG や FM 側 Ch.3 の効果音モードによるチャンネル補完は併用しない。
SE の鳴るチャンネルがバラバラであるため、特定のチャンネルを PSG や効果音モードでまかなうのは難しいと判断した。

本編で ADPCM メモリを凄い勢いで叩きまくるので、I/O ポートを共有する FM4-6 は割込禁止の隙間を縫って恐る恐るのアクセスである。
いっそ FM4-6 側を使わないことも考えたが、SB2 搭載機で OPN 相当というのは今回の趣旨にも反するので実装してみた。SB2 火吹きそう。
一応 OPN/A 系ボードの複数刺しもチェッカで判別するので 8 声対応はできなくはない。

結局 FM 音源の音色は 8 種類にした。してしまった。
音程によって音色がダイナミックに変化するのは FM 音源のいいところでもあるけれど今回のような用途には向かないのかも（半可通）。
あとからでも増やせる構成にはしてあるが、似なさすぎて正直もう疲れた。
8 声のときにはまだ目立たなかったが 6 声になると似てなさが際立つ。

OPNA で拡張された定位指定は特に指定しなくてもデフォルトでステレオになっている。
互換性を考えると当たり前の仕様だが、改めて書き込む必要が無いのは少し手間が減ってありがたい。
初期化をサボるのは単なる手抜きだけど。

こういうのはまだ分かるが、

こんなのは！？＃％＄＆である。


音楽をやっている間、本編はしばらく虫干し。

「ここを変えるとあそこも変えねば」みたいなのが億劫になってくるとよくない兆候である。
こういうときは全然別なことをするに限る。


HAL 研製 GSX-8800 と 純正 PC-8801-10。後者は現物を使ったことはあるが何に使っていたかは忘れた。
対応ソフトはハドソンや dB-SOFT あたりから出ていたはず。いまひとつ印象は薄い。らぷてっく？

2 つ載っている PSG は、出力がミキシングされず別々のようだ。
そのままでは BGM 演奏として使い勝手が悪いので、適当に外部でミキシングすることが前提となる。

ついでに、本体側 OPN(A) の PSG も同時に使うことで PSGx3 構成で鳴らすことにした。
PSG 系は 2 枚刺しや 4 枚刺しが可能なボードが多いのだが、現物で動作確認しようにも単品ですらレアなのに複数はなおさらということで
基本的に拡張ボード 1 枚 + αという構成をとりたい。本体側 PSG を使うことで複数刺しが実現できた場合にどのような音になるか理解しやすい。はず。

FM 音源のってるのにわざわざ PSG というのもなんだけれど、意外と PSG 多チップ構成のものは聴く機会がないと思う。

PSG も音量が極端なところがあるので、エンベロープの後に一段テーブルを挟んでいる。
そのままの音量テーブルで鳴らすと凄くハネた曲になってある意味楽しくはある。ただし耳に刺さって痛い。

制作には hoot を利用しているが、PC-8801-10 の構成時には YM-2203 や YM-2608 は載らないので PSG が足りない。
他のアーケードドライバに偽装できないか見たところ、意外と PSGx3 以上のドライバはあるようだ。へぇ〜。
ま、さすがに一番多いのはジャイラスだったけど。PSG x 5 !!
結局メモリマップド I/O や CPU クロックが違ったり、そもそも CPU が違ったりすると無理なので PC88 エミュレータ上で調整することにした。

一通り作ってから、実はこの拡張ボードが本体クロック 4MHz 専用という話をちらっと目にしたのだが後の祭り。


ADDCOM サウンドユニット。SN76489Nx2 を積んでいるらしい。

初代 PC-8001/mk2/88 用があるらしいが、後期 88 で使えるのか全く不明。とりあえず見切り発車で実装する。
6 声だと足りないので、同じ SN76489 の ASCII 誌掲載 ミュージックアダプタも併用する。こっちはプリンタポート接続。
SN76489 は DCSG と通称されるもので、いわゆる「セガっぽい」音が出る。ワンダーボーイモンスターランドとか好き。

以前弄ったことがあるので制御方法自体は知っていたがドライバを書くのは今回が初めて。
矩形波部の 3 音はすぐに鳴ったもののノイズをどうするのが良いのか思案中。ch.3 と相互に設定できる仕組みが必要か。

そういえば、レジスタへの設定時に bit7-0 を、逆に bit0-7 へと引っ繰り返して書き込まねばならない。
何故こんなことになっているのかよく分からないが、妙に面倒くさい仕様だと思った。ビッグエンディアン原理主義者か。
テーブルつくるまでもないので逐一変換している。

この音源に関しては例によって hoot が使えないので PC88 エミュレータ上でテストした。
曲オブジェクトは AY-8910 と完全に同じで、ドライバ側で差を吸収する仕組み。音量が 0 <-> 15 で逆だったり。
同じ PSG なので出音にそれほど大きな差はないが、分周値の範囲が狭いので低い方では音痴になりやすい。12bit vs 10bit。

YM2608 + SN76489 で、ほぼメガドラサウンドになるので、いろいろ鳴らせると楽しいかもしれない。そうでもないか。

ところで、ミュージックアダプタの方は 3.58MHz 基準になっているのだがこれで合っているのだろうか。
音程テーブルを 2種類持つことになってもやもやする。


HAL 研の PCG-8100/8800/8200。i8253 が載っているらしい。

この拡張ボードは PCG の名の通り、PC-8001 に PCG 拡張機能を提供するもので、ゲーム用途を想定して音源機能も付属させたと思われる。
8253 も 当初は 1ch だけだったのが、後期モデルでは 3ch 出力になったとか。
当時の拡張ボード類は、故･岩田氏が関わられていたとのこと。R.I.P. http://weekly.ascii.jp/elem/000/000/355/355736/

8253 はいわゆる「ピポッ」音(他機種だが)の出所で、単なるタイマーカウンタなので音量の設定などはできない。
ノイズも無く音量も変えられないので色々と残念なのだが、とりあえずこんな音が鳴るらしい。

Theme of Carpet Stories (MP3:音量大きめ)

出音を聴く限りほとんど PSG だが、音量関係の操作が全くできないので休符は超音波でごまかしている。
さすがにゲームの BGM に使うには厳しいので、このドライバは本編では使わないこととした。

ドライバ作成には PC98 関係の資料を漁ったが、MZ 関連での使用例が充実していたことを作った後になって知った。そりゃそうだ。
紅茶羊羹さんの資料 → (http://www.maroon.dti.ne.jp/youkan/mz700/pg/sound.html)

8253 は軽めに触った程度なので、実は怪しいテクニックがあるのかもしれない。
PCM(PWM) 再生なんかも出来るといえば出来るっぽい。PC98 の卒業とかで喋ってたのはコレだったかな。


音関係はこんなところか。
あとは PC88 に SCC が刺さってしまった時のことも想定して一応 8ch 仕様でドライバと曲データは拵えておいた。
80 円で SCC もどきが出来るらしいので、あと 8 円出したら PC88 にも刺さってくれないだろうか。

記事に「ようだ」とか「らしい」が多いのは筆者が実物を所有していないため。
従って出音の確認はエミュレータでしか行っていない。
偉そうに語っているくせに完全なエアプなので間違っていたら指をさして笑った後、教えてください。




余裕の音だ、馬力が違いますよ。
本編とは別に、こういうプログラムを書いて曲と効果音のテストを行う。
音が出っぱなしにならないかとか音量バランス等々、実際の動作にあわせて問題点を拾う。

例によってバグはあったが、せっせと曲データを作るよりよほど楽しい。
曲データ作成は終始ツールとのにらめっこになるので今ひとつ面白くない。

メモリ足りない問題が再燃。曲データもヘッダを削ったりしてダイエットはしているのだが、
音オブジェクトとドライバ合計で 12KB は欲しいところが、10KB しか確保できない。どうしよ。まさかの CD-ROM2 から音楽垂れ流しか。

15KHz / 24KHz でかなり曲の速さに違いがある。これは対処可能だが敢えて残しておこうと思う。
速度が変わる方が、ある意味ただしい動作といえるので。

FM 音源のパラメータも 31-0-0-15-0 的なアレなので、ほぼ固定値で書き換える場合でも手間は最小化できる。
音量も、Op.4 だけ考えればいいはず･･･。しかし後になってもう少しマシなやり方を思いついた時のことを考えて
フルパラメータ版でいくことにする。


その筋では有名な「天使たちの午後」というタイトルがあって、JAST SOUND というモジュールに対応していた。
これはプリンタポートに接続する音源アダプタで、ゲーム中に（天使たちの?）声が聞けるというのが売りだった。

プリンタポート接続ということからも想像がつくが、パラレル 8bit 再生周波数可変（CPUごり押し）PCM というスペックである。
音源というより単なる DAC といった方がいいかもしれない。

エミュレータでも対応しているものはいくつかある模様。
筆者は実物は持っていないが互換ハードを作った方がおられるので、ありがたく参考にしつつ自作した。
当時の広告を見ると高機能版などいくつかバリエーションがあったようだ。

プリンタポートさえあれば PC88 である必要は無いので他機種でもいけるかも。って電圧が違うのかな。

その後、サウンドボードII などが出て PCM 音源のありがたみもすっかり薄くなったのだが、
実際、天午後の音声を実機で聞いたという人も少ないのではないかと思う。

というわけで、パッチを当てて SB2 の PCM で音声が鳴るようにしてみた。
tengogo_pcm_patch.zip
D88 イメージを patch.bat にドラッグ＆ドロップすると DOS 窓が開いてパッチを当てる。問答無用で上書きするのでバックアップを忘れずに。
たぶん初期の方のバージョンには対応していない。つくりが雑なパッチなので音質は悪い。メモリの空きが十分あれば PSG 版や BEEP 版もつくれそう。

今の時代に聞いてもがっかりすらしない。コーン紙が震えるのを虚無のまなざしで目撃して欲しい。

http://erogereport.blog.jp/search_tags?qt=265338
こちら(18禁)によると、対応タイトルは他にもいくつかある模様。


というか、なんの話だっけ･･･。


結局 10,496byte に収めないといけないのに 10,608byte になっってしまった。112byte 足りない。ふえぇ。
幼児退行してみても解決しないので他のプログラムの使用頻度の低い部分を削って押し込むことにした。

コンパイルしてみたらサイズが 514 byte → あと 2byte でぴったり！みたいなのが下手すると本編より楽しいから困る。

とりあえず削りまくって 512byte 確保に成功。上の方で DOS のカスタマイズに苦労、みたいな話はまったくの無駄になった。
追加した機能ごっそり削除。はぁ〜〜。


PC88 は Z80 CPU を 2 個積んでいて、2 個目はディスクシステム制御に使われている。
ディスクアクセスしていないときは、ずーっと待ち受けループになっているので、
自前のプログラムを走らせてやれば計算資源やメモリの足しになる。

これを活用した市販ゲームもあるにはあるのだが、性能 2 倍なんてことはなくて、
CPU 間の通信がボトルネックすぎて、よほどの並列化をしない限り CPU 1 つで計算した方がマシという結果になりがち。
速度を度外視すれば別だけど。

2 つの Z80 間には共有メモリのような便利なものは無いので 8255 を介したやりとりとなる。糸電話というか文通レベル。
CPU そのものは高速でも通信はスローで間接的、なおかつお互いの情報をやりとりするにはプロトコルを決めるところから始めなければならない。
ROM 内によく使う便利なコマンド類が載っているので、それを使えば一応ラクは出来るのだが、独自の処理をしようとすると自分でなんとかするしかない。

今回、ディスクシステム側では音源ドライバが動いている。
vblank 毎に BGM と SE のリクエストがあれば本体側から送信し、受信時には音源に送り込むデータをストリーミングしてもらう。
前述の通り、通信がボトルネックなのでメリットはそう多くないのだが、一応なんとかなっている。

BGM と SE が 合計 16 トラックだとすると、vblank が来てからメイン CPU で音楽の処理をするのでは馬鹿にならない時間がかかる。
そこを本体側がゲーム処理で忙しい時に平行して作業できれば、通信がボトルネックでも収支を考えると多少速度は稼げる･･･ﾄｲｲﾅ? という目論見が半分。

あとの半分は、単にやってみたかったから。勢いって怖い。

結果論だけど、ディスク側で音源ドライバはやめたほうがいいと思った。
理由はメモリがきつい、デバッグが大変、既存のドライバと構造がかなり違うので予想外のことが多く、色々と面倒だった。

当然ながらディスクドライブとしても使うので、必要なときは DOS と制御を切り替えることになる。
メモリが足りなくて一部ワークエリアがかぶっている。


そもそも本体側にフルセットの音源ドライバ入れる隙間は無いのだった。

隕石の SE は「ぴー」と飛来して通過するときに「ひゅるる」となるが、この二つは実は同じ SE である。
後者の冒頭部分が前者であり、リクエストされた SE が毎フレーム頭から連打されるので「ぴー」に聞こえるのだ。
X68k 版の動画を見ると、タイトルデモでのこの SE はかなり濁って聞こえる。
これはおそらく FM 音源の音色定義やキーオン・キーオフを毎回行うので濁って聞こえるのだと思う。

この問題は単純に「ぴー」と「ひゅるる」の 2 つに分けて再生すれば良いというものではない。
同チャンネルで鳴るベースパネルへのヒット SE が絡んでくるので SE 同士のプライオリティが絡む、ちょっと複雑な問題なのだ。
推測だが X68k 版でも既知の問題で、うまい解決策が見つからなかったのではないだろうか。PC88 版ではちょっとズルい方法で解決している。

タイトルデモの遅さは見る度に憂鬱になるレベルなので、こういう小さいところでポイントを稼いでおかないと惨めな気持ちになる。


『サウンドボードII の 256KB メモリを全て使い切った』
トロフィーを獲得しました。


エミュレータでテストプレイ。

分かっていたことだが、ちらつきが酷い。そして遅い。ナビコン面はストレス溜まりまくり。
あと、画面の縦横比にやはり違和感がある。縦横方向での見た目と実際の移動量の違いが少し気持ち悪い。
縦横比の関係でジャンプのときの「踏み切り」の感覚が違う。

それにしても、ざっと遊んだだけでゴロゴロとバグが出てきてしまった。
すぐに直せそうなものから調査が必要なものまで。
一番きついのが、直したはずのものが何故か再発しているという･･･。

実機では、いわゆる ATARI仕様(P6仕様) のジョイスティックを持っていないのでテンキーしか使えず、あまりテストにならない。
変換キットのようなものが無いかググってみたのだがどうやら無さそう。逆はあるんだけど、欲しいのは USB to ATARI なんだよなぁ。
Bit Trade One とかにありそうなものだが。

なんか動作が変だぞ → オリジナルを見る → オリジナルもこうだった、みたいなコンボ祭り。思い込みは怖い。

いまのところ PC にセカンドモニタをつないで縦置きでプレイしている。持ってて良かった Century。
だけど、CRT でリアル PC88 の画面をみることはもうないのだろうな･･･。


またアトリエの新作が出るのか･･･このプロジェクト始めてから何度目だ。
というかロロナが終わってないんですけどー。


ALIGN で揃えると無駄が出るが、テーブルを 256byte 境界内に収めたいという場合があって、以下のように書いている。

 while	(($ + 9) >> 8) <> ($ >> 8)          
    nop
 endm
    db  0,1,2,3,4,5,6,7,8,9

すべては Z80 に 16bit+8bit が無いのがいけないのだ。


SE は同じ論理フレームに複数のリクエストが発生することがあるので、キューに格納するようにしている。重複するリクエストは破棄。
vblank 毎に一つずつ取り出してサブ CPU に送っていたのだけれど、間に合っているのか心配。いや、間に合ってはいないんだけど。
SE がずれるのも問題だがキューのオーバーフローの方がよほど心配。

用心のためにキューを毎回全部吐き出す方法も書いて、そっちも上手い具合に動いている。
ただし、こっちは見るからに重い。なるべく通信回数減らしたいのに。

これとは別にメイン CPU とサブ CPU の通信時のステート数を合わせることでハンドシェイクのロスを減らす案を思いついた。
片方は受信しつつ音源に書き込んでいるので、ズレが生じないように反対側もダミーの I/O ポートに書き込むようにする、と。
まったく意味なかったらどうしよ。ウェイトとか違ったりして。

どうやら 4MHz & M1-1 ウェイトっぽい。ダメだー。


海外移植版の BGM は妙に耳に残って困る。


Amstrad CPC 版 Z80 @ 4MHz でそこそこの動き。
P6mk2 と色合いが似ていると思ったら 160x200 で 16色なのだそうだ。しんぱしー。
パーツが点滅（パレットアニメ）しているのは中々。それはいいとして落としたら爆発するのか。
ちらつきが無くて嫉妬。


Commodore64 版 6510 @ 1MHz。
なんだか動きが怪しいけど、こっちはちゃんと落下する。
P パーツって "PILL" なの？ まぁ薬っぽい形状だけどさ。
ちらつきが無くて嫉妬。


ZX Spectrum 版 Z80 @ 3.5MHz。256x192 なのかな?
よかった、こっちは "POWER PARTS" だったよ。
キャラ単色ながらベースパネルのパレットアニメは芸が細かい。
ちらつきが無くて嫉妬。

同じ移植担当者がいろいろな機種を手がけているので似たような出来になってしまうのだろう。国内でもよく見た光景。
Amstrad 版は色合いも好みで好感触。このくらいの完成度なら十分に遊べたと思う。
ただ、他に魅力的なキラータイトルがある中でこれらを遊びたいと思うか、という問題もあるから
当時のラインナップを知らないとリアルな評価は難しそうだ。ゼビウスは明らかに酷いのが多かった。

X68k版?
ちらつきが無くて嫉妬。

パーツのパレットアニメは PC88 版でもやれないことは無いんだけどメモリが余ってないんだよな、あと 2KB が。


敵のフラッシュ攻撃、もとい、ちらつきがひどい。

まぁある程度は分かってたことだけど、困ったことにエミュレータによってチラツキ方が違う。
最終的な調整はさすがに実機準拠ということになるだろう。
実機でやっても、つなぐモニタが CRT か液晶かなどで変わってくるのかもしれない。

ま、見る人も老眼だからいいか（いやいや）

一応、スプライトを座標でソートして逆順に描画することで、現状よりちらつき（というかキャラ欠け）は減るはずだが、
そうなるとプライオリティが破綻するので難しい。
マップチップ処理を若干変えたせいで、バッファにためて描画する案も使えなくなったし。
VRAM 2 枚あればなぁ･･･。


既知の開幕パターンはあまり通用しない。原因は乱数絡み。

オリジナルではプレイ中のパネルの色や背景の星の明滅（パレットアニメ）にも乱数が使われている。
PC88 版ではこれらの演出は省略しているので、乱数を引く回数がその分だけ変わってくる（無駄に乱数だけ求めても速度が遅くなる）。
これにより自機・敵の動きに使われる乱数が変わってくる。
デモプレイでも同様の理由により自機および敵の挙動が違う。

乱数は面の開始時に面の数値を加工した値をシードとして初期化している。
これにより一応毎回同じパターンにはなる。ドルアーガの迷路生成で有名なアレ。

パターンが通用しないのを攻略しがいがあると見るか出来損ないと見るか。


P6 にスプライトかー。
巨大戦艦は表示できるのか!?という問題はさておき、スプライトが表示できても背景の表示に時間がかかっては意味がないので、何らかの仕組みは必要になりそう。
そうなるとスクロールは欲しくなるし、スクロールに巻き込まれないようなスコアやステータス欄の表示の仕組みもまた必要になる。
あとは（まともな）パレットかなぁ。


CPU クロックが 0.5MHz も上がれば軒並み解決して、さらにお釣りが返ってくる程度の高速化なのがむなしい。

やらないよりはマシだが、やり過ぎると駄目という問題もある。
Z80 のインデックスレジスタがどうこう、というのは 8MHz だと大した差でもなさそう。


FM 音源の音色定義はメイン側に処理を置いている。サブ CPU 側からは音色番号だけを受信する。
さすがにフルセット 28 パラメータを送るのは気が引けたのと、サブ CPU 側のメモリが足りないため。

これに加えて、同一チャンネルで同じ音色を再定義しないように管理している。ただでさえ FM 音源は待たされるので効率が優先だ。
メイン側での音色管理はちょっと不便なところもあるのだが、サブ側のダイエットに成功した今でも音色を置くスペースは無いので仕方ない。
全てうまくいく解決策はなかなか無いものだ。


256KB ADPCM RAM にロードしたものはリセットしても消えないはずなので
既にロードされているかどうか、起動時にチェックをかければリセットした時にロード時間を短縮できる･･･んだけど
そんなにリセットするようなゲームでもないので毎回律儀にロードする。
エミュレータだと外部メモリでもきっちり揮発してしまうのでテストが面倒という話も。

ゲームソフトとしての体裁の部分は全くの後回しなので、コンフィグ的なものが一切無い。
音源の切り替えにビルドし直しが必要だったり。

いかにも同人っぽいゴテゴテしたものは要らないんだけど最低限の UI は必要か。


こんな格言を知ってる？　バグは常にもうひとつある。



その「1」はどこから出てきたんだよ･･･。ちょっとゲーム機っぽいバグに思わず笑ってしまった。

キャラが豆腐になったり破壊したはずのナビコンが半透明の幽霊になったり、まだまだ不思議な現象が盛りだくさんである。


スプライトにクリッピングを実装。
実は今まで未実装だった。冒頭にも書いた、画面写真を見ただけでは分からないが遊んでみてがっかりする部分の一つ。
キャラが少しでも欠けるようなら描画をキャンセルするようにしていたので、特に画面の端の方で頻繁にキャラが消滅していた。

実装は当初から予定はしていたが、一通り遊べるレベルになってメモリの都合がついたのと、
音源ドライバを駆動して落下 SE を付けてみたところ、今まで画面端で落としたら無言で消えていた敵が落下音と共に急に存在感を発揮しだしたので
やはり是非とも表示しなければ、とモチベーションが上がったのが大きい。

といっても実装は非常ーーーーにややこしく、224 <-> 196 の論理・物理解像度の違いや、単に表示しきれない部分をキャンセルするだけでなく
画面の長辺については、大きなキャラが上下に跨がった形で表示されるなど、複雑な処理が要求される。
なによりドット単位でのクリッピングは PC88 には荷が重い。

で、とりあえず動いてはいるものの処理はやはり重い。そしてサイズも大きい。
これまでは、スプライトのデータはマスク→Ｂ→Ｒ→Ｇを正順・逆順・正順・逆順で格納していたが、クリッピング実装にあたって全て正順にした。
これにより通常の表示でも 1 キャラに付き 30 クロックほど遅くなった。
他で挽回できるといいのだが。


ところで、操作しながらスクリーンショット取るのが非常に大変だ。動画･･･動画･･･



下にジャンプすると上から出てくる。クリッピングの効果は大きく、これだけでもグっとスプライトっぽくなる。

どうも「やっぱり所詮は 88 か･･･」と我に返る部分を極力なくしていくことが、脳内で 88 = スプライトマシンの錯覚を強くするものらしい。
上映中の映画館を暗くするようなものか。

このところ、エミュレータで、通して動かすと止まるがステップ実行をすると止まらないという不具合が出て困っている。
おおよその問題箇所の見当はついているが、こういう「たまたま動いているだけ」のような微妙なバグは実機でも起こりかねないので悩みの種である。

クリッピング実装で、ついに $8000-$BFFF の 16KB が尽きてしまったので優先順位の低いものからバンクメモリへ引っ越し。
単に引っ越しするだけでなく、その部分をアクセスする際にバンク切り替えと復帰を追加しなければならなくなるので、結果として遅くなる。




ぱんだここあ (What is this place?)
P88SR で動いたのは驚き。拡張メモリのエミュレートが異常に遅いのと、ADPCM メモリとの併用ができないので
グラフィックが化けている。機会があれば実機 PC98 でも試したいところ。

エミュレータ P88SR M88 QUASI88 X88000 j80 ePC8801 XM8
動作状況
 △ ○ ○ × SB2未対応で動作不可 ○ ○ ？

M88 は懐が広すぎて雑な処理を書いても大抵のことは通ってしまうので、実機に持って行ったときにびっくりすることがある。
OTIR 命令にバグがあるような気がする。

QUASI88 はテキストアトリビュートに少し違和感がある。具体例あげられないのがアレだけど。
メインのデバッガ。このエミュに限らずステートロードからの復帰でサブ CPU との通信途絶がたまに。

j80 は割と最近まで動いていなかったので要テスト。
テキストアトリビュートは完璧っぽい？

ePC8801 は縦画面に出来るのはいいが、明らかに遅い。

XM8 も遅いが ePC8801 ほどではない。ほとんどテストしていない。

推奨は 8MHz-H の 15KHz。
128KB RAM の代わりにビデオアートボードとかでも動くのかな。

実機+Century のモニタで見ると白飛びしすぎて本来の色が分からないのが残念だ。


今まで曖昧にしていた部分を 1 日半かけてじっくり検証する。
計算自体は間違っていなかったが、全然別なところでやらかしていた。
仮想マップの初期化に漏れがあったのが原因で「画面外」の判定に失敗し、色々おかしな現象がおきていたようだ。

敵同士の衝突は、各敵が自分のインデックスより後の敵との当たり判定を行う。
インデックスが一番うしろの敵も自分よりひとつ後の･･･そこ隕石のワーク･･･
これってオリジナルのバ･･･

論理フレームレートを 30fps にしてみる。アクションゲームとしては 60 出せないのはある意味敗北だが仕方ない。
多少遊びやすくはなったがチラつきが増えた。どうにか可変フレームレートにできないものか･･･。
レバー・ボタンのスキャンは vblank 同期にしておくと、エッヂの取りこぼしが頻発するのでゲームループに同期することにした。

ナビコンの影がモアレっぽく見える。

テストプレイ中、念のために仕込んでおいたフェイルセーフに引っかかった。
着地でパネルを落下させつつ隕石がパネルにヒットするとワークメモリが足りなくなる･･･のか？ そんなの頻繁に起きていそうな気がするが･･･。
着地で落下はパネル 2 枚でも 4 枚分処理してしまうのだな。まあそれはいいとして、隕石落下でワークが足りないときはインデックスが範囲を超えて･･･
これってオリジナルのバ･･･

そうか、daa は cf を見るから inc だと駄目なのか。

起動時のロードがどんどん長くなってさすがに洒落にならなくなってきた。
といっても圧縮ローダーみたいなのを搭載する余地は既に無さそう。
サルがお手玉しているデモを流す･･･は火に油を注ぐだけか。




ディップスイッチ設定。
とりあえず画面は作ってみたが、PC88 向けに設定できる項目を絞った方がいいかも。
サウンドテストとかいらないし切ってしまおう。

コンティニュー、、、どうしようか。
隕石が降ってこない設定とか、つまらなくなるかなぁ。

音源の切り替えはエミュレータでないとほぼ意味をなさないのに加えて、筆者がテストできないのでナシの方向で。
音源選択は初期ローダーでのみ行う。
PSG 版がお気に入り。宇宙っぽい感じが出て上々である。

あとはローディング画面を作らねば。
派手なのは同人っぽい感じがして印象悪いので控えめで。メモリも無いし。
予定になかったけど、少し思うところがあって入れることにした。4KB 空けた。


ギャラリー



疲れからか、不幸にも黒塗りのピューパに追突してしまうモトス。ピューパの主、暴力団員ビートルに言い渡された示談の条件とは･･･。

なにげにピューパの処理が一番多い。
他の敵のお供になっている場合や、ナビコンからの発生もあるので一番相手にする機会が多いとも言える。



62 面が最終面。
ナビコンは 5 個まで、敵は大小問わず 12 匹まで出せるが、これは消防法の関係･･･ではなくてワークメモリの最大である。

おそらくこの面よりナビコン 4 個とか 5 個とかの面の方が処理は重い。
重いけれど色々頑張ったおかげで、かろうじてゲーム性は維持できていると思う。


動画のツール作る人ほんと凄い。
意味不明なパラメータ、よくわからないファイル群、ツールチップすら表示されない謎のチェックボックス、ひとつ変えただけで大惨事になる設定項目etc
それを懇切丁寧に解説するサイトが充実しているのも凄い。

こういうのが後押ししたジャンルは相当あるんだろうな。
PC エミュレータの高品質な動画を撮る記事なんかにも需要があるかも。

というわけでビデオのリモコンを手にしたお爺ちゃんみたいな状態なのだった。


たいした意味の無いメモリマップ



SB2 に空きがあるが、色々削った結果である。
仮に何かデータをいれたとしても、それを処理するプログラムを置く余地がメイン側に無い。

小型・大型キャラクタを共に SB2 に入れられれば、描画ルーチンも省メモリ化できたと思う。
SB2 の余りが 76KB なので現状の 128KB は入らないけれど。

結局、描画ルーチンだけで 10 種類に達してしまった。小型・大型でそれぞれ 5 種、
あとはフォント描画や VRAM バッファへの展開なども含めるとメモリのかなりの割合を占める。


プロジェクトのフォルダを掘った日付を見て、我ながら少し引いた。

結局よく分からないものができてしまった。考えていたことや作りながら思いついたことは大体入れられたはずなんだけど。
自画自賛抜きに十分遊べるし ARCHON 並に面白いと思うんだけど、テーマ的にはどうなんだろ。従来のものとの違いは出せただろうか。

とりあえず PC88 の宿題の一つを片付けられたのはよかったと思う。えっ提出期限過ぎてる!?
『PC88 の 8MHz 世代は要らない説』は払拭できたかな?

このページを最後まで見た人の首もいい感じに痛くなったことだろう。

あとはどうするかなぁ。
2017 年がちょうど 0x20 周年なので（ちょうど？）Youtube にでも動画を上げようと思う。
ニコニコはフォーマットが変わったとかいう話を聞いたので調べてから。
その後は落ち穂拾いをぼちぼちと進めていこうかな。

疲れた。ちょっと横(画面)になるわ･･･。

おわり。

Thanks to 諸々協力頂いた方
▲ TOP