SDCard の不調

開発をしている機材で動作がおかしいメモリーカードがたまにあります. 公開当初はこちらの実装が悪いので修正というのが多かったのですが、最近2例メモリーカードの方が悪いというのがありましたので掲載いたします.

注意

記載での使用モードは SPI mode での確認です. 各カードは1枚ずつの確認のため同じ型番のものがすべて該当するかは不明です.

CMD12 の規格違反, AUSDX64GUICL10-RA1

CMD12 (STOP_TRANSMISSION) は CMD18 (READ_MULTIPLE_BLOCK) 発行後に停止するコマンドです. このコマンドの後に R1b response がくるはずですが、このカードはそれがきません. R1b response を無視すれば意図通りには動くのですが本当のエラーの時の対処ができないので無視の処理はいれてありません.

異様に遅い data packet, SP064GBSTXBU1V20BS

CMD18 発行後、 data packet 単位にデータがきて、 data packet の区切りには待ち時間がいくつかあります.その時間や読み捨てるデータのために CDDA 再生には fifo をもうけてあります. そしてこのカードは CDDA 再生途中に fifo が空になりました.
調べたところ特定のセクタで次の data packet がくるのに 50 ms もかかりました. fifo の深さを 16 倍にすればこの遅さに耐えられますがいままでこのような不具合はみたことがなくカードの不備と判断いたしました.

これは seek 時間ではなく単なるシーケンシャルアクセスです. よくアクセス速度にかかれる UHS-1 とか CLASS 10 とかは SPI mode なので関係ないです. それと比べてとても遅いであろう MMC でもこのようなことは起きませんでした. もちろん CDDA 再生としては MMC でも十分に早くこのような問題はありません.

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:ブランディッシュもそうかも

自分で作った潜在的なバグ

最近他人が作った潜在的なバグに言及しておりますが、upergrafx のソースコードにも本来ならすぐに起きるはずのバグが起きずに放置、その後の謎の現象となり、調査したら稚拙なバグが2件も見つかってお恥ずかしい限りです.

  • write strobe の正負の論理を間違える
  • address decoder で read 用 databus 入力で read strobe をデコードしてない

address decoder のほうはなんでいままで正常に意図通りに動いていたのが不思議なぐらいのバグでした. そういう変なバグがあると開発が停滞しますが、そこを抜けたので今回の回収も落ち着くといいのですが...

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

CD-ROM の 1 sector のロード時間を規格通り 1/75 秒に設定したところ、ロード時間が早いために問題になっていたソフトが結構直りました. 一方直らなかったソフトの傾向を見ると下記のようでした.

ロード時間の前後の処理時間を要求するもの

1 sector のロード時間を設定しても、その前後の準備時間や後処理の時間はわからないままです. 準備時間はシーク時間で別に書くとして、後処理のレジスタの変化の微妙なタイミング要求するソフトまでありました.

このような高い精度を要求するソフトは...正直に申しまして...プログラムが汚く読めたものではありません. 初期化やタイミング同期を省略しているので本物のハードのタイミングでのみ奇跡的に動いているものが多いです. これはプレイヤーが遊んで名作かというのは関係なくプログラマの性格やそのソースコードを使い回す職場が原因で困りものです.

シーク時間の再現を要求するもの

CDDA の音ズレの原因がロードではなくシークの時間の再現がいるようです. シーク時間は CD のレンズが物理的に動く時間で実機からの計測がいります. これもシークしてから再生すればいいだけなんですがとってないみたいです.

当ユニットのユーザーさんの間では人気のスーパーダライアスでは最初のクレジット音とゲームの開始も同期を取らずにシーク時間決め打ちで動いているようです. mednafen でもシーク時間を再現してないみたいで、ゲームを遊ぶ側にとってはダメな演出になっています.

ADPCM 用 RAM のメモリアクセス待ちの再現を要求するもの

風の伝説ザナドゥで港のシーンにいく前に CDDA 再生したまま, ADPCM 用の RAM (本物は DRAM) から VRAM に転送しているようでして. メモリアクセス待ちを設定しないのかずれてしまいます.

これは実機からの計測で待ち時間の法則性を得て再現性をあげる必要があります. 元のプログラムで CDDA を PAUSE するか時刻指定で再生し直すだけで同期はとれたと思うのですが...

実機計測かパッチか

(次回に続く)

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

現在の不具合報告に登録してあるソフトの不具合の原因が読み込み時間が実機と違うのでちゃんと動かないというのがある程度わかっています.

別件で mednafen の document を読んでいたら pce_fast module で CD-ROM の読み込み時間を設定で変えられることをしりました. それが再現するかみてみたら大半は再現しました. mednafen で pce と pce_fast と2つ emulation engine が存在するのはこの理由でしょう. 他のエミュレータがこの乖離をその場しのぎのパッチで補正するよりかは、わたしとしては*1 mednafen はいい選択と思います.

PCE の CD-ROM2 の場合、読み込み速度がかわっていても同期を取る仕組みはあります. 問題にならないソフトはちゃんと同期をとっているんですが、問題になっているソフトの大半は同期を取っていないとか初期化を省略しているとかの潜在的なバグが表にでてきてしまっています. 潜在的なバグを直すことはよいのですが、意図的に同期を取らないソフトもわずかに存在します.
意図的に同期を取らないソフトは HuVideo を使うものとブランディッシュぐらいです*2.

というわけで厳密な読み込み時間の再現を実装してみますが、意図的なものを動くことを目標にしまして、潜在的なバグは回避策がなければパッチをあてるほうが無難なのかもしれません.

*1:ゲームを遊ぶことだけを優先せずに現状動作がおかしくても再現度をあげるとかデバッグ情報が豊富という視点

*2:手元にイメージがないんですがネクスザール(通常版)もそうな気がします

9821 のハードディスク相当を復旧する / その4 (終)

Filesystem 関連

前回細かく書いていたのは LBA=0 を PC-98 用, AT 用に調整すれば現行のパソコンから普通にファイルシステムにアクセスできるだろうという考えでした.

結論からいいまして下記でした.

  • NEC 5.0 の FAT header のフォーマットが謎で RCF-X 64MB で発生して 2GB の SD カードでは NEC 6.2 だけだった
  • NEC 6.2 だけのほうは AT 用の MBR として LBA #88 からにすれば普通に mount できた
  • FAT header の offet 0x1fe に data 0x55, 0xaa が規格上いるはずが NEC は書いてないし, 今の Windows でも文句をいわない
  • RCF-X 64MB は LBA #88 から FAT として Windows からフォーマットした場合は PC-98MS-DOS からも使える
  • どちらの場合も 1 cylinder = 8 Heads , 17 Sectors; 8 * 17 * 0x200 -> 0x11000 となる.

当然ながら MBR だけ書き換えて mount するという考えは別の方がちゃんとしたツールを作っていましたので NEC 5.0 の謎フォーマットだけが問題でした.

TCP/IP

LGY-98 を持っていましたので下記の文書のままでそのまま使えました.
http://www.qsl.net/ja0rug/teene.html

TEEN 用の ftp client やWindows共有フォルダアクセスツールも普通に使えました. Windows のほうはセキュリティ甘めが必要でした, パスワード有りはやってみたけどだめでした.
つまりオンラインのファイルの受け渡しも問題なくできます.

ゲーム

ちゃんと動きました. でもゲームやるだけならエミュレータのほうが楽かなと思いました. 何より 2018 年の常識では PC-9821 の寸法は大きすぎで邪魔です. 2010年あたりからコンピュータ用の機器がどんどん小さく高性能になっていくのはなんとなく気付いていましたが、 1997 年の常識とは全然違う物でした.

おわり

SCSI カードが動かなくなっていたので、 16GB や 8GB の flash media が使えません. FreeBSD (98) の導入はやらずにここで終わりにします. LGY-98 や MS-DOS 起動ディスクの所持がハードルでしたが、それ以外は機材も簡単に揃いますし、ソフトの操作も経験があれば難しいことはありませんでした.

一応この機材を残していた理由が PC-9821 実機ででないとできないことのためで、それが PC-98 向けではないフロッピーディスクの解析でした. 5 インチディスクとかファイルシステムがない特殊用途とか、そういう依頼がたまにあったので残していました. それも死んでいた期間に依頼があったわけではなかったし、私だけがそれをやれるという分野でもないように感じました.

PC-9821 のハードディスク相当を復旧する / その2

手元にある Compact Flash は昔デジカメで使っていた RCF-X 64MB です. これは websitehttp://buffalo.jp/php/lqa.php?id=BUF9612 [コンパクトフラッシュを起動ディスクとして ご利用いただくことはできません。]とありましたので別のメディアも買いました.

Trancend TS16GCF133 と No brand EXTREME CF アダプター UDMA TYPE II SD です. TS16GCF133 はデータシートに True-IDE mode のことが明記, EXTREME CF... のほうは .com のほうの amazon に True-IDE mode support と書いてありました.

機材があらかた到着して,PC-9821V16 につけて動作させてみたところ TS16GCF133 は容量制限で memory check 以降の動作(OS 起動)になりませんでした. 容量制限,つまりこの機種の IDE port の固定ディスクは 4.x GB までです. そんなことは購入当時から知ってて PCI bus に挿して IDE コネクタが付いてる SCSI カードを持っていたので容量制限は関係ないと思っておりました. でもその SCSI カードがどうも動いてないみたいでした...

RCF-X 64MB も使えますし、EXTREME CF アダプターも使う SDCard が 2GB なら固定ディスクとして OS が起動できました.