現在は協力者にファミコンソフトを大量に借りて、 dump 機能の動作確認をしている. 意外とやることがおおく flash programming の機能修正ができていない.
設計初期から構想があった nametable control register によるカートリッジハードの検出を実装した. 個人的には優秀な機能だと思っているが欠点もいくつかある.
利点:
- わりと早い.
- nametable control で PPU A10,A11 の MUX を介さない TKSROM のような CHR ROM Address MSB を VRAM A10 に配線する variant の検出の信頼度がとても高い.
- ROM data を参照しないのでバージョン違いを誤認しない.
欠点:
- nametable control register がない CNROM, UNROM その他単純なハードの検出ができない.
- MMC1A を利用したハードでは backup RAM に write protect register がついていないので、この領域に nametable control register があるハード(Taito-Xxx ほか数種類)の検出でバックアップデータを消してしまう.
- VRC1-VRC2, X1-005-X1-017 のようにレジスタ仕様が全く同じだと別の異なる仕様を確認するがそれは ROM bank の違いぐらいなので、ROM data の内容によっては誤認する.
variant hardware の発生原因は大まかに2種類あり上記の nametable 制御と work RAM の容量の違いである. nametable 制御は先述のようにほぼ完璧に検出できる反面、 work RAM の容量とそれに派生する電池の有無の検出は実装しづらい. その理由は30年以上経過しているであろう電池が死んでいると検出を誤認する点である.
今回 +5V の電源スイッチは MCU の GPIO から操作できるので、一旦電源を止めてしばらく待って再度電源をいれてデータが残っていれば電池があると判別の実装は可能. また電池が生きていたとしてもセーブデータを誤って消すリスクがあるのでそれは問題となる.
以上の点からハードウェアの検出は ROM hash (dump 前例)を起因とするデータベースなんかつかわないと豪語しておきながら、電池の有無はデータベースを利用する実装にしてしまった.
