CD-ROM2 の読み込み時間の厳密な再現の必要性 / その3

David Shadoff さんの実測と再現ルーチンのおかげで、問題となっていた多数のソフトの動作の改善がみられました.

用語の規定

この文章内では下記といたします.

  • SEEK TIME: 読み込みコマンドを受けてから光学ヘッドが移動する時間.
  • READ TIME: 1 frame を読み込む時間. Compact Disc の 規格上 1/75 秒.
  • LOAD TIME: 読み込みコマンドを受けてからすべてのデータを読み込む時間. 細かい部分を無視すると SEEK + READ * sectors の所要時間.
  • 1 frame: Compact Disc のデータ単位. 2352 bytes. *1
  • 1 sector: CD-ROM で 1 frame の中の管理情報を抜いたデータ単位. 2048 bytes. 16 進数で 0x800 bytes.

SEEK TIME

機械的要素と物理的要素が関係するためわたしには理解が難しく、 David さんがほぼ解明してくださいました.

SEEK TIME はヘッドの移動距離が主なパラメータです. CD のデータは内周から外周にらせん型で等密度で記録されています. つまり1周あたりの frame 数が異なるためにセクタ番号の差分を割り算するという単純式では所要時間を算出できません. またモーターが停止から制動する時間の算出も簡単な数式ではありません. それに加えて、実物の経年劣化も時間が変わる要素となります.

実測は David さんが PCE 向けにプログラムを組んで PCE の VSync (約 1/ 60 秒単位) で計測してくださいました. 大きな傾向としては下記となります.

  • 同じ移動距離であっても vsync 単位でばらつきがおきる
  • 移動距離が大きいとばらつきは最大 20 vsync もでる
  • メンテナンスをしてあれば機種別の所要時間平均値は大体同じだが PI-CD1 はおそいらしい

この計測情報や問題となるソフトで必要な経過時間を元にらせん構造からの移動時間の算出ルーチンを David さんが作ってくださいました.

これらの計測を元に UperGrafx や Mednafen で問題となるソフトは改善しました. この再現によりビジュアルシーンでの絵と音のずれは直りましたが、場合によっては実機でさえ問題が起きたことを確認しています.

SEEK TIME の再現で一番の問題となっていたのは TJCD2023 夢幻戦士ヴァリスのオープニングデモ後半の下校シーンです. このプログラムは内周端から外周端の遠い距離に移動することと、CD SEEK の同期をタイミングとっていませんでした. 必要な SEEK TIME 時間は約 1.6 秒で現状のエミュレータではパッチをあてないとちゃんと動かないはずです.

READ TIME

SEEK TIME の実装によりビジュアルシーンの同期ずれは直りました. ADPCM 再生中にしてはいけない ADPCM RAM への読み込みの問題が直らないソフトがわずかにありました.

David さんの調査で最も厳密なタイミングを求めるソフトは HECD4007 ブランディッシュのオープニングデモ後半の「この大穴があんたの墓になるのよ!」でした. これも実機でさえ起きる不具合で、現状のエミュレータでもちゃんと動かないと思われます.

不具合の原理は下記となります.

  1. ADPCM 再生を開始
  2. CD 読み込みのコマンドを発行し、転送先を CPU にする (わりと長い)
  3. (タイミングが正確なら) ADPCM の再生が終わる (PCEソフト側が同期をとっていない)
  4. CD 読み込みのコマンドを発行し、転送先を ADPCM RAM にする.
  5. ADPCM 再生途中に CD 読み込みをしてしまい、 ADPCM の再生が延長される

2. の読み込みコマンドの所要時間内に ADPCM の再生が終わることが必須となります. 先述の SEEK TIME の再現がない場合ここは 1.6 秒も早かったです, SEEK TIME の再現をいれてもまだ 0.2 秒早かったです.


ここでタイミングチャートの作図をし、1 sector あたりの読み込み時間を分散して増やして、2. の読み込み時間を 0.2 秒増やすことにしました. つまり PCE の厳密な CD-ROM の 1 sector の READ TIME は、 CDDA での 1 frame の読み込み規格値 1/75 秒に 0.0017 秒を加算した値であると決めました. 作図上 no seek time と書いたところは実機では約 0.0017 秒の内部処理時間があると予想しています.

この時間は割と信憑性があるようで、似た症状が起きる TJCD2026 F1チームシミュレーション PROJECT.F や実時間で高い読み込み精度を要求する HCD5076 空想科学世界ガリバーボーイ の Arcade Card での HuVideo での問題も起きなくなりました.

同期をとらないソフトたち

HuVideo *2は明確に理由があるので仕方ないですが、CD SEEK や ADPCM 再生完了の同期をとらないソフトは場合によっては実機でも起きる潜在的なバグたちでした.
逆説的に申し上げますと同期をとっているソフトは SEEK TIME や READ TIME が違ってもちゃんと動きます. 問題が起きるかどうかはゲームソフトのプログラマの性格に依存するところが大きいです.

CD-ROM2 互換機能でちゃんと動作しないソフトはかなり減りましたが、別の原因で止まってしまうソフトがまだ数本あります. これらのソフトはどういうわけか1995 年以降の PCE の市場がほぼ終わってるときにでていたソフトたちで、特別なテクニックを使っているわけでもなく純粋に何をしているのかわからないひどいプログラムです. これは筆者の勝手な予想ですが、その当時 PCE のソフトを制作する会社なんてものは1社か2社程度で、汚いソースコードをひたすら使い回していたのではないかと思ってしまいます.

*1:frame とあるが video でいう frame (約 1/60 秒)は全く関係ない

*2:ブランディッシュもそうかも