この大穴があんたの墓になるのよ!
という後に ADPCM を再生ながら data ロードをする.このあと ADPCM の再生がノイズ混じりでおかしくなり、映像もおかしくなる.
これは問題の部分まで長いので細かい分析はできてないが,<BTS:68> に非常に似ていると予想される.
ADPCM 再生中に READ(6) を数回発行. たぶん最後の READ(6) の転送先が ADPCM 用 RAM になっていて追記が発生. そこでボイスがおかしくなる.
追記したデータが 1 byte ずれて VRAM に転送しているように見える.
pomping world はたぶんバグ. こちらは意図的に行なっている.
mednafen pce_fast module で音の乱れは再現,絵の乱れは再現せず.
CD読み込み時間を等速相当に設定したら絵の不備は改善した.
音はまだ直らない.
https://youtu.be/5dBZDFbRcrs
D8> track04
D9> track05 play+IRQ2
audio play
paused
drive stop
08> 002203 04-> 6280
08> 002213 5C-> 6280
08> 00226F 18-> 6280
08> 00228F 10-> ADPCM RAM 02 <- 追記が 2 つあってどっちかわからない
08> 002287 08-> ADPCM RAM 02 <-
08> 002207 0C-> 6280
D8> track05
D9> track06 play+IRQ2
audio play
08> 00228F 10-> ADPCM RAM 02
開始直後の ADPCM controller の波形. by signaltap ii
この時点での重要地点は ADPCM 再生残り時間. signaltap では rw_length (0x33d9), Mednafen (0x2937) では --ADPCM-- の length がこれを指す.
本物の場合、 seektime があってADPCM 再生残り時間はこの時点で 0 になっている. 仮に ADPCM 再生残り時間を 0 にしたい場合は 0x33d9 * 2 / (16_044.4) で 1.6 秒の待ちを増やす必要がある.
調査前は rw_length が 0x1000 未満の小さい値であればその分の待ちを増やす調整をするつもりだが、いまでも十分に早いため調整はしない.
08> 00228F 10 -> ADPCM RAM 02 の前にある3つの read(6) コマンドで最低でも 1.6 秒の待ちがいるかは計測記録のある根拠のある値が必要. 根拠のない待ち時間を他の CD-ROM2 ソフトへ影響に与えることは現状はできない.
現実的な対策は問題の部分へ ADPCM 再生が終わるまで同期をとることが適切.
(誤)
調査前は rw_length が 0x1000 未満の小さい値であればその分の待ちを増やす調整をするつもりだが、いまでも十分に早いため調整はしない.
(正)
調査前は rw_length が 0x1000 未満の小さい値であればその分の待ちを増やす調整をするつもりだったが、その値が想定外に大きかったので調整はしない.
ゲームの進行は止まらないことと精度の高い資料が必要なので保留.
TRACK 05 の MSF が 07:30:04 その次の READ(6) が lba 0x002203 (01:58:07) でシーク時間の内ヘッドを動かす時間が1秒以上もかかるのかわからない.
During the scene, sound is mostly CD-DA, but the problem section does several CDROM reads. ADPCM is played during this time.
During this time, there are 6 CDROM data reads from the same area on the data track (the final two reads are into ADPCM memory).
The expectation is that (head seek time + data read time) for the first 4 reads, plus head seek time for the first ADPCM read, will be longer than the ADPCM playback. If it is faster than ADPCM playback, the ADPCM registers and/or memory can be corrupted, causing the noise.
Testing with Mednafen, the problem happens if each head seek time is 306 milliseconds, but not if each head seek time is 320 milliseconds.
On my "fast" Duo-R, I measured head seeks in this region, and they took 16-20 VSYNCs with an average of 19: 266-333 milliseconds, average 316.
This means that it is possible for a real machine to see this ADPCM problem (at least sometimes).
I tested on my Duo-R, and I saw the problem on a real machine.
READ TIME の 1/75 秒のタイマの設定条件を修正.
READ TIME が少し長くなったことにより、問題の READ command より早く ADPCM の再生が終わることを確認.
READ TIMER が規格通りの 1/75 秒では早く、問題がでないようにするには実測値で 208 ms 遅くする必要があった.
問題の ADPCM 再生中に発生する READ sector 数から READ TIMER の値を算出した. 1/75 + 1.73 ms とすることでタイミングがシビアなこのソフトとガリバーボーイ+ArcadeCard の HuVideo での安定を確認した.
$ r 'p 0.208 / (4+0x5c+0x18)'
0.0017333333333333333