事の発端はtwitterでマークⅢの上下分割スクロールの動画を見た時でした。
2つ前の動画で「グラディウスⅡ」のOPぽいものを動かしてみたのですが
流石に上下スクロールが入る1面はできない、作ったとしてもMSX版エピソードⅡを
きれいにした感じにしかできないと思っていたのでこの発表は衝撃でした。
9918モードを調べる。まあMSXじゃね？
しかしながらただでさえグラフィック的に詰め込みが厳しいのにさらに
9918モード用のデータが共存できるのか？
まずは9918モードの表示を行わないといけないので早速9918モードの詳細を
ネットで調べてみました。
グラフィックモードはどちらを使用する？
まずGraphicⅠモード、GraphicⅡモードどちらにするか悩みました。
GraphicⅠモードは占有するメモリが少なくて済みますが表示は単色になるので
上の画面とあまり差が出るのは好ましくないのではないか？
GraphicⅡモードはある程度上の画面とのギャップをつけず表示ができるのはいいのですが
カラーテーブル分のデータの増加が一番きつい。
動画用なのでとりあえず見た目重視でGraphicⅡで表示してみるかと組んでみたのですが
ここでGraphicⅡ用のカラーテーブルは詰め込んだPCGアドレスの
2000h反対位置に置く必要があり、今回の場合スプライトCG領域の
ど真ん中にカラーテーブルが居座ることになることが分かりました。
PCG的アクセス？グラフィック的アクセス？
また、Ⅰ,Ⅱ共通の問題でグラフィックとしてアクセスするかPCGとしてアクセスするかの
も問題も発生しました。9918のBGのネームネーブルにはPCG番号しかありません。
パワーメーターのように黄色に点灯するというのはPCGとして別に登録する必要が
あるということです。必要PCG個数を調べますと74個分のPCGが必要になりました。
一方で下の2行のステータスにPCGを並べ、必要な部分のPCGを書き換える
グラフィック的な使用方法も考えられます。この場合PCGは64個固定になりますが、
メーター一つを点灯するのに32~64バイトもVDPに書き込まなければなりません。
ステータスにはスコアの書き換えも含まれますので結構なアクセスが必要になります。
ここはPCGとしてアクセスする方法を選びました。
最適化。表示されない領域はマークⅢモード側で使用しても構わない
ここまでで大体9918モード用のデータがVRAMを占有する領域が確定できました。
そこからさらに実際には下2行しか9918モードで表示しない制約からエリア０と
エリア1にはデータを置かなくてもよくなりました。
（9918はPCG番号を8ビットでしか持たないため画面を8行ずつ3分割し表示するための
情報を決め撃ちしている）
あとがき。でも本当の移植はここから
それでも結果的には9918用データがVRAMを虫食い状態にしたことは変わらずで
ここから残った領域にグラディウスⅡを移植していくという、
まさに「おれたちのたたかいはこれからだ」状態に突入したのでした。