CDの読み込みバーが常に動き、動画も同じ場面が何度も再生される.
ただし進行はできるようで動画の再生時間が終わると操作可能.
ゲーム起動直後の曲が停まらず 「ロンドン..」とつながる部分は, ADPCM 再生中に length register を操作していた. これを無視していたので他の bit 同様見落とすことのない仕組みに変更.
最近の ADPCM コントローラの改善により、それで動画部分なども問題なく動いているようにみえる.
しかしなぜか CD の read しつづける問題は起きている. もとのプログラムが BIOS を無視してレジスタを無理矢理操作していることもあり、別の修正でまただめになる可能性が高い.
これの対応はここまでにして保留にする.
CD の loading に wait を追加した都合で、 ADPCM RAM への書込みタイミングがかわった. これに伴い、追記の内部処理手順がかわったのでタイトル画面の曲の終わりの部分がおかしくなった.
主な原因は PCE 側のプログラムが再生途中に length を変更するなど無茶な手順を踏んでいることが原因.
mednafen pce_fast module では最初の曲は問題ないが、動画に関しては乱れる. HuVideo と動作が似ているように見える.
I also feel that there are two issues: one on the title screen, and one during video playback.
Title screen:
-------------
I have attached an "enhanced Mednafen log" of the title screen play.
The ADPCM buffer is first loaded completely; then, half played back. This is OK, and runs for ~4 seconds.
Next, while the second half of the ADPCM buffer is being played, the first half is being reloaded. Playback is good until the original end of the buffer (~4 seconds). UperGrafx seems to have a different behavior at that point.
My conclusion is that the issue happens at overflow/wrap time (when pointer changes from $FFFF->$0000),
Please check the following:
1) ADPCM write (especially DMA transfer) may not work well for buffer overflow (it should wrap to $0000).
2) Playback may not work properly for buffer overflow (it should wrap to $0000)
4) The read pointer and write pointer may not be properly isolated from each other (this is probably OK)
Video playback:
---------------
The game loads data byte-by-byte into ADPCM memory, while playback occurs. I was able to make Medanfen behave in a similar way, by making the "write delay" slower (but making it faster had no effect).
Review the speed of ADPCM memory write from port at $180A.
(log not attached; I can provide one if needed).
Title screen:
Write180D: $68, $70
The cause of problem is read address register when the playing.
ADPCM playing time scheduling (fifo controller) is not perfectlly.
Video playback:
I checked the code writing 0x1ff80a ($180a).
It's a terrible code... A transfer code never check 0x1ff80c.r.0 when it writes to 0x1ff80a. HuVideo and Top wo Nerae vol.1 checks writing status when it writes to 0x1ff80a.
It write to 0x1ff80a to with no-condition, we have to know how many datas are ignored on the real system. If any datas are not ignored, it is need more FIFO. EP2C5 (FPGA) has no more logic element for a new FIFO...
next, I have to change priority time management in the ADPCM RAM controller when a MSM5205 is playing.
UperGrafx is not software emulator, it's difficult to manage shared RAM.
このような問題を持つソフトがシャーロックホームズシリーズだけであれば直す必要があるのかよく考えねばなりません.
ADPCM fifo と memory controller を修正したのでそのついでに細かく見たらかなり改善した.
ADPCM fifo は深さは 1 M4K の最低値, 4 bit x 0x400 word としていたが更新頻度に対して深すぎるので 4 bit x 4 word に変更. 事実上 fifo はなくした.
ついで fifo を追記する state machine の動作を久しぶりに確認.
CD-ROM fifo から ADPCM 用 RAM に書く過程と ADPCM 用 RAM から ADPCM fifo に書く過程で dead lock 状態になっていた. この dead lock 状態を解消し、どの状態でも 6280 address 0x1ff80d.w の書き込みをすぐに反映するようににした.
この2つの修正で、オープニングの曲の終盤が正しく再生されるようになった.
0x1ff80d.w への制御をすべて対応するようにしたので下記の動かないソフトでも改善を確認.
- スチームハーツ
- てきぱきワーキンラブ
- DE.JA
It cames from dessert は改善しなかった.
シャーロックホームズの動画の音声の再生は一見問題ないように見えるが、音声の再生がどこかで飛ばしてしまうようで、本当の正常の再生と比べて早く音声が終わってしまう.
https://youtu.be/kHnXSA03TIE
動画です.
read timer を遅くすることでこの問題は解決できるが、 HuVideo の再生が途切れる. HuVideo は早めを求めるし、シャーロックホームズは遅めを求める.
両者の中間点を探ってみたが、動画の再生時間が長ければ結局はだめになってしまう.
read time の調整は別にして、 1 read command 発行毎にかかる seek time の 32 ms の高い精度がないと解決できないと予想される.
まだ細かい調整は必要ですが、無難に動くようになりましたので修正済みに変更します.