Graphic4 rendering issue (F1Spirit3DSpecial)

[suzukiplan]

F1Sprit3DSpecialの描画乱れを確認

s1	s2

1. 空の境界部分にゴミ（H-Sync割込タイミング誤り？）
2. コースが多重に表示される（横ハードウェアスクロールのクリッピングミス？）
3. メイン画面とコックピット画面の間に1行の描画乱れ（H-Sync割込タイミング誤り？）
4. コース上に謎のゴミ描画（これがよく分からない）

4 はコース上毎回同じ位置に出るっぽい。
演出かと思ったがWebMSXでは何も表示されない。

[suzukiplan]

b57f432 の修正が間違っているかも（この修正を入れないと画面上方の背景処理がおかしくなるので何となく入れてみたが G4 は 1行 128 bytes なので AND 0x7F の状態で正しいはず）

※参考までにこの修正を入れない場合、33〜64バイト目の表示が下図のようになる

（左: VRAMダンプ, 右: ディスプレイキャプチャ）

[suzukiplan]

上図の「ココかな」の推測は誤っているっぽい
この動画 でこの部分と思しきグラフィック表示を確認したところ、真ん中（青）が連続表示されていた。

[suzukiplan]

よくよく見ると「Hobil 1」の看板の左（コーラみたいなヤツ）の左に KONAMI の看板ではなく旗が立っているので、赤の部分も期待した表示になっていないっぽい。

なるほど（MSX Datapackのハードウェアスクロールの解説の偶数ページ、奇数ページの扱いを読み違えているバグのような気がする...自信はない）

[suzukiplan]

とりあえず b57f432 は revert 1271f4c

[suzukiplan]

MSX2+のハードウェア横スクロールの説明を改めて確認したところ、

SP2=1のときは、 パターンネームテーブルの先頭アドレスは、 奇数ページ が選択されるように設定します。
各テーブルのベースアドレスは次のようになります。

との注意書きがあった。

この注意書き通りに実装されていれば問題は起きないが、SP2=1の時にパターンネームテーブルの先頭アドレスに偶数ページを設定していた時の動作が、現状の実装が期待値と異なるかもしれない。（そして、F1Spirit3DSpecialはページ0だから偶数ページを設定している）

現状の実装では bit-15 を反転していた (addr EOR 0x08000) が、クリア（addr AND 0x17FFF）するように修正する。

修正commit: 51bcf73

[suzukiplan]

F1Spirit3DSpecialのVRAM usage analytics

やはり、想定通り Page 0 をメイン表示にしている。
そして SP2 は true にしているっぽい。

H-SYNC は 3箇所確認

• H-SYNC #1 ... 38pxの範囲で上下に動くことで空の高さを表現
  • 登り坂では空を狭く、下り坂では空を高くしている
  • カーブ中はハードウェア横スクロールしつつ背景画像をPage 3から部分的にブロック転送しながら書き換えている
• H-SYNC #2 ... コース描画の起点
  • この割込を検出してから次の割込 H-SYNC #3 を検出するまでの間、1スキャンライン毎にハードウェア横スクロールの値を変えてカーブしているコースを表現
• H-SYNC #3 ... コクピット表示

[suzukiplan]

H-SYNC #2 のタイミングでネームテーブルアドレスを Page 1 にしているものと考えられるが、その部分が何故か効いておらず（多分エミュのバグ）、これによりコースが多重表示されるバグが発生するものと考えられる。（ネームテーブルアドレスの切り替えが想定通りに行われているかチェックする必要がありそう）

[suzukiplan]

CPUのクロック計算が期待値と異なっている可能性がありそう。

以下によるとMSXのZ80は全命令 +1Hz ではなく、一部 +2Hz の命令もあるらしい。

https://taku.izumisawa.jp/Msx/ktecho2

[suzukiplan]

#1 (comment) の件で、試しに CB, ED, IX, IY 命令で +1 ウェイト増やしてみたが変化なし。

[suzukiplan]

commit 638ae84 で4以外の問題は一通り解消済み

[suzukiplan]

4は恐らくコマンドのどこかがバグっているのではないかと思われる。
あとコース描画時に細かい乱れがあるが、その点はCPUサイクル計算が想定と異なる可能性があるので #1 (comment) の対策も必要という認識。（ただし、細かい描画乱れは OpenMSX や WebMSX でも発生することもあり、プレイ上は支障もないことから仕様かもしれない）

[suzukiplan]

すっかり忘れていたが、タイトル画面がバグっている。
ちなみにデモディスクで起動した時のタイトル画面はバグっていない。

ディスクAのタイトル（描画乱れ）	デモディスクのタイトル（正常）

KONAMIロゴの描画終了からタイトル遷移までの間のコマンドログをディスクAとデモディスクで見比べれば、バグっているコマンドの特定が簡単にできるかも。（あわよくればこれが現象4の描画乱れの原因にも関係するかもしれないので、タイトルの描画乱れの原因調査をするのが近道な気がする）

[suzukiplan]

DISK A と DEMO DISK のコナミロゴを表示しきった後からタイトルへ遷移するまでのコマンドログを確認したところ、DISK Aの場合、以下のコマンドを実行後に HMMM コマンドで描画を行っている。HMMMコマンドの実装内容には差異はないので バグっているのは HMMC コマンド だと思われる。

ExecuteCommand<HMMC>: DX=52, DY=372, NX=64, NY=80, DIX=2, DIY=1, VAL=$EE (SCREEN: 3)
ExecuteCommand<HMMC>: DX=116, DY=372, NX=64, NY=80, DIX=2, DIY=1, VAL=$EE (SCREEN: 3)
ExecuteCommand<HMMC>: DX=180, DY=372, NX=32, NY=80, DIX=2, DIY=1, VAL=$EE (SCREEN: 3)
ExecuteCommand<HMMC>: DX=0, DY=272, NX=64, NY=80, DIX=2, DIY=1, VAL=$44 (SCREEN: 3)
ExecuteCommand<HMMC>: DX=64, DY=272, NX=64, NY=80, DIX=2, DIY=1, VAL=$44 (SCREEN: 3)
ExecuteCommand<HMMC>: DX=128, DY=272, NX=64, NY=80, DIX=2, DIY=1, VAL=$44 (SCREEN: 3)
ExecuteCommand<HMMC>: DX=192, DY=272, NX=64, NY=80, DIX=2, DIY=1, VAL=$99 (SCREEN: 3)

※なお、ログはHMMCの初回（DX,DY等の初期設定）のみを記録
※ SCREEN: 3 は GRAPHIC 4 (MSXでいうところの SCREEN5)

[suzukiplan]

VRAMを覗いてみたところOAMが壊れていることを確認（タイトルのVRAM = Page3は壊れていないので）

※前半2ページはYJKカラーの1枚絵

[suzukiplan]

HMMCによるVRAM書き込みをコメントアウトして確認したところ、タイトルの描画乱れは治らなかったのでHMMCはバグってなかった模様（OAMのアドレス設定がうまくいっていない感じか）

[suzukiplan]

Mode 2 Sprite の attribute table アドレスはどちらも同じ（$7600）

VRAM の真ん中よりちょい上の辺りで、DISK Aの方だと謎の黄色い縦線が入っているが、この辺りかな。

DISK A VRAM	DEMO VRAM

自然画（YJKカラー）の内容も微妙に違う気がするが、これは実際に構図は同じだが明度が微妙に異なることによるもの。

DISK A YJK Color Graphic preview	DEMO YJK Color Graphic preview

[suzukiplan]

m2pencで現在の描画乱れ状態を録画

https://www.youtube.com/watch?v=fcP9MWz4psQ