日記みたいな何か

連休が終わってしまいましたなぁ。相変わらず在宅ワークは続いていますが・・・。

CPS3のゼロキー版の命令抽出精度を上げるべく改良を進めている解析ツールを改善。ちょっとノイズ（命令候補として抽出されてしまうデータ列）が減ってくれました。

トワイライトプリンセスHD、シナリオが（多分）ハイラル城を残すのみとなったので、ここ数日はミニゲームとかゴースト討伐とかハートのかけら集めとかを進めていました。が、もうハートも最大になっていて、ゴーストも全部倒しちゃったので、残すはハンコ集めくらい。大妖精のいる洞窟をもう1回やるのもしんどいし、そろそろ終わりかな・・・

昨日、特に何もせず移行に成功したかと思えたWindows 10ですが、やっぱり何もしないのはまずかったらしく、再アクティベーションを求められました。一瞬焦りましたが、元のWindows 7のプロダクトキーを入力したら無事パス。ふぅ。

あと、メインのデスクトップWindows PCのRyzen化に伴い、64bit Windows 10マシンから外したパーツを32bit Windowsが入っているマシンに玉突きで導入してみました。元々ChipMaxのためだけの環境ですが、せっかくなのでGeForce GTX 750TiでもFolding@homeを動かそうかと思ったら、なぜかGPUが計算リソースとして表示されません。うーん、NVIDIAが32bit版 Windowsのサポートを終了した関係で新し目のドライバが入らず、そのせいで動いていないのかな？ 別途Linuxでも入れれば動きそうですが、新しいマシンに比べるとパフォーマンス的に全然大したことないから、無理してFolding@homeを動かさなくてもいいか・・・。

というか、GeForce GTX 750Tiのカードを挿してしまうと、PCIのスロットにパラレルポートの拡張カードが挿さらなくなっちゃうんですよね（厳密に言うと挿さるんだけど、ビデオカードのファンやヒートシンクとの間隔が2〜3mmみたいな距離になってしまう）。パラレルポートはマザーボード上のコネクタから取ればいいかなぁ・・・と思ったら、手持ちのパラレルポート引き出し用のアダプタは、ケーブル長が短くてケースの拡張カードスロットまで届かないという別の問題が判明。仕方がないので3.5インチベイのカバーを外してそこから引き出しましたが、これはかっこ悪い・・・ｗ

メモリ以外のパーツも届いたので、さっそく入れ替えてみました。

CPUはRyzen 5 3600にしました。

ケースと電源は再利用。ストレージや光学ドライブもとりあえず前のままで。

マザーボードはGIGABYTEのB450M DS3H。カッコいい！

CPUを取り付けました。カッコいい！

リテールファンを取り付け。カッコいい！

ビデオカードは玄人志向のGF-GTX1650-E4GB/OC/DFです。元々使っていたGeForce GTX 750Ti搭載のやつ（写真右）と比べると、大きさのギャップが凄まじいですね・・・。

一通り組み込んで、起動することを確認。

そのまま特に何もせず、普通にWindows 10も起動しました。

ちゃんとCPUも認識されています。便利な時代になったな・・・。

その後、無事Folding@homeも動き出しました。これまでの環境 (Phenom II X6 1065T + GeForce GTX 750 Ti) の 3〜4倍くらいのスコアが出ていますね。凄い。

先に注文しておいたDDR4のメモリだけ着荷ｗ。とりあえず16GBです。それなりのブランドでちょっと高性能なやつだとは思うんですが、何故かこれより下のクラスの製品よりもちょっとお安かったり。

MAME上のデバッガでCPS3のタイトルの命令を追っていたら、NOPでない2ByteのデータがなぜかNOPとして表示されていることに気が付きました。不思議に思ってソースを調べてみたら、どうも命令を判別する処理の実装が色々と怪しい感じ。NOPは本来「0009h」なんですが、実装を見ると、2Byteの命令の最上位4bitが「0000b」のときは下位6bitが「001001b」だったら無条件でNOPと判断されるようになっていました。つまり「0000_XXXX_XX00_1001b」なら何でもNOPになってしまうということ。なので、たとえば「03C9h」みたいな全然違うやつもNOPになってしまいます。

自前のツールで使っているライブラリも、元々MAMEの逆アセンブラから切り出して作ったものなので、当然同じ問題を抱えています。そしてこれを許してしまうと、既存の解析済みのプログラムをチェックする際に不正な命令を再エンコードしてしまいっている箇所を見逃してしまうことになり、非常によろしくない感じ。

というわけで、自作のツールの方でこの辺の雑な判定を修正してみたところ、先日は特に問題の見つからなかったストIII 3rd初期版の解析済みのプログラムにおいても、本来命令にはならないはずのバイナリ列 ($4858) が命令として再エンコードされてしまっているところが見つかりました (MAMEの逆アセンブラだと「SHLL8 R8」と解釈される)。

ちなみに、気になってMAMEのCPUエミュレータの実装の方も見てみたところ、こちらも逆アセンブラと同様にバイナリ列を緩く判定して処理していました。うーん、もしかして実機でもこういう風に判定しているのかな。プログラムがバグって暴走した時の挙動を正確に再現するためにこういう実装になっているみたいな・・・。

あと、MAMEの逆アセンブラのコードを検索しても何故か STC GBR,Rn が見つからず、不思議に思って調べてみたら、間違って STS GBR,Rn が割り当てられていました。CPUの方は流石に大丈夫でしたが、こっちは純粋に逆アセンブラのバグっぽいですな。

CPS3の解析、今度は既存の解析結果で「データ」として認識されているところに有効な命令列が埋もれていないかを探すプログラムを書いてみたりしているんですが、初代ジョジョとかで試してみたところ、埋もれたサブルーチンが結構な数出てきました。もちろんたまたま命令として解釈できるようなものも多く混ざっていたりするんですが、明らかに関数の形になっているものも結構あり・・・。まあ、どこからも呼ばれることのない関数なんだろうとは思いますが。

しかし、こうやって静的に解析するのにも限界を感じますね。どこまでやったら完璧と言えるのか全然わかりません。というか、そもそも、ストIII 2nd以外のタイトルについては、CPUが素のSH-2なら、デコード後に命令部分だけを抽出して再エンコードしたバイナリを用意する必要もないんですよね（機械的に全部デコードするだけで良い）。・・・ああ、そうか、MAMEのソースのスゴイBIOSにcps3bootとcps3bootaの2種類があるのはそういう理由かー。

ゴーストの魂を求めてさまよっていたら、いつの間にかシリーズ恒例の試練系のダンジョンに突入。何の準備もせずに入った割には粘れたんですが、最後だと思ったフロアにまだ続きがあって、そこで力尽きました。後で調べたら力尽きたのが49Fで、これが本当の最後のフロアだった模様。惜しい・・・