続5：中華linuxゲーム端末Anbernic 353PSでセガサターン

今度こそyabasanshiro-saでGRANDIAのムービーが遅い原因を調査する

とりあえず忘れないうちに覚書をメモ

ここまでの調査でFBCRへの書き込みで画面をマニュアル更新していることは分かっている。要はこの画面更新のタイミングがなぜ遅いのかが問題となる。単にタイマーのエミュレーションにバグがあるとかだったら直せそうなので調べてみる。（そうであってくれ）

 FBCR(25D00002)への書き込みを行っているのがどこなのか探してみる。いろいろやったがよくわからず、SSFのデバッグ機能で、25D00002を検索した。（ような気がする。うろ覚え）

そしてprintf結果と突き合わせて、どうやら060129baでFBCRに書いているようだとわかった（と思う）

そしてその近辺でpcをprintfした。普通こういうタイミングが重要な処理は割り込みのタイミングでやるはず。急にアドレスが飛んで戻っているので、おそらく割り込みだろうと決めつけて調べる。

pc 06039f94
pc 06037b10
pc 06013a1c <= なんとなくここで割り込みっぽい気がする
pc 06012952
pc 06012988
pc 0601298e
pc 06012996
pc 060129a8
pc 060129ba
mw 25D00002 @060129ba
pc 06013a34
pc 06015144
pc 06015160
pc 060151c8
pc 060151f4
pc 06015210
pc 06015222
pc 06039ae4

再びSSFで06013a1cを検索、06000a04が見つかる。なんか割り込みベクタっぽいアドレスだ。ただ、SSFの画面を見る限りはVBRは06000000と060000400で、微妙に遠い。ただ、限りなく割り込みっぽいので、Interruptで検索してprintfを入れまくる。そしてここで06013a1cを登録しているっぽいことが分かる。

static void FASTCALL BiosSetScuInterrupt(SH2_struct * sh)
{
   SH2GetRegisters(sh, &sh->regs);

   LOG("BiosSetScuInterrupt. vector = %02X, func = %08X\n", sh->regs.R[4], sh->regs.R[5]);

これで、どうやらベクタ番号41番と分かり、先日見つけたサターンの仕様を見ると

SCU Interrupt
bit 1    V-blank-OUT    VDP2    vector 41    Level E

となっている。1画面書き終わったら発生するV-blank-OUTの割り込みのようだ。という事は単に1画面60フレームごとに割り込みでマニュアル更新しているということになる。

単に画面の描画が60fpsに間に合ってなくて遅くなっているという事だろう。エミュレーションバグとかではなかった。簡単に治せそうにない。当てが外れたようだ。

フレームスキップが有効になっているが、無効にしても同じ速度で動いている。自動フレームスキップが何の役にも立ってなさそうだ。 何か違うところが遅いのかもしれない。

実機でしか動かせないからどこが遅いのかしらべるの大変そう。。