2020年5月4日の日記の2番目の記事へのコメント
■基板
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月4日の日記の2番目の記事へのコメント
[コメントを書く]