日記みたいな何か

ふじっこさんがRGB2C02N搭載ファミコンでアルマジロの映像がおかしくなるとお困りの模様。

現象としては実機ではアクションシーンの下半分が表示されないって状況です(動画20秒以降)。同じROMをレトロフリークで読ませて実行すると問題なしなのでROMの故障とかではなさそう。そもそもこんなクリティカルにコード化けとかしないかと。 pic.twitter.com/j8cudJN4VI

— fujikko (@fujikko_alpha) May 27, 2025

アルマジロは現物が手元にあるので、RGB2C02N 搭載機で試してみることに。先日ラベルを貼ったお陰で、ものすごい速さでカセットにたどり着くことができましたｗ

動かしてみましたが、映像自体がおかしくなるようなことはありませんでした。ゲーム自体は操作にクセがあってしんどいところがありますがｗ。ワリオの森と同様に、ファームウェアアップデートで解消する問題なのかもしれませんね。

ファームウェア更新済みのRGB2C02N+ニューファミコンです。アクションシーンも画面下半分が普通に表示されているように見えますがどうでしょう pic.twitter.com/tpmq8qoQvi

— のすけ (@konosuke) May 27, 2025

昨日エラー24で動かなかった自作のキーチップクローン、PICのプログラムの問題を手直ししたところ、動くようになりました。

昨日動かなかったのは、信号の取り込み処理の高速化のために、取り込みのループで行わないようにしたAND演算を、ループの外で実施するのを忘れていたからでしたｗ。残念な理由だｗ

下邳の戦いで呂布を回復無しで撃破し、ついに赤兎馬をゲットすることに成功。一体何回リトライしたことかｗ。最後の最後で相手が覚醒したところで、こちらも覚醒して残り体力を削り取るのがポイントでした。

昨日、Arduino Uno側でNAOMIのキーチップを叩けなかった問題ですが、落ち着いて調べた結果、酷い初歩的なミスをしていたことが発覚。まず、キーチップのPICは、外部からクロックを供給する必要があるのに、それをやっていませんでした。なぜか内蔵オシレータのクロックで動いているものと思い込んでいました（汗）。また、MCLREが有効になっているのに、4番ピンをHighにしていませんでした。多分これをやらないとリセットが解除されないはずです。

というわけでPICに4MHzのクロックを入れるようにして、4番ピン (MCLR) をプルアップしてみました。これでどうだ。

お、Arduino Unoからのメッセージに純正キーチップのPIC が応答するようになりました。

しかし、この応答に、今度はArduino Unoの方が反応してくれません。何かArduino Uno側が、PIC側のクロックのトグルをちゃんと拾えていないような・・・。で、調べてみると、トグルの検知や値の読み込みに利用しているdigitalReadという関数が激遅との情報が出てきました。そして早くしたかったら直接レジスタを操作すると良いとのこと。なるほどねー。

digitalReadを使うのをやめて、直接レジスタを読むように書き換えたところ、メッセージと応答のやり取りが進むようになり、ついに純正キーチップの情報の読み出しに成功しました。やった。これでようやく自作キーチップクローンのデバッグが進むｗ

早速Arduino Unoに自作のキーチップのクローンを読ませてみたところ、こちらは失敗。波形を見ると、何かやり取りをしているように見えなくもないですが、変ですね・・・。

これはもしや・・・と、試しにArduino Uno側のクロックのトグルを遅くしてみたら、PIC側が正しく反応するようになりました。これはつまり、PIC側が遅くて、クロックの読み取りに失敗している可能性が高そうですｗ

ソースを見返してみると、PIC側でクロックを検知してレジスタの値を読み込む部分のループカウンタが無駄にintになっていたので、これをcharにし、さらにレジスタから読み出した値に7をANDして、下位3bitのみをメモリに保存する処理を、ループの外で行うようにしたところ、Arduino Uno側を遅くしなくても応答が返るようになりました。読み出せた情報も正しそうです。

では再度実機で動かしてみます。

う、だめか。しかし前回はエラー26だったのが、今回はエラー24に変わりましたｗ

波形を見ると、それなりにやり取りをしているように見えるんですが。うーん、何がだめなんだろう。

任天堂での多言語版も注文完了。後は発売日を座して待つのみです。

NAOMIのキーチップクローン、デバッグに便利そうな気がしたので、PIC向けに書いたコードをArduino Unoに移植して、Arduino Uno側でDIMMモジュール側の挙動を模擬できるようにしてみました。

早速Arduino Unoに純正のキーチップをつないで波形を観測してみます。うーん、それっぽい信号がArduino Unoから出ているようですが、PIC側が応答しませんね。何でだろう。 (追記: 実はPICが内蔵のオシレータで動いているというとんでもない勘違いをしていました・・・。外からクロックの供給が必要だったんですね。あと、オリジナルのPICはMCLREがセットされているので、ちゃんとMCLRをHighにする制御も必要でした)

一旦Arduino Unoからの認識は諦めて、作ったクローンの方をNAOMIの実機に刺してみました。が、こっちはエラー26。やっぱりデバッグしないとだめかｗ

ちなみに、作業をしていて気づいたんですが、コンパイラが生成したPIC16F628A向けのhexファイルをTL866CSでPICに書き込んでVerifyすると、configが不一致エラーになってしまうようです。

どうもコンパイラが生成したhexファイルだとconfigの値が0xFF82になっているのに対し、PIC側から読み出される値が 0x3F82 になっているせいで、不一致を起こしているようです。上位2bitの部分は実機に存在しないbitなので、MiniPro側で無視してほしいんですが・・・。Cのコードでconfigの値を直接指定する方法とかあるのかな。

ビックカメラでの購入手続きを完了させました。2台目確保です。任天堂の方は周辺機器をどうするか、もうちょっと考えてから・・・。

NAOMIのキーチップのクローン、いきなり実機でデバッグするのは大変そうなので、まずはCで実装したPICのコードのコア部分をLinux上で動かせるようにして、5年くらい前にロジアナで取り込んだNAOMIのPICの波形データをテストベクタとして食わせてみました。

その結果、PIC側の応答の一部のパリティが一致しないという結果に。非常に悩んだんですが、実はおかしいのは実機側のデータでした。どうやら、PIC側から出る8Byteの応答の最後の1Byteには、パリティが正しくついていないっぽいです。意図的にやっているのか、あるいはPIC側のバグなのか・・・。後者だとすると、実はNAOMIのDIMMモジュールはパリティをちゃんとチェックしていない・・・？