続4：中華linuxゲーム端末でセガサターン

yabasanshiro-saでGRANDIAのムービーが遅い原因を調べている。覚書のメモ。（実は雑音がひどいだけで遅くなかった）

ソースコードvdp2.cpp:882くらい

swap_frame_bufferがmanual changeされていて、VDP1 offset 0x02にval=3が書かれたとき更新される。

FBCR	Frame buffer switching mode

どうやら遅いわけではなく、もともとそういうスピードにしてそう。

音が雑音だらけで遅くなっているのかと勘違いしていた。どうやら雑音だけの問題の模様。

SCSPのSLOT04とSLOT08を使っている模様

04だけ止めるとほぼ無音（あっているのか？） 

08だけ止めたがノイズまみれ。ただ、部分的に問題なさそう

とりあえずSLOT04が悪いようだ。

データを見てみると、サウンドバッファにあるデータをM68kに投げて、データを戻してから再生するようだ。おそらく、M68kとやらを使って圧縮された音を展開しているんじゃないだろうか。

原因を調べようとprintfを入れると音がマシになる。

またタイミング問題かよ。。。

memo

なんかyabause.cのあたりで、CPUシミュレーションとSCSPシミュレーションの同期が取れてないような気がしてきた。

とりあえずyabause.cの中を見てみる

deciline = 1/10ライン
SCSP 44100 * 512 clock？
M68k 44100 * 256 clock？

decilineの9と10でHBlankINとHBlankOUTになり、ScspExecされる

PAL 50フレーム x 313ライン
NTSC? 60フレーム x 263ライン

1/10ライン当たり 143.0874... clockということ
この端数が良くないとか？

scsp_cycles_per_deciline =

VLBlankで
    setM68kCounter((u64)(44100*256/60)<<SCSP_FRACTIONAL_BITS)
    SmpcINTBACKEnd()
    Vdp2VBlankIN()
    SyncCPUtoSCSP()