日記みたいな何か

昨日の続きで、手持ちのビデオゲームタイトルの残りを一通り動かして、追加調査は終了となりました。やることは決まっていて、カートリッジの認識率もめちゃくちゃ高まっているので、まあそんなに大変じゃなかったんですが、調査結果自体はちょっと思っていたのと違っていて残念な感じｗ

加湿器を片付けるついでに、お子様がバッキリ折ってしまったヒンジ部分をプラリペアで修復してみました。意外といい感じに強度が出てくれています。よかった。

また手持ちのST-Vのビデオゲームタイトルを片っ端から引っ張り出してきて起動させて追加調査を実施したり。そろそろ期限が近づいているので焦るｗ

ファンキーヘッドボクサーズのテストモードを見ていたら、COMMUNICATIONなる設定があることに気が付きました。もしかしてマザーボード間を繋いで通信対戦する機能があったりするのかな・・・。

通信自体はおそらくCN18を使うんだと思うんですが、ソフトが1本しかないので試せないのが残念ｗ。ちなみに単独でCOMMUNICATIONをオンにしておくと、通信相手を待つためか、ゲームがまったく起動しなくなりますｗ

あと、他のゲームのテストモードをいじっていたら、マザーボード上のテストスイッチやサービススイッチが効かなくなるやつとか、異常に反応が悪くなるやつがあることも発見。上海 万里の長城、ぷよぷよSUN、ファインドラブがそんな感じでした。もちろんJAMMAの方から信号を入れる分には普通に反応するので、通常は問題にはならないですが、うちではST-VとかNAOMIはマザーボード側で操作することが多いのでちょっと焦りましたｗ

ふと気になることがあってコナミのSystem GVを開けて中の基板を確認してみたり。この忙しいときに何をやっているんだという感じですがｗ

連休に入ったので家の中の片付けに着手しました。で、そのうち捨てようと思ってまとめてあった漫画とかの収納用の袋の中に謎のUSBメモリが入っているのを発見 (※以下の写真は取り出した後に撮ったものなので「謎のUSBメモリ」は映っていません)

・・・と思ったら、USBメモリじゃなくてKOFスカイステージ (Type-X) のドングルでした (汗)

Type-X側に養生テープで貼り付けてあったんですが、剥がれ落ちてしまったようで、その際、当時基板の近くに置いてあったこの袋の中に入り込んでしまったようです。危ないところでした・・・。

先日水洗いしたプリクラVol.6冬のカートリッジを再度開ける機会があったので、ついでにテスターで確認してみたら、黒く変色してるところも全然断線していないことが判明しました。認識されないのは、エッジコネクタの表面が錆かなんかでスロットの端子と導通できていないからとかなのかも。

というわけで、端子の錆っぽいのを落としつつ、やや甘めにスロットに刺してやったら立ち上がるようになりました。

ついでにカートリッジのコネクタについても少し調査。なるほど、これはそういうことか・・・

何かiPadが充電中の状態で机の上から落ちたらしく、その際にLightningのケーブルの端子部分が折れてしまいました。

このiPad、10年以上前の機種なんですが、驚くべきことに未だに使っていたりするんですよね。というわけで、朝方AmazonでAnkerのLightningケーブルをポチったところ、夕方に到着しました。早いｗ

ST-Vのマザーボードのバスとか拡張コネクタまわりの配線を調べたりしていました。今まであんまり意識していませんでしたが、配線が内層に隠れているのが凄くいやですね・・・。

ST-Vの古い(?) マザーボードは4Mbit のBIOS ROMが27C4096系なんですね。で、BIOS ROMのソケットの横にあるジャンパは 2Mbit とか 1MbitのROMを装着するときに使うものみたいです。途中からそんなの必要ないと判断されたのか、ジャンパはなくなり、BIOS ROM自体も4MbitのマスクROMになったようですが。

あと、超どうでもいい話ですが、2個載ってるSH-2について、テスターで120番ピン (MD5) の接続先を確認した結果、角に近いところにあるやつがSlaveで、そうじゃない方がMasterということがわかりました (MD5がGNDに接続されている方がMaster) 。これで何かがあるわけでもないですが、ちょっとスッキリｗ

ST-Vの水滸演武、今まであんまりちゃんと動かしてなかったんですが、改めて見てみると背景が遠くの山とかまで含めた一枚絵みたいでちょっとびっくり。多重スクロールしないのね。BGの拡大縮小をやるとこうなっちゃうんでしたっけ。さすがにもっとできそうな気がするけど。

あと、水滸演武ではワイドモニタに設定できるんですね。変えてもよくわからん感じでしたが。環境側の問題かな。

ゲーメスト増刊のザ・ベストゲーム2を確認したら、初代スポーツフィッシングのことがちょっとだけ出ていました。

まあ (当時の) 最新のLDのゲームであるということだけですがｗ

というか、時期的にこれが国内のLDゲームの最終作品なのかも？調べてみたら、同年にタイトーも冒険王タップルというのを出していたみたいですが (IDYAなるコクピット筐体向け)、どっちが後だったんだろう。

ST-Vの麻雀ハーネス変換アダプタを発掘。

そしてプロ麻雀 極Sのマニュアルも発見。なるほど、ST-Vの麻雀ハーネスの接続はこうなっているのか。アダプタからひょろっと出ているケーブルの接続先はCN32ね (他に9ピンのコネクタはないので間違いようがないとは思うけどｗ)。

繋いでみて、プロ麻雀 極Sで無事ボタンが認識されることを確認。ついでに他のタイトルでの対応状況を確認してみましたが、バーチャル麻雀シリーズや団地で花札も同じ変換アダプタで大丈夫な模様。

ちなみに、ST-Vの多くのタイトルにはポーズ機能 (画面写真撮影などのため？) があって、押すとゲームの進行を止められるようになってるんですが (タイトルによっては有効化できない、非対応なものもあるっぽい) 、マイ・フェア・レディ (バーチャル麻雀2) だとデモ中にポーズを押しても上下にガタガタしてしまう問題がある模様。

そんなときに頼りになるのはやはりFramemeisterですね。静止ボタンを押すことで完全に止まります。まあ、マイ・フェア・レディのキャプチャをするつもりはないんですが・・・ｗ。この機能、RetroTINK 5X-Proにないのが残念。

おまけ。マニュアルを探していたら、バーチャファイターキッズのポスターが出てきました。これが普通の頭身のYet Another VF2.1 だったりしたら、少しだけ世界が変わっていたんじゃないかという気も。結末は変わらなかったにしても・・・。

お子様が急に熱を出してダウンしたりして何もできず。

またしてもサントリー生を箱買い。飽きずに飲めてしまう恐ろしいビールですｗ

特に目的があるわけでもないんですが、またいくつかST-Vのソフトを動かしたり。エランドールは普通に端子を掃除してもまったく認識されず、ガワから出して差し込みを調整したりして、やっとのことで認識されました。嫌な汗をかいたｗ

その後、さらに念入りに端子を掃除したら、ガワに入った状態でもちゃんと認識されるようになりました。ふぅ。

後は特に問題なく平和な感じ。

原稿をちょっと進めたくらい。頑張らねば。

ST-VのBIOSについて調べていたら、MAMEのソースに EPR-23603 なる2000年10月24日版のBIOS ROMがあるみたいなことが書かれていますね。この時期に新規に出てたとなると、くれよんキッズあたりのBIOSとかなのかな・・・？過去にオークションに出品されていたくれよんキッズのマザーボードの画像を見ると、確かにBIOS ROMがマスクROMじゃなくてシール付きのものになっているようですが。うーん。

前にeBayで買ったピカピカな AM27C400、見るからに怪しい感じですが、ちょっと実験で使おうと思って出してきたら、プログラマが「IDが合わない」といって弾いてきました。やはり怪しい品だったか・・・。

Xgproで読み出されたIDは 0x00C2 0xB800 らしいです。Manufature Codeが0xC2ってどこだと思って手持ちのデータシートをチェックしてみたところ、Macronixのものと判明。もしやこれは・・・とMX27C4100 のデータシートを見たら見事に 0x00C2 0xB800 の記載がｗ

さっそくIDをMX27C4100としてReadしてみたら成功しました。そのままプログラムもできました。なにこれ、やっぱりリマーク品ってことなの？ｗ

昨日水洗いしたプリクラ2 Vol.6 のカートリッジ、乾いたみたいです。でろでろしたのは落ちたけど、やはりパターンの変色が酷いですね。

動かしてみましたが認識されませんでした。残念。

腐食によって断線してる箇所が結構あると思われますが、まあ今は調べてる場合じゃないのでまたいずれｗ (追記: 後々確認したら、普通に端子の表面の接触が悪かっただけで、特に断線はありませんでした)

プリクラ2 Vol.6冬のカートリッジを開けてみたところ、めちゃくちゃ腐食気味なことが判明。

うちに来る前、長らく過酷な環境で保存されていたんですかね。

とりあえずいつもどおり食器用洗剤でじゃぶじゃぶ。

積極的に乾かしていきます。

続いて資料捜索。サービスマニュアル類をまとめた箱を漁っていたらST-Vのサービスマニュアルが出てきました。まったく記憶になかったｗ

あと、MAMEのソースを見ていたら、タタコットの基板は別の基板からROM載せ替えで作っているとの興味深い情報があったので確かめてみることに。

先日タタコットのカートリッジを開けたときの写真を確認してみます。このマスクROMに刻印された番号はバーチャファイターリミックスですねｗ

こちらはバーチャファイターリミックスのカートリッジの中身。表側のマスクROMは完全にタタコットのものと一致していますｗ

バーチャファイターリミックスの裏側にはマスクROMが実装されていません。

タタコットはここに必要なマスクROMを載せている模様。

ということは、タタコットのカートリッジ基板にバーチャファイターリミックスのUVEPROMを乗せれば、バーチャファイターリミックスが起動するのでは？というわけで、やってみました。

さてどうか。写真だとまったくわかりませんが、マザーボードに刺さっているのは、タタコットのROMボードにバーチャファイターリミックスのUVEPROMを移植したものになりますｗ

きた！バーチャファイターリミックスとして認識されました！ｗ

カバーをつけて改めて起動。普通にバーチャファイターリミックスが立ち上がりましたｗ

ちなみにタタコットの個体によってはベースが違うことがあるようです。うちのはバーチャファイターリミックスでしたが、MAMEののソースにあるやつはエジホン探偵事務所がベースだった模様。

ST-Vについて色々調べ直したり考察したり。

今日もST-Vのカートリッジを開けて中を見たりしています。花組対戦コラムスは、シールが二重になっていたり、マスクROMを貼り直した感じの跡があったりで、何か元々別タイトルだったのを再利用してる雰囲気ありますね。何だろう。

しかし見るのも面白いけどやっぱり動かしていかないと。

うっ、この時代の変わり目の難しさ感ｗ

ST-Vマザーを比較したくてあちこち漁ってみたところ、ジャンク箱の中から2枚発掘され ました。確かどっちも起動しなかったはず・・・と思って通電してみたら1枚目は普通に立ち上がりました。あれー、何だっけ。

ああ、ボリュームが取られていて音が出ないｗ

もう一枚は見た目こそまあまあキレイなものの、まったく起動しませんでした。雰囲気的に最初期のものかな (写真撮り忘れ)

ちなみにST-Vにはこんなデモ動画みたいなのが入ってたりするんですよね。カートリッジを刺さずに起動したりすると見ることができたりします。

深夜基板ミュージック pic.twitter.com/2Ytl4bTTlH

— のすけ (@konosuke) April 11, 2024

色々確認したくて、ひたすら手持ちのST-Vのカートリッジを開けて写真を撮ってます。色々興味深いけど数が数だけに大変ｗ

手持ちの基板リストのST-Vタイトルを確認していたら、バーチャル麻雀とサンドアールが見当たりません・・・。もしかして持ってない？いやいや、そんなわけないよね・・・というわけで棚を見に行ったらちゃんとありました。単なるリスト漏れでした。ふぅｗ

ついでに後で便利なように、発売時期順にソートしてみました。左下の方は未確認。

気がつけば、いわゆる国内で販売されたビデオゲームのカテゴリに属するものは、特殊筐体向けを含めて一通り揃っているのかも？もちろん、マジカル頭脳パワーとかスポーツフィッシング2みたいなやつは、カートリッジ以外が足りなくて動かせないですがｗ

今日はサターンをばらして基板を取り出してST-Vの基板と見比べたりしてましたｗ。いやー、ST-Vを見た後だと、サターンの基板の詰め込み具合が凄いｗ

ポーカーレディースを一旦片付けて、CPicS2の出荷準備した後、ST-Vのマザーボードを引っ張り出してきて色々と調べ物を開始。頑張らねば・・・。

ポーカーレディースの基板 (88124-A-2) 、KABUKIのクイズ系の基板 (89126-A-2) とそっくりなんですよね。ひょっとして互換性があるんじゃないかと思い、試しにクイズ三國志の基板に部品を載せてみることに。

まずはキャラクタデータまわりから。ポーカーレディースは4Mbit品のROMを使っているので、それが乗るようにクイズ三國志の基板の設定を変更します。デフォルトだと32pinソケットの30番ピン (4Mbit ROMではA17相当) がVCCに直結しているので、JP14・JP18のジャンパ (0Ω抵抗) を外します。

上記だけだと不十分で、JP16とJP20も外す必要があります (何で二重化されているのかは謎)。これでROMの30番ピンがVCCから切り離されました。

で、代わりにJP14・JP18の隣のJP15・JP19をジャンパさせることでROMの30番ピンに5Jの位置のPALの12番ピン出力 (A17のアドレス信号) が来るようになるんですが、いつでも戻せるようにしておきたいので、ここはソケット化した上でJP15とJP19をジャンパさせました (JP15・JP19をジャンパさせた状態の写真は撮り忘れ)

で、サウンドまわりのROM用のソケットを空きパターンに増設。

ROMとPALを移植して動かしてみます。

うおお、タイトルロゴが出た！しかし後ろがおかしいｗｗ。あと、タイトル画面が出た後、すぐにリセットかかってしまうようです。何だこれは

あ、そうか。キャラクタデータのROMの31番ピン (A18) の処理を直すのを忘れていました。31番ピンには5Jの位置のPALの13番ピンが配線されています。おそらくこの出力は、5JのPALのすぐ隣にあるJP17の有無で決まると思われます (ジャンパがあると5JのPALの6番ピンがLに落ちて、ジャンパがないとHになる)。

というわけで、このジャンパをポーカーレディースの基板と同様に外してみました。

これでタイトル画面が正常になりました。やった！ｗ

あとは、リセットですね。こちらは、もしやと思いMAMEでトレースを取ってみたところ、そのまさかで、0xE004番地に命令を置いて実行していることが判明。これ、スーパーパンと同じくSRAM上の命令を実行しているってことになりますね。というわけで、コンフィギュレーションの最後を 0xF0 0x00 にしてたのが問題だった模様。はー、だからKabuki Desuiciderのコンフィギュレーションではスーパーパン以外も 0x70 0x00 になってるやつがあるのか・・・。

CPicSKに書き込むコンフィギュレーション情報の末尾を0x70 0x00 に直したらリセットもかからなくなりました。スプライトが表示されるようになったことで急に華やかになりましたねｗ。本来こういう画面だったのかｗ

ちょっとCPicSKとかをいじったりしたくらいで特に面白い話もなく。

スーパーパンでのSRAM上のデータに対するエンコード方式について、スタックに読み書きしているエンコード済みのデータも含めてツールで絞り込んだところ、以下の通りと判明しました。

• エンコードは、ただのビットシャッフル
• ビットシャッフルのアルゴリズム自体はROM上のプログラムと共通
• シャッフル時のパラメータは命令 (オペコード) とそれ以外で共通
• ROM上のプログラムでは、アドレスとコンフィギュレーション情報の一部 (MAMEのコード (kabuki.cpp) でいうaddr_key) で決まっていたパラメータ (select) が固定値 (0xffc3) になる
• ROM上のプログラムではコンフィギュレーション情報の一部 (MAMEのコードでいうxor_key) が使われていたが、ここがゼロ固定になっている

デコード処理は、MAMEのコード (kabuki.cpp) のbytedecode関数を以下のように呼ぶイメージです。

        decode_buf[A] = bytedecode(src[A],swap_key1,swap_key2,0,0xffc3);

エンコード関数はMAMEにないけど、デコードと逆の順番でシャッフルするだけですね。

static int bitswap1x(int src,int key,uint16_t select)
{
        if (select & (1 << ((key >>12) & 7)))
                src = (src & 0x3f) | ((src & 0x40) << 1) | ((src & 0x80) >> 1);
        if (select & (1 << ((key >> 8) & 7)))
                src = (src & 0xcf) | ((src & 0x10) << 1) | ((src & 0x20) >> 1);
        if (select & (1 << ((key >> 4) & 7)))
                src = (src & 0xf3) | ((src & 0x04) << 1) | ((src & 0x08) >> 1);
        if (select & (1 << ((key >> 0) & 7)))
                src = (src & 0xfc) | ((src & 0x01) << 1) | ((src & 0x02) >> 1);

        return src;
}

static int bitswap2x(int src,int key,uint16_t select)
{
        if (select & (1 << ((key >> 0) & 7)))
                src = (src & 0x3f) | ((src & 0x40) << 1) | ((src & 0x80) >> 1);

        if (select & (1 << ((key >> 4) & 7)))
                src = (src & 0xcf) | ((src & 0x10) << 1) | ((src & 0x20) >> 1);

        if (select & (1 << ((key >> 8) & 7)))
                src = (src & 0xf3) | ((src & 0x04) << 1) | ((src & 0x08) >> 1);

        if (select & (1 << ((key >>12) & 7)))
                src = (src & 0xfc) | ((src & 0x01) << 1) | ((src & 0x02) >> 1);

        return src;
}


static int byteencode(int src,int swap_key1,int swap_key2,int xor_key,uint16_t select)
{
        src = bitswap1x(src,swap_key2 >> 16,select >> 8);
        src = ((src & 0xfe) >> 1) | ((src & 0x01) << 7);
        src = bitswap2x(src,swap_key2 & 0xffff,select >> 8);
        src = ((src & 0xfe) >> 1) | ((src & 0x01) << 7);
        src ^= xor_key;
        src = bitswap2x(src,swap_key1 >> 16,select & 0xff);
        src = ((src & 0xfe) >> 1) | ((src & 0x01) << 7);

        src = bitswap1x(src,swap_key1 & 0xffff,select & 0xff);

        return src;
}

...
        encode_buf[A] = byteencode(src[A],swap_key1,swap_key2,0,0xffc3);
...

結局、SRAMアクセス時のエンコードは8bit内のビットシャッフルでしかないので、0x00と0xFFを読み書きするときは必ずエンコード後も同じ値になります。だから最初のRAMチェックの処理では、エンコードが有効になっている状態でも生データと同じ値 (0x00 or 0xFF) が書かれていたんですね。

何か当初の目的を見失いかけていますが、これまでわかったコンフィギュレーション末尾のまとめ。

• コンフィギュレーションの末尾が 0x70 0x00 のときはSRAM上のデータがエンコードされた状態になるけど、SRAM上に置いたデータを命令列とみなして実行できる
• コンフィギュレーションの末尾が 0xF0 0x00 のときはSRAM上のデータが生データになるけど、SRAM上に置いた命令をそのまま実行することができない (間違った命令にデコードされちゃうからなのか、そもそもこの設定のときはSRAM上の命令の実行が禁止されているからなのかは不明だけど、おそらく後者だと思う)

こういう理由があって、SRAM上に置かれたコードを実行するタイトルについてはコンフィギュレーション情報の末尾を 0x70 0x00 にする必要があるということなんでしょうね。・・・ということは、もしかしてスーパーパン以外にもそういうやつがあったりするのかな。 (追記: 調べてみたら 麻雀学園2、ポーカーレディース、スーパー○禁版ではSRAM上のコードを実行することが判明しました)

スーパーパンでSRAMを読み書きする際のエンコード・デコード方式について考え続けています。EEPROMから読み出してきたものをデータとしてSRAMに書き出して、それを命令(オペコード)およびデータとして読み込むんだから、ROM上のプログラムと違い、オペコードとそれ以外とでエンコード方式は共通だと推測されます。

とりあえず既存のルーチンのまま、一部のパラメータを変えるとかしているものと推測し、ツールを作ってブルートフォースでそれらしき値を探すも、候補があり過ぎてなかなか絞り込めませんｗ。もうちょっと情報が必要そうですね。

昨日に続き、KABUKIのコンフィギュレーションの末尾を 0x70 0x00にした際に、0xFD10にロードした命令が読み出されるところをロジアナで確認したいんですが、こっちはSRAMに読み書きするデータがエンコードされた状態なので、どんな値にエンコードされているかがわからないとトリガを掛けることができません。

で、どうしたものかとちょっと考えて、M1を使うことを思いつきました。命令として読み込むときはここがLowになるはずなので、SRAMからReadしていて、なおかつM1が0のところ見れば、そこが 0xFD10からの読み出しとなるはずです。問題は信号が足りないという点ですが、今16bitアドレスの上位4bitを見ているところを上位3bitに減らして (0xE000〜0xEFFFには命令が置かれないはずなので)、最下位bitをM1に割りつければ行けるはず。

というわけで、観測してみたところ、見事にヒットしました (波形写真は撮り忘れｗ)。本来 0xCD 0x81 0x0Eという並びの命令は、SRAM上に 0x67 0x03 0x2c という並びで置かれているようです。見た感じ、ROM上のオペコードやデータに対するエンコードとは違うようですが、どうやってるんだろう。

スーパーパンを使ったKABUKIのコンフィギュレーションの末尾2Byteの調査を継続しています。スーパーパンは、EEPROMの中にちょっとだけ命令が入っていて、起動直後にこれをSRAM上の特定領域 (0xFD10) に読み出した後、起動処理の中でそこを一旦経由するという変な動きをします。コンフィギュレーションの末尾が 0x70 0x00 で起動して、0xF0 0x00 で起動しないのは、おそらく前者と後者でここの動きが変わってしまうからだと推測されます。後者の場合、画面に「RAM OK」と出たところでハングアップしたような状態になるんですが、MAMEで確認すると、ちょうどそのタイミングでSRAM上の命令にジャンプしているので間違いないでしょう。

というわけで、ここをロジアナで観測してみることに。ひとまず 0xF0 0x00 のときは生のデータがSRAMに書き出されているはずなので、EEPROMからコピーした命令をSRAMから読み出して実行するところを引っ掛ければよいのでは、と考えてSRAMから 0xCDを読み出すところを探してみました。アドレスを全ビット見られれば簡単なんですが、ロジアナのチャネルが少ないので、データ 8bitとアドレスの上位4bitだけを見ていますｗ

で、無事 0xCDを読んでいるところは見つけられたんですが、その後に 0x81 を読まずに SRAMに 0xFD 0x11を書いているようです。

0xFD 0x11 は0xFD10 の次なので、次に実行する命令のアドレスということになりそうです。これはつまり、0xCDをオペコードとして読み出して実行しようとしたところで、KABUKIが独自に持ってるメモリ保護の仕組みに引っかかってトラップか何かになったか、RST命令としてデコードされたとかで、割り込み処理ルーチンに飛ぼうとしてスタックポインタにアドレスを積もうとしている状況みたいな？ いずれにしても、やはりこの EEPROMからコピーしてきた0xFD10の命令を実行するところで止まっているのは間違いないようです。