カートリッジが届きましたので簡単に調査しました。
バードウイーク
従来の CNROM スクリプトで読み出したデータは mapper #3 として動作可能。読み出した page は下記になっていました。
- page0, 1, 2: 0xff で埋まったデータ
- page 3: キャラクタデータ
CNROM の基板は同じなので Charcter ROM に CE2 がついた mask ROM がついているという予想は出来ていて、 74LS161 から出力される A14 か A13 どちらか無効になってミラーだと思ってました。見る感じ、 CE3 もあるんかこれ。
page 0,1,2 は 0xff で埋まったデータが ROM から出力された 0xff なのか、ROM は HiZ で、AVR 入力端子のプルアップが 0xff にしているかは判断できず... ファームウェアを書き換えてプルアップを停めれば事実がわかります。
バナナ
指示通り、レジスタに書く値の bit5:4 を 2'b01 にしないとキャラクタデータの出力が安定しませんでした。安定しない理由は基板をばらして配線をみないとわかんないですね。
このゲームは元からキャラクタデータを 2 page 使う仕様となっていて、page 別には下記のようになっています。
ROM データの出力はいいんですが、エミュレータでは mapper #3 なのか mapper #185 なのかがばらばらで、よくわかりません。
プロテクトには2種類ある
ハードウェアのプロテクトとソフトウェアのプロテクトがあります。
ハードウェアプロテクトその1
バナナにあるようにレジスタの data bit 5:4 とダイオードの関係です。これは前回の雑誌の記事にあるようなタコの吸い出し対策*1で、PC でデータを得られないようにする対策ですね。単純すぎてすぐわかりますけど。
ハードウェアプロテクトその2(?)
ROM アドレス(=レジスタアドレス)への write を行うと、 ROM への output enable が完全にデコードされてないので、 CPU と ROM から同時にデータがでて不安定になります。レジスタへ安定して書き込むのには、ROM の出力と CPU の出力がデータが一致する必要があります。
これはコストダウンの目的もあってプロテクトかどうかはちょっと怪しいので (?) を付けました。AVR から書くときはこれを無視してるんだけどなんで AVR のデータ出力が安定するんでしょうね。(いまさら)
ハードウェアプロテクトその3(?)
Charcter ROM はバンク切り替えをする必要がないデータサイズなのに、ちゃんとデコードしています。ちゃんとデコードをするなら普通は実ROMデータを先頭から置くのを、末尾に置くのはプロテクトの目的があるのかもしれません。
mapper3 なのか mapper185 なのか
10年前の定義では mapper 185 はダイオード設定があるか否かになっているみたいです。CNROM であるということもわかってないかも。
それに追従してダイオードの設定も対応していますが VirtuaNES のソースでは不完全でダイオードの方向というパラメータは ROM の CRC で見ているぽいです。もしかしたら、ROM data のミラーを発生させないと言うことに気づいてないかもしれない。
重要なのは Charcter ROM につながるアドレスバスがフルデコードかミラーで、ダイオードが対応する bit5:4 は無視しても動くと思うんですが... 曲者なのは配線自体はみんな同じだけど Charcter ROM に制御線が増えているかもしれないってところでしょうか。
単純にダイオードがついていて bit5:4 も対応するものを mapper 185 とした場合に、Chracter ROM の容量が 0x8000 byte のドラゴンクエストとかグラディウス(互換品でも提携してたっぽい)も入ってくるのもやっかい。
この論理だとバードウイークはダイオードがついてないので mapper 3 ということになります。うーん。
*1:データバスは8bit → タコの足は8本 → タコの口は吸いそうという言葉遊びから来ているっぽい
