CDROM画面で、RUNを押すと、ゲームは発送しない。画面が黒くなって、何も起こりません。
UperGrafxのlogfileを添付しました。
手元の動作と log の出力が異なります.
こちらでみる限りは FPGA 内蔵の MCU が暴走しているようです.
08> 000E88 0C の直後に MCU が暴走するので、そのコマンド発行時点でターミナルのキー入力待ち、その後 signaltap で PC を監視して、MCU が暴走する場所を特定する仕組みを作った.
このキー入力待ちを作った時点で MCU が暴走しなくなってしまった.
よってこのキー入力待ちの代わりに _delay_ms(200) を挿入したら起動するようになった.
引数は 100 では起動しない. 起動する 200 はハードウェアの都合で実際には 200 ms 以上で 400 ms ぐらいかけていると思われる.
MCU が暴走する理由は不明だが wait をいれると改善するというのはとても気持ち悪い.
挿入した wait 処理は seek time に相当する場所であるから、seek time の再現ができれば問題は起きないと思われる.
その反面 seek time をいれないと MCU が暴走するようなソフトの構造は重大な欠点であるが、現状追跡ができていない.
3点気になることを追加
- VCE register の VSync 設定
VSYNC CONFIG = 60.00Hz でもいったん画面が切れるので原因を調べたら、
こちらのファームウェアのバグがあり、scanline の本数にかかわらず MCU への割り込みがかかっていたので修正.
VSYNC CONFIG = ORIGINAL ではこの修正は影響しないので、大量に割り込みがかかる. Zerowing では同じ値を大量に書き込む対策をしたが、これはどうも scanline の本数が変わってから設定変更を何度もするらしく悪質.
このせいで頻繁な書き込みで MCU が暴走してしまうことがわかった.
この原因での MCU の暴走原因も特定できていないが、基板上の電力不足だと勝手に思っている.
- 内蔵システムカード
DS英雄伝説2同様、実システムカードのみ起動する.
これも原因不明だが、 MCU へ多重に割り込みがかかっているために、不安定になっている気がしてきた.
- seek time の 400 ms ぐらいの wait
上記2点の対策や周知をした上でも 400 ms ぐらいの seek time は必須で、MCU が暴走する.
<BTS:69>の内蔵システムカードの書き込み条件を改定したらこちらも内蔵システムカードで動いたようだ.
しかし MAME で address 0x90000-0xbffff の書き込みは確認できなかった. なお MAME は cmp 命令での読み込みは read watchpoint の対象外になっているようだ.
原因特定. VCE の HSync と VSync の取り込みが一時的に不安定になり、 scanline counter (display_y) が 263 以上をとってしまうことが原因.
frame buffer の address bit 17:11 は display_y の値をいれて、 vce_d を保存する. 通常 0 から 262 をとることと MCU の instructon RAM の容量不足解消のため、 scanline 384 からを instruction data 置き場として使用する.
メタルエンジェルでは 08> 000E88 -> 6280 のあとにおそらく VCE や VDC のレジスタを激しく操作するため、 display_y が 384 以上を経過してしまい、 instruction data が VCE data としてすべて上書きされる.
その後 SCSI のために MCU へ割り込みがかかり、消されてしまった address へ instruction data を取りに行きそれが正しくないので MCU が暴走する.
対策は video 側の frame buffer へ書き込むときに display_y が 263 以上の場合は 262 にすること (384 以上にしないこと)で解決.
#5 の VSync Frequency = ORIGINAL で大量に scanline の本数の変更の割り込みがかかっていた理由も 1 frame あたりの scanline の本数が 263 を超えていたための誤動作.
#7 の対策を別の場所に入れた。これで間違った MCU への割り込みの発生、instruction data を間違って消してしまう、2つの問題が起きないようになった.