移植がうまくいかない！！

XPCEというC言語で書かれたPCエンジンエミュレータを、iアプリのJava（DoJa）に移植する作業を行っています。

Javaにはunionやstructがないので、その辺はclassに書き換えました。

前回も書きましたが、問題なのが、unsigned型をどうするかということ。

CPUコアである「M6502」の主なレジスタは、unsigned char型で定義されていますが、Javaにはunsigned charに相当する
符号無し1byteの型が存在しません。
よって、int型で定義するように変更したうえ、AND演算でマスクして、0〜255で循環するようにしてやる必要があります。

しかし、
M6502のソースから、0〜255の循環を想定している部分を見つけて修正していくのは、けっこう難儀ですねえ…

でも、だいたい修正しました。

実行！！

でも、

クマー？？？
　 　∩＿＿＿∩　　 　　　　　　
　　 | ノ＼　　　　 ヽ　 　　　　　　
　　/　　●゛　　● |　　　　 　　　
　 |　∪　　( _●_)　ミ　 　　　　
　彡､　　　|∪|　　 |　　　 　　　 
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

R-TYPEの画面がおかしくなったクマー！！
ショットの代わりに、ロボットが飛んでクマー！！

Yレジスタの値がおかしいみたいなんですけど…
どうやってデバッグすればいいんでしょうか…

１．XPCEのデバッグモードを使う

XPCEをデバッグビルドすると、デバッグモードで起動することが昨日分かったんですけど、
それを使うと、レジスタの値を表示しながら、ステップ実行したりできるみたいです。

XPCEをステップ実行していって、Yレジスタがおかしくなったときに実行した命令を調べる、
なんていう地道な方法でやるしかないかもです。

２．コードにassertをはさむ

または、YレジスタをチェックするコードをCPUエミュレーションのループにはさんで、
0〜255の範囲外になったら、そこでブレークさせるみたいな。
assertみたいな方法でも調べられるかもしれません。

３．条件付きブレークポイントを使う

そういえば、条件付きブレークポイントというのもありましたね。
Visual C++ 6.0にもあったのかなーと思いつつ見てみたら、
どうやら使えるみたいです。
CPUエミュレーションのループの最後に、条件付きブレークポイントを仕掛けて、

R->Y < 0 || R->Y > 0xFF

という条件を設定します。
これで、Yレジスタが変になる命令を実行したタイミングでブレークするはずです。

４．ひたすらソースとにらめっこする

最終的には、臭いところをひたすら探すしかないかもです。

このバグを乗り越えたら、後はかなり楽な作業なはずなんですけどねー
C言語にあってJavaにない機能で書かれている部分を回避するように書き換えたわけで、
あとは簡単にJavaにもっていけるはずです。
残るのは、DoJaのクラスを使って、画面表示の転送を行うとか、そういう部分だけなはずです。

まあ、音源エミュレーションは難しい問題なんですけどね…
Ga氏のWSXサウンドエンジンの仕組みを真似してやってみるつもりです。
PCEの音源で、どれぐらい似た音を出せるかはやってみないとわかりません。
WSX2相当の方法で、音源エミュレーションの結果をADPCMで再生すれば、音色が違ってしまうという
問題はないはずですけど、重くなっちゃうでしょうし、悩みどころです。

はよ携帯実機でR-TYPEが動くところを見たいなー