2020年5月8日から2020年5月4日までの日記を表示中
2020年 5月 8日 (金)
■基板
昨日に続き、今日もCPS3のゼロキー版の命令抽出精度を上げるべく解析ツールを改善。さらにノイズが減ってくれました。しかし、やっぱり進みはするけど終わりはあるのかという疑問がつきまといますな、この活動・・・。
2020年 5月 7日 (木)
■休み終わり
連休が終わってしまいましたなぁ。相変わらず在宅ワークは続いていますが・・・。
[コメントを書く]
■基板
CPS3のゼロキー版の命令抽出精度を上げるべく改良を進めている解析ツールを改善。ちょっとノイズ(命令候補として抽出されてしまうデータ列)が減ってくれました。
[コメントを書く]
2020年 5月 6日 (水)
■トワイライトプリンセスHD
トワイライトプリンセスHD、シナリオが(多分)ハイラル城を残すのみとなったので、ここ数日はミニゲームとかゴースト討伐とかハートのかけら集めとかを進めていました。が、もうハートも最大になっていて、ゴーストも全部倒しちゃったので、残すはハンコ集めくらい。大妖精のいる洞窟をもう1回やるのもしんどいし、そろそろ終わりかな・・・
[コメントを書く]
■PC
昨日、特に何もせず移行に成功したかと思えた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インチベイのカバーを外してそこから引き出しましたが、これはかっこ悪い・・・w
[コメントを書く]
2020年 5月 5日 (火)
■PC
メモリ以外のパーツも届いたので、さっそく入れ替えてみました。
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倍くらいのスコアが出ていますね。凄い。
[コメントを書く]
2020年 5月 4日 (月)
■PC
[コメントを書く]
■基板
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の方は流石に大丈夫でしたが、こっちは純粋に逆アセンブラのバグっぽいですな。
[コメントを書く]
2020年5月8日から2020年5月4日までの日記を表示中
[コメントを書く]