日記みたいな何か

自作のキーチップクローンがChihiroで動かない問題、とりあえず応答が遅すぎるのが原因ではないかと考え、応答時間を改善する最適化に挑戦してみることにしました。で、まずはその下準備として、Arduino Unoのキーチップテスタに応答時間を計測・表示する機能を追加。さすがにちょっとコードを弄るたびに実機にPICを取り付けて、ロジアナで波形を観測するとかやってられないのでｗ

自作のキーチップクローンは現状、応答に6ミリ秒以上の時間を要するようです。一方、純正品は3ミリ秒台前半で応答しているので、自作の方を純正相当にするには、3ミリ秒ほど詰めなければなりません。

どこで時間を食っているのか、あちこちコメントアウトしたりして調べたところ、応答のパリティを計算するところで3ミリ秒くらいかかっていることがわかりました。なるほど、ここ、律儀に8bitのデータから1bitずつ取り出してXORして計算しているもんね・・・。

そこでパリティの計算をやめて、こんなテーブルを参照するように変更してみましたｗ。ビットシフトの時間も勿体ないので、最初から左に2bitシフトした値を格納してありますｗ

他の細かな最適化と合わせて適用した結果、応答時間が3.4ミリ秒台に短縮しましたｗ。凄い効果です。これで純正品とほぼ同等になったはず。

早速実機で試してみます。

ぐ、まだエラー26か・・・。

最適化の際に、クロックのデューティ比も1:1になるように調整してあり、純正とほぼ同じ周波数で応答するようにしたので、クロックも無関係と思われます。そうなると、あと要因として考えられそうなのは、応答のサイクル数の違いとか・・・？

キーチップは1Byteのデータを転送する際、これに1bitのパリティを付与した上で、3bit x3に分解し、3サイクルをかけて出力します。なので、8Byteの応答メッセージは24サイクルをかけて送付することになります・・・と考えていたんですが、実機で取得した純正品の波形をよく観察すると、実は応答メッセージには25サイクル目があるんですよね。これがなくてもNAOMIは普通に起動したので、ただのノイズだと思っていたんですが、もしかしたらChihiroはこれをちゃんとチェックしているのかも？

というわけで、応答時に、最後に1回余計にトグルするように挙動を修正してみました。さあどうだ・・・

おおお、エラー26じゃなくなって、ロードが始まったぞ！

やった！起動した！

というわけで、自作のキーチップクローンでChihiroがエラー26で起動しなかったのは、応答の最後にダミーのサイクルがなかったからだったようです。NAOMIのDIMMモジュールは、この辺を細かく見ていないんでしょうね。

・・・ん、ひょっとして、応答時間は関係なかったｗ？ 気になるので、後で調べてみますｗ (追記: ダミーのサイクルを追加した状態で応答時間を伸ばす実験をしてみたところ、エラー26で再び起動しなくなりました。応答時間も関係していたようです)

手元にある謎のキーチップの中身らしきPICをかき集めて、Arduino Unoのキーチップテスタで中身を読んで整理してみましたｗ。結構あるなｗ

続いて、自作のキーチップクローンがChihiroで動くかどうかの実験。

う、エラー26で立ち上がりませんでした。うーん、何でだろう。

ロジアナで波形を取って見てみます。

純正の波形はこんな感じです。NAOMIとかでよく見たのと同じ感じですね。左下の帯と帯の隙間が、キーチップ側が応答に要する時間で、帯は、両端を除くと、キーチップ側の応答と、それを受けてのChihiro側から出てきた次のメッセージのセットになっています。

一方で、自作のキーチップクローンの波形はこんな感じ。Chihiro側から出た最初のメッセージにキーチップ側が応答しています。ただ、その次のメッセージがChihiro側から出ていないようです。

メッセージが来てから応答が出るまでの隙間が、オリジナルと比べるとだいぶ大きいけど、これのせいでChihiro側がタイムアウトしたりしているのか？あるいは、応答の波形のクロックが遅くて、デューティ比が2:1になっているのが良くない？

Arduino Unoのキーチップテスタで読み出したキー情報を手入力でPC側に取り込むのが面倒だったので、Arduino Unoからシリアル出力してみることに。が、シリアル出力を有効化したら急にキーチップに正しくアクセスできない状態になってしまいました。うむむ？

あ、シリアル出力をUSB側に出す場合であっても、Digital pin 0 (PD0) とDigital pin 1 (PD1) は空けておかないとだめなのかも？ 現状、PD0とPD1をキーチップを叩くのに使ってしまっていました。

というわけで、PD0とPD1を使わないようにピンの接続位置をずらし、Arduino Unoのコードも修正。速度を出すためにPORTBやPORTDを直接叩いているので、単純にdefineをいじっておしまいにできないところがちょっと面倒ですね。

無事にArduinoのIDEのシリアルモニタに読み出した内容が出力されるようになりました。これは便利・・・と思いきや、何かArduinoのIDEのシリアルモニタの使い勝手がイマイチな感じで微妙かもｗ

Arduino Unoのキーチップテスタでキーチップのキーを読み出して、出てきた情報をPC側に手入力で記録した後、念のためこの情報でググると既知のキーチップの情報をまとめていると思しきサイトがヒットするんですよね。

これが出てくるということは、正しく読み出せていて、さらにそれを正しくPC側に手入力で書き写せているということを意味するわけですが、その一方で、こうも網羅されていると、一体何のためにキーチップを読み出しているんだという複雑な気分になります・・・ｗ

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

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

— fujikko (@fujikko_alpha) May 27, 2025

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

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

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

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