前々から「とあるアダプタ」に付いている漢字ROMをひっぺがしてフォントデータを吸い出したいと思っていて、とあるアダプタ自体は手にしていたもののなかなかそこから先へ進むことはできず。そんな状況がもう何年も続いていたのですが、ネットの海を漂っているとデータを吸い出した方がいらっしゃるのを見つけました。
実機が手元にある以上そのデータを手にしても問題はなかろうということで、今回はそれを使って実験を行います。一応、グリフの一覧をきちんと並べた状態で眺めることができる程度までは、なんとか。
最初にデータを眺めた時は、グリフのかけらが何一つ見えず途方に暮れる状態でした。この手のROMはアドレス線の繋ぎ方に細工して吸い出し対策をすることもあるという話をどこかで聞いていたので、こんなコードを書いて並べ直してみました。CPU側のアドレスを[17:0]とするなら、ROM側は[0:17]に対応するようなものです。これでそれっぽくは見えているのですが…
グリフの並びがめちゃくちゃで、これをどう文字コードと対応付けるか再び途方に暮れることになりました。
一文字分のグリフをきちんと構成するためには、CPU側のアドレス[4:0]にROM側の[13:17]を対応付ける必要があります。残った部分でグリフの並びを決定しますから…CPU側の[17:5]をROM側の[0:12]に割り当てるのではダメなようなので、ROM側が[12:0]だったらどうなるかを試したところ、うまくいったという訳です。
自分自身が実際にチップから直接吸い出したデータで作業した訳ではないという注釈が必要になりますが、もし実際のROMがこのようなアドレス線の結線を必要とするのであれば、何故このような作りになっているのかという点に非常に興味があります。文字の並び（インデックス）とグリフのデータ（データ）を示すアドレス線の順番、おそらく自分の考える普通の技術者であればインデックスもデータもまとめてCPU側[17:0]→ROM側[0:17]にするものだと思います。[17:0]→[17:0]でないのはエンディアンの問題でしょうからそれは置いとくとして。
マスクROMの内容に問題があったと仮定しても、インデックスもしくはグリフのどこかのアドレス線が入れ替わる程度で、インデックスはインデックス、データはデータで綺麗に真逆になっているというのは…何らかの「意図」があるように感じてしまいます。
さて、基本的な調査は終わったので次はFONTX2化かと考えていたのですが、なんかあんまりやりたくないなーというのが正直なところです。半角の"＠"に"00"が割り当てられているのを見てしまうと、昔はともかく今の御時世でそれは許容できないかなって。56.5kg(20:45)
24-May-2023補足：Famicom Network System - NESdev Wikiを見るに（ってこれで何を対象に実験していたかバレてしまいますね）、おそらく$40b0にインデックスのbit[12]を書き込んだ後にインデックスのbit[11:0]＋$5000を32回読み出してグリフのデータを得る、そんな作りになっているようです。グリフ側のアドレスはRF5C66 Mapper and Disk Drive Controllerが握っているようなので、吸い出し対策というよりは単に「分担」の違いということになるのでしょう。
25-May-2023補足：半角の"＠"(0x40)→"00"の他、"＾"(0x5e)→"ガ"、"＿"(0x5f)→"ギ"、"‘"(0x60)→"百"、"｜"(0x7c)→"千"、"〜"(0x7e)→"グ"、(0x7f)→"ゲ"、(0xa0)→"ゴ"、"「"(0xa2)→"ザ"、"」"(0xa3)→"ジ"のグリフになっているため、半角の部分は変換してもそのままでは使い物にならない感じです（不足したグリフは適宜補う必要があります）。
29-May-2023補足：一応基板の所持証明ってことで、写真上げときますね。
ROM外してないのにデータ所持してんじゃねえ、っていうツッコミに対しては流石に効力無いですけど。
