日記みたいな何か

今日から長岡です。午前中に出て、明るいうちに無事到着することができました。都内を抜けるのに2時間もかかりましたが、前回のようなひどいアクシデントに見舞われるようなこともなく何よりな感じ。

会社に行ったら津波警報の影響で電車が止まりまくって帰宅時に割とピンチな感じだったんですが、横須賀線が部分的に動いてくれていたお陰で、ちょっと時間はかかったものの、大混雑に巻き込まれたりすることもなく無事に帰宅できました。いやー、焦った。

AliExpressで注文していた、配線済みのPHDR-10VSコネクタが届きました。

これをATOMISWAVEのステレオケーブルの作成に使います。とりあえずちゃんと刺さることが確認できて一安心ｗ

10ピン全部に配線されていますが、使うのはSP+/SP- 2ch分の合計4ピンだけなんですよね。使わない分はもったいないけど抜いておく感じかな。

コツコツ進めていた手持ちのN64のソフト約130タイトルのダンプが完了しました。確認した範囲では、特別珍しいものはなかったですｗ

また今年もリビングのエアコンで水漏れが発生 (泣)。今回は単なる (?) ドレンホースの詰まりだったようで、外から吸ったらものすごい勢いで水が流れ出ました。やばい故障とかでなくて良かった・・・。

なぜかまたSystemSPを買ってしまいました・・・

今回はぶろっくぴーぽーです。

まあ、普通に立ち上がるわけがないですよねｗ。デモモードとかないかなぁ。

2台ある670-14071Eのうち、片方を分解してメイン基板を取り出しました。

目当てはこちらのBIOS ROM (MPR-21931-X2)です。

剥がしました。

同様に、先日分解した 670-14071G (MIl-CD非対応本体) のメイン基板のBIOS ROM (MPR-23588-X2) も取り外し。

せっかくなのでダンプしておきますｗ

で、670-14071GのBIOS ROMの跡地に、MPR-21931-X2を貼ってみました。予想通りなら、これで607-14071GでもMIL CDが動くようになるはずです。

組み立てて通電。

ひとまず普通に立ち上がりました。まずは一安心です。

GD-ROMのゲームも問題なく立ち上がりました。

それではいよいよMIL CDを・・・。

起動した！

というわけで、MIL CD非対応の本体 (670-14071G) であっても、単にBIOS ROMを貼り替えるだけでMIL CD対応にできることが確認できました。MIL CDの起動を防ぐために、ハード的にも対策が入っていて、海外で出回っているリージョンフリーBIOSでは、その辺をうまく回避したりしている可能性もあるかと思っていたんですが、考え過ぎだったようですｗ

ついでに、VA2.1基板搭載機 (670-14071F) もばらしてメイン基板を観察したりしてみました。

ちゃんと基板に「VA2.1」と書かれています。

VA2.1基板搭載機は、GDドライブ側の基板の機能がメイン基板側に統合されているという認識なんですが、BIOSは VA1のMIL CD対応機種と同じ MPR-21931-X2なんですね。

VA2.1基板の全体像はこんな感じ。

670-14071Fの本体裏ラベルです。バーコード下の数字の3桁目が1なので、一般的に知られている解釈が正しいのであれば、本体の製造 (出荷？) は 2001年ということになりますね。

670-14071FはMIL CD対応モデルですが、MIL CDが使えない 670-14071G のバーコード下の数字の3桁目は0でした。つまり2000年に製造された本体ということになります。流れ的には、VA1基板の機種の最後で一旦封印されたMIL CDが、その後、コストダウンを図ったVA2.1基板搭載品で再度使えるようになった、ということになるんですかね。

型番 (670-14071Fとか) の最後のアルファベットが、製造時期順に並べた場合に E → G → Fという順番になっていることを考えると、本来 VA1基板搭載機の670-14071Eの次に、VA2.1基板に切り替えた670-14071Fを出荷する予定だったけど、MIL CDによる不正コピー等を問題視して、急遽残っていたVA1基板にコピー対策を施したBIOSを搭載した 670-14071G を投入。が、その直後に、セガの家庭用ゲーム機ハード撤退発が決定し、不正コピー対策にコストをかけるのをやめにして、残っていた 670-14071F をそのまま放出した、みたいな流れだったりするのかな。ふーむ。

ドリキャスのGD-ROMの高密度領域に複数トラックが記録されているタイプのダンプで、最後のデータトラックの直前の2秒の空白部分の最初の2セクタをうまく読み出せない問題に関して、開始セクタによって中身が変わることをツイートしたら、ランダムっぽいデータになっているのはスクランブルが解けていないからではないかとのご指摘を頂きました。

あまり詳しくないですが

音楽～データ部分のGAP、「音楽1秒 + データ2秒」のように形式が混在している事が吸い出しの問題となっているのだと思います。

GAPデータ普通は空っぽだと思うので、上の形式(内容部分は"00"埋め)で自作しても大丈夫なはず。

— (-_+) (@_nega_posi_) July 25, 2025

吸い出す場合は

>最初の方のセクタがエラー
データモード?で読んだ為、音楽部分がエラー?
・音楽、データ部分を別々に吸い出す

>もう少し手前から読み～ジャンクデータ
音楽モード?で読んだ為、データ部分がスクランブル状態
・データ部分を切り出し、ツールでスクランブル解除

とかで

— (-_+) (@_nega_posi_) July 25, 2025

スクランブル解除https://t.co/Ud7i0lGDIw
MyStupidPrograms > unScramble.exe

昔PCエンジンを手動で吸い出してた時なんかに使ってました。
他にもツールあるのかな、今どうなってんだろう。

— (-_+) (@_nega_posi_) July 25, 2025

うおお、CD-ROMのデータトラックって、元々スクランブルがかかっているのか！調べてみたら、ECMA-130なんていうので定義されていたりするんですね。これは知らなかった。

早速ダンプ済みのスターグラディエイター2のデータに対して、教えていただいたツールを適用してみたところ、ランダムっぽかった中身が綺麗なデータに！

調べてみると、最初の 12Byte (00 FF FF FF FF FF FF FF FF FF FF 00) の部分が同期部分で、その後の3Byte (A3 01 40) がそのセクタのアドレスを時刻 (分、秒、フレーム) の模様。数字はBCD形式とのことですが、分の部分が 0xA3と、BCDじゃない数値になっちゃっています。これは多分、GD-ROMだとCD-ROMと違って99分を超えちゃうので仕方なく拡張したものと推測ｗ。なので、0xA3は103分かな。計算してみると、103 * 60 * 75 + 1 * 75 + 40 = 463,615 となり、まさに最後のデータトラックの2秒手前の最初のセクタ番号と一致しますね。

次のセクタ 463,616も正しくスクランブル解除できているようだったので、これらをダンプ済みのデータと合成してみたところ、ついに最後のデータトラックのSHA1が redump.orgのデータベースと一致するようになりました。やった！ありがとうございます！いやしかし、ほんと解決するとは思いませんでしたｗ。SNS凄すぎるｗ

その後、調べたら、スクランブルのアルゴリズムとかも見つかったので、Cで再実装してみました。これでLinux上で、httpd-ackを利用したダンプ結果のredump.org互換形式への変換を自動化できそうです。

訂正不能エラーが出て末尾の3トラック (トラック13〜15) がダンプできないトイ・レンジャーです。

セガラリー2のような目立つ傷は見当たらなかったんですが、よく見ると、数ミリ程度のやや深めの傷が回転方向に・・・。場所的にも、エラーが出るあたりと一致してそうな気が。これなのか？

ダメ元で手研磨してみました。

結果は・・・成功！ トラック13からトラック15まで、エラー無しでダンプできるようになりました。やった。

先日手に入れたSuper Major Leagueのカートリッジを開けてみました。

中の基板は裏までマスクROMがぎっしりです。・・・あれ、そんなにROMが載ってるタイトルじゃないよね・・・？

よく見たら、裏側のROMは、手作業で貼ったような雰囲気が・・・。

あ！表側にあるMPR-19745〜MPR-19750って、バーチャファイターリミックスのマスクROMじゃんｗ。バーチャファイターリミックスの基板と並べてみるとこの通りｗ。下がSuper Major Leagueの基板です。

タタコットと同様に、余っていた基板を再利用したパターンと推測されます。 ということは、UVEPROMを交換するだけで、Super Major Leagueのカートリッジでバーチャファイターリミックスが立ち上がるはずｗ。というわけでやってみました。

きた！Super Major Leagueのカートリッジ基板でバーチャファイターリミックスが立ち上がりましたｗ。公式2 in 1、お得ですねｗ

Windows PC上で手持ちのN64のソフトのダンプを始めたんですが、カートリッジの差し替えがだいぶしんどいことがわかってきました。一旦ダンパーのドライブをアンマウントして、USBケーブルを抜いた上でカートリッジを交換し、再度USBケーブルでPCに接続するみたいな。ケーブルの抜き差しのところは物理的なスイッチのついたUSBハブのオフ・オンで済むんですが、アンマウントがマウス操作を必要としてとにかく面倒くさい感じです (アンマウントせずに、いきなりUSBケーブル抜き差ししても良いのかもしれませんが・・・)

何とかここを楽にできないものかと思って調べてみたら、PowerShellで簡単に制御できる模様。今回のダンパーであれば、以下のようにすることでアンマウントできることがわかりました。こりゃ楽ちんです。

pnputil /remove-device "USB\VID_CAFE&PID_4003\123456789012"

そして、以下のようにしてPowerShellごと呼び出すことで、MSYS2上のシェルスクリプトからも利用できました。素晴らしい。

powershell -Command "pnputil /remove-device \"USB\VID_CAFE&PID_4003\123456789012\""

これで カートリッジをダンパーに装着 → USBハブのスイッチをオン → シェルスクリプト実行 (マウントされたドライブからROMの中身をコピーしてアンマウント) → USBハブのスイッチをオフ → カートリッジを取り外し・・・という流れでガンガン回せるようになり、劇的に効率が改善しましたｗ

こうなると、次にしんどいのはカートリッジの端子の清掃ということになるんですが、こればかり手作業で頑張るしかないですねｗ

今日の15kHz調査。まだやってますｗ。KOF '99 Evolutionです。

15kHzはRGB1・RGB2ともに240pで立ち上がりました。こうでなくちゃねー。

VGAは非対応ですね。ストIII 3rdみたいな裏技ではなく、15kHzで普通に240pで立ち上がるゲームで、なおかつVGA対応のものはあるのかな。

先日ゲットした 670-14071G (MIL CD非対応本体) をばらして、メインボードにアクセスできる状態にしてみました。何気にドリキャス本体をここまで開けたのは初めてかもしれませんｗ

基板はちゃんとVA1です。

BIOS ROMはMPR-23588-X2という型番のものでした。同じVA1基板を使っている670-14071Eとは、まずここが違うっぽいんですよね。

あと、ダンプした結果を、なんとかしてredump.orgの結果と合わせられないかと思い、ポチってみたSDカードアダプタが届きました。redump.orgのWikiの、SDカードを使ったGD-ROMのダンプの説明のところに、気になることが書いてあったんで・・・。

If the HD area has more than one track, the tracks will need to be properly split to conform to Redump standards (Fireball knows hows to do this).

というか、何の説明もなくDreamShellのCDが付属しているんですが、これは・・・ｗ。しかもレーベル面に「CD-R」って書いてあるのにプレスCDっぽいしｗ

せっかくなのでDreamShellを試してみることに。SDカードに最新のDreamShell (4.0.2) を持ってきて起動させてみました。

おおー、立ち上がった。

試しにスターグラディエイター2を読んでみます。いやしかし、何でNAOMIのGDドライブの写真が使われているんだ、これ・・・

げ、トラック4に入ったところで止まるぞ。スターグラディエイター2はトラック66まであるんですが・・・ｗ

2回試して2度ともだめだったので、DreamShellのバージョンを4.0.0に落としてみました。

4.0.0だとトラック4以降も含め、全トラックをダンプできました。4.0.2はバグありなのかな？

ダンプした結果は、トラックごとにISO形式になっているっぽいですね。圧縮されてるのかな。展開の仕方がよくわからんので終了ｗ

では、本命のSD Rip 1.1の方を試してみます。redump.orgのWikiにも、これを使うと書かれていたので。

こっちは無圧縮のバイナリで保存することもできるようですが、ダンプする範囲をセクタレベルで細かく指定することはできないようですね。普通にhttpd-ackと同じ範囲しか取ってくれないっぽいなぁ。本当にこれで取った結果を切り貼りして何とかなるのか？うーん・・・

途中のトラック14と最後のトラック23で訂正不能エラーが出まくってダンプに失敗するセガラリー2のGD-ROMの盤面を手研磨してみました。

延べ2時間ほど頑張った結果、同心円状の傷はかなり薄くなりました。

トラック23はエラーが出るものの、リトライで乗り切ってどうにか完走。これでもまだエラーゼロにできないとは・・・。

一方、トラック14の方はエラーが解消しました。やった。

まあしかし、ダンプができたとはいえ、できることならエラーを完全に取り切りたいところではあります。とはいえ、またここから頑張るのもなかなか辛いところ。うーん、これはもう思い切って研磨機を買うべきなのか・・・ｗ

ちょっと確認したいことがあり、MIL CD非対応のドリキャス本体 (670-14071G) を買ってみました。

商品説明にあった通り、GD-ROMのメディアすら読み込まない状態でした。「ゲームディスクを入れてください。」と表示されます。

試しにレンズの部分をIPAで掃除してみたところ、綿棒の先が茶色にｗ

これはいけるんじゃないかと再度チャレンジしたところ、バッチリGD-ROMのゲームが立ち上がるようになりました。やった！単にレンズが汚れていただけだったのねｗ

では本番。MIL CDのメディアを入れてみます。するとレンズを掃除する前と同じ「ゲームディスクを入れてください。」の表示にｗ。MIL CD非対応の本体だとこうなるんですな。なるほど。

ちなみに何となく開けてみたら電池がやばいことが判明ｗ

液漏れしたのが飛び散って、金属部分も一部錆びかけてるように見えますね。どうせ寿命が尽きてて充電されないだろうから、さっさと外そう・・・。

GD側の領域にオーディオトラックがあるタイプのGD-ROMに関して、httpd-ackでダンプした最後のデータトラックのSHA1をredump.orgのデータベースと合致させるためには、最後のデータトラックの直前の150セクタを読み出す必要があると見て、手動でセクタを指定して読み出しに挑戦してみました。一つ手前のトラック65の最後のセクタは 463,614 なので、463,615からの150セクタをダンプできれば補完できるはず。

ひとまずセクタ 463,615 から75セクタ分を読んでみたところ、いきなり1セクタ目でエラーが出てFailに。ぐはぁ

1つ手前のセクタ 463,614 から読み始めると、なぜかセクタ463,615を含めてエラーが出ることなく、セクタ 463,689まで読めました。

中身的には、最初の方がゼロで、途中からしばらく、ランダムっぽいデータが続く感じです。ランダムっぽいデータが続く範囲は、だいたい64セクタ分ですね。readオプションで指定しているセクタ数分がランダムになっている？

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001410  00 00 00 00 00 ff ff ff  ff ff ff ff ff ff ff 00  |................|
00001420  a2 81 40 61 00 28 00 1e  80 08 60 06 a8 02 fe 81  |..@a.(....`.....|
00001430  80 60 60 28 28 1e 9e 88  68 66 ae aa fc 7f 01 e0  |.``((...hf......|
00001440  00 48 00 36 80 16 e0 0e  c8 04 56 83 7e e1 e0 48  |.H.6......V.~..H|
00001450  48 36 b6 96 f6 ee c6 cc  52 d5 fd 9f 01 a8 00 7e  |H6......R......~|
...
00024be0  0f 2b 44 1f 73 48 25 f6  9b 06 eb 42 cf 71 94 24  |.+D.sH%....B.q.$|
00024bf0  6f 5b 6c 3b 6d d3 6d 9d  ed a9 8d be e5 b0 4b 34  |o[l;m.m.......K4|
00024c00  00 ff ff ff ff ff ff ff  ff ff ff 00 a3 02 28 01  |..............(.|
00024c10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00025410  ec 3d 8d 12 00 00 00 00  00 00 00 00 c2 f7 30 f5  |.=............0.|
00025420  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
...

逆に1つ後のセクタ463,616から読み始めると、463,615から読んだときと同様に1セクタ目でエラーになりました。

さらに開始セクタを1セクタ進めたセクタ 463,617 にすると、エラーが出なくなりました。

セクタ 436,617 からのダンプ結果を見ると、それっぽいデータフレームが続いている感じです。同じ範囲をダンプしたはずですが、先程 463,614セクタから読み始めたものと全然違いますね。雰囲気的に、こっちの方が正しく読めてそうな感じです。うーん、そうなると、あとはセクタ 463,615とセクタ463,616 の2セクタさえ読み出すことさえできれば、redump.orgのデータが再現可能になる？というか、何でこうも結果が変わるのか・・・。

00000000  00 ff ff ff ff ff ff ff  ff ff ff 00 a3 01 42 01  |..............B.|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000810  a1 0f 0c 61 00 00 00 00  00 00 00 00 c2 f5 7c f5  |...a..........|.|
00000820  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000860  00 00 00 00 00 00 fe 11  14 a3 00 00 00 00 00 00  |................|
00000870  00 00 61 f4 3e f4 00 00  00 00 00 00 00 00 00 00  |..a.>...........|
...

試しにVA2.1基板の本体やVA0基板の本体でもダンプしてみましたが、特に結果は変わりませんでした。ただ、VA0基板の本体は、ヤマハのドライブを搭載しているからか (今回試した他の本体はどれもサムスンのドライブ)、先日教えて頂いたオーディオリード時のオフセットが 2,788 Byteではなく 2,336 Byteになっていました。トラック2をダンプするとこんな感じになります。なるほどね・・・。

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000920  18 00 18 00 12 00 12 00  09 00 09 00 07 00 07 00  |................|
00000930  04 00 04 00 09 00 09 00  02 00 02 00 01 00 01 00  |................|
00000940  05 00 05 00 ff ff ff ff  fe ff fe ff 04 00 04 00  |................|
00000950  08 00 08 00 13 00 13 00  13 00 13 00 0b 00 0b 00  |................|

ちなみに昨日接着剤を塗布してみたデミロのAV端子は、いい感じに固まってくれたようです。本体を交換する際に何度か抜き差しをしましたが、バラバラになるようなことは一切ありませんでした。良かった良かった。

先日、固まって開かなくなってしまった光で固まるアロンアルファ、横穴から漏れ出た分を使ったわけですが、その後、ボトルガムの容器に入れてしまっておいたら、キャップや発光器が白化してました・・・。何かもう辛いので、諦めて捨てます。はぁ、勿体ないことをした。

去年、ゲームラボにST-Vの記事を書いたときからずっと気になっていたST-VのSuper Major Leagueをゲットしました。動作未確認品らしいのでドキドキですｗ

しっかり清掃した上で、北米BIOS搭載マザーに装着して電源オンしたところ、無事起動しました。やった！

まあ、中身的にはファイナルアーチの北米版なんですけどねｗ

デミロに取り付けたAV端子のコネクタ部分が抜き差しの際にばらばらになるのを防ぐべく、コニシのボンド ウルトラ多用途SU を買ってきました。早速、コネクタの金属部分とカバーの間や、カバー同士の接合面に塗布。頼むぞ・・・。

また、もはや15kHzの調査は完結した感じですが、スターグラディエイター2を新たにゲットしたので、対応状況を確認してみました。

こちらはRGB1とRGB2のどちらに設定しても240pで立ち上がりますね。VGA非対応なので、完全にジョジョと同じパターン。

で、ここからが今日の本題です。先日ゲットしたバンガイオーの中身が、本当に製品版と一致しているのかどうか知りたいというところから、GDパートにオーディオトラックが含まれるタイトルの場合に、httpd-ackでダンプした結果のチェックサムがredump.orgのデータベースとほとんど合わないのはなぜなのかという疑問に発展し、気になって色々調べてみました。

いきなり不確定要素のあるバンガイオーでやると、何が正しいのか混乱しそうなので、まずは、バンガイオーと同様にGDパートにオーディオトラックを含むスターグラディエイター2を調査に使うことにします

とりあえず、PCでMPFを使ってCDドライブからCDパートのオーディオトラック (2トラック目) を読み出してみたところ、redump.org のDBと一致したので、これが参考になりそうです。サイズは httpd-ackでダンプしたものより 352,800 Byte (ちょうど2秒分) 大きい感じ。

MPFでダンプしたものを見てみると、先頭にちょうど0x56220 Byte (352,800 Byte) 分のゼロデータがついていました。2秒分のプリギャップと推測されます。

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00056220  18 00 18 00 12 00 12 00  09 00 09 00 07 00 07 00  |................|
00056230  04 00 04 00 09 00 09 00  02 00 02 00 01 00 01 00  |................|
00056240  05 00 05 00 ff ff ff ff  fe ff fe ff 04 00 04 00  |................|
...

一方、httpd-ackでダンプした方は、2,788Byteのゼロデータの後から、MPFでダンプしたデータの352,800Byte以降と同じデータが並んでいました。

% hexdump -C track02.raw
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000ae0  00 00 00 00 18 00 18 00  12 00 12 00 09 00 09 00  |................|
00000af0  07 00 07 00 04 00 04 00  09 00 09 00 02 00 02 00  |................|
...

そこで、httpd-ackでダンプした方のデータの先頭の 2,788 Byteを削って、代わりに2秒分のプリギャップとして 352,800 Byteのゼロを付与し、サイズ調整用に末尾にも 2,788 Byteのゼロを足してやったところ、SHA1がredump.orgのデータベースの値 (1312a9ce85a306e731945dc0e97a047b2a7c6187) と一致しました。なるほど。

% ( head -c $((2352 * 150)) /dev/zero;
    tail -c $((1949808 - 2788)) track02.raw;
    head -c 2788 /dev/zero ) | sha1sum
1312a9ce85a306e731945dc0e97a047b2a7c6187  -

次にGDパートのオーディオトラックについて見ていきます。最初のトラック4を見てみると、httpd-ackでダンプした結果のサイズ (7,566,384 Byte) は redump.orgのDBと一致しています。が、SHA1が合いません (redump.orgの方は dfaeec3bc307904bc598648251a1a74172649086)。

% sha1sum track04.raw
7a57ba3f4aec43480c0e548825fad32c33b98e7d  track04.raw

redump.orgのDBによると、オーディオトラックにはいずれも2秒のプリギャップがついているようなんですが、httpd-ackでダンプしたtrack04.rawなどを見ると、track02.rawと同じく、先頭には2,788Byteしかゼロデータがついていませんでした。

% hexdump -C track04.raw | head
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000ae0  00 00 00 00 ff ff 00 00  00 00 00 00 00 00 00 00  |................|
00000af0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

そこで、試しにhttpd-ackでダンプしたデータの先頭 2,788 Byteのゼロデータを削って、代わりに2秒分 (352,800Byte) のゼロデータを付与し、さらに末尾の 352,800 - 2,788 = 350,012 Byteを切り落とす加工したところ、redump.org のDBとチェックサムが一致。おおー、なるほどね。

% ( head -c $((2352 * 150)) /dev/zero;
    tail -c $((7566384 - 2788)) track04.raw ) | head -c 7566384 | sha1sum
dfaeec3bc307904bc598648251a1a74172649086  -

それ以降のオーディオトラックも、トラック64まではこれと同様の方法で一致しました。

GDパートの一番最後のオーディオトラック (トラック65) については、例外的に、httpd-ackの方が redump.orgのDB記載のサイズより 176,400Byte (1秒分) 小さい状態です。そこでGDパートの一番最後のオーディオトラックについても、httpd-ackでダンプしたデータの先頭 2,788 Byteのゼロデータを削って、代わりに2秒分 (352,800Byte) のゼロデータを付与し、末尾を削ってredump.orgのDBとサイズを揃えたところ、チェックサムが一致するようになりました。あと一息。

% ( head -c $((2352 * 150)) /dev/zero;
    tail -c $((2027424 - 2788)) track65.raw ) \
    | head -c 2203824 | sha1sum
dd201cda4e12c1c47f858cbdd20986f1d2e3daed  -

が、最後のデータトラック (トラック66) については、どうしても結果が一致しません。redump.orgのDBの最後のデータトラックのサイズは、httpd-ackでダンプした結果より225セクタ分 (3秒分) 大きいので、単に225セクタ分のゼロデータを付与すれば良さそうなんですが、それだとチェックサムが合いませんでした。

% ( head -c $((2352 * 225)) /dev/zero ; cat track66.bin ) | sha1sum
fff6c5722482b645d96a5dd7eff64ce77a1f48d5  -

ひょっとして、データトラックの手前のプリギャップのところには、ゼロデータじゃない何かが書かれているのか・・・？ どこかにヒントはないかと思ってググってみたら、何とgdi-utilsというツールの説明に情報が。 どうもデータトラックの手前の150セクタは、プリギャップじゃなくてポーズらしいです。ポーズって何だと思って調べてみたら、何やらデータを埋め込めるとか何とか。そうなると、ここは別途読み出す必要があるということか・・・。

ちなみに、2,788という数字もどこから出てきたのかよくわからなかったんですが、こちらはオーディオリードオフセットというドライブ固有 (機種固有？) の値であるということを教えて頂きました。そうか、プリギャップが2,788Byte入っているというより、2,788Byte分、遅れてデータが始まっているってことなのか。半端なデータですが、4の倍数なので、中途半端にずれても大丈夫なんですね。

this is issue with CD/GD drives in general, it's called "audio read offset" (offset value usually constant for specific drive models).
and that's one of main reasons why "https://t.co/EnV63eVe0E" project exists - theirs tools and dumping methods remove that offset.

— MetalliC (@xMetalliCx) July 20, 2025

AliExpressで買ったN64のダンパーを試してみることに。繋げばいいとあったので、カートリッジを刺した状態でPCにUSB TYPE-Cケーブルで接続。

おお、ドライブとして認識された！

ドライブを開くと、中にROMイメージらしきものが。こんな風にストレージとして見えるのが面白いですね。

CartTest.txtを開くとこんな感じ。ROMを読み出しながらになるからか、コピーしようとすると一瞬引っかかる感じになりますが、無事読めました。すごいな。

さっそく、ずっと気になっていた時のオカリナをダンプしてみました。

3本あったうちの2本が初期バージョン (Ver. 00) で、残りの1本は中期バージョン (Ver. 01) でした。

投票に行ってきました。暑くてヤバすぎ。

AliExpressで買ったゲーム関係の小物が色々届きました。こちらはゲームボーイカラーとゲームボーイポケットの電池の蓋です。なんか蓋がない本体がいくつかあったんでｗ

早速合わせてみたところ、ぴったりでした。色合いもまったく違和感なし。すごい。

こちらはドリキャスのAV端子のプラグ。こんなの売ってるとか凄すぎなんですけどｗ

そしてこちらはN64のコントローラー用のコネクタポートです。ALECK64に64のコントローラーを繋ぐのに使おうかと思い買ってみました。

あと、N64のダンパーも買いました。ダンプして何かで動かすとかそういう予定はないですが、いざという時すぐに動かせるようにはしておきたくｗ

今日はドリキャス三昧でした。まず、手持ちのドリキャスソフトの中で未ダンプのものをhttpd-ackでダンプしようとしたところ、トイ・レンジャーで訂正不能エラーが出てFAILに。

しかし、盤面を見ても大きな傷は見当たらず。念のため、いつものサムスンのドライブ搭載の本体ではなく、ヤマハのドライブを搭載した本体 (VA0基板の本体) でも読んでみましたが、やはりだめでした。珍しくVA0の方が先に進む感じでしたが・・・。

また、セガラリー2も同様に訂正不能エラーでFAILとなりました。

こちらは盤面に同心円状の酷い傷が多数ありました。どう見てもこれですね。後日、手研磨を試してみようと思いますｗ

次に接触不良連発でストレスの元でしかなかったデミロのコネクタを、AliExpressで買った互換品に交換してみました。

元々超はんだ付けしにくい構造な上に、デミロ側の16芯のケーブルの個々の線の被覆が熱に弱すぎてガンガン縮んで、非常に残念な仕上がりにｗ。あと、コードブッシュがなかったので、DSUB 9ピンのコネクタカバーに付属していたと思しき抜け止めの金具を取り付けてあります。

金具のネジがカバーに干渉したため、カバーを少し削ったところ、カバーも無事閉まるようになったんですが、コネクタを抜く際に力が加わると、簡単にカバーが外れて中身だけ残った状態になってしまうことが判明。カバーと中身のかみ合わせ部分が浅くて弱いからか？ うーん、微妙過ぎる。接着剤で固定するか？

続いて15kHz調査の続き。今日はまず クライマックスランダーズ からです。このタイトルは15kHzがまったくだめなパターンでした。RGB1だと信号自体は240pで認識されるものの、画面が縦に引き伸ばされたような状態になり、上半分と下半分でパタパタ切り替わる感じに。

一方、RGB2だと起動時に本体がリセットされます。こんなのもあるのね。ちなみにVGA出力時のタイトル画面はこんな感じです。

お次はポップンミュージックです。このタイトルも、クライマックスランダーズと同様に、RGB1だと画面が縦に引き伸ばされた状態になり、上半分と下半分でパタパタ切り替わる挙動となりました。信号自体は240pで認識されているみたいです。

そして、RGB2では・・・おおっと、RGB2だと480iで正常に映りますね。ついに見つけたぞ、RGB1でNGでRGB2でOKなやつ！ｗ

ポップンミュージック2も同様でした。RGB1だとセガラリー2のRGB2のときのような乱れた表示になりますが・・・

RGB2にすると480iで正常に表示されるようになります。

うーん、RGB1がだめでRGB2ならOKなタイトルは、VGA非対応かつ240p専用みたいなやつだと予想してたんですが、普通にVGA対応かつ 480i OKなやつだったとは・・・ｗ。まあでも、謎が解けてスッキリです。

ちょっと前に話題になって以来、ずっと気になっていた四天明王をついにゲットすることができましたｗ。メガドライブとかスーファミのソフトを買う際は色々と緊張しますが、この手のはニセモノの心配がないのがいいですねｗ

今日の15kHz調査はサイキックフォース2012です。説明書がしわしわだｗ

このタイトルはVGA非対応で、15kHzにすると RGB1・RGB2ともに240pで立ち上がりました。ジョジョと同じパターンですね。

聴力テストしてもらったところ、左耳の聴力が回復してるとのことでした。良かった良かった。

今日の15kHz調査は セガラリー2です。

こちらはRGB1だと480iで普通に起動しますが、RGB2だと画面が縦に引き伸ばされて、変に重なった感じになりますね。同期信号が異常になるのかな？

ドンキーコングバナンザ、始めてみました。マリオオデッセイを始めたばかりのときと似た感じで、まだイマイチ面白さが見えてこない感じｗ

今日の15kHz調査は クイズああっ女神さまっ です。TYPE-2 (RGB2) で動作NGだったリストのお陰でピンポイントで調べられるのがありがたいですねｗ

RGB1だと480iで立ち上がって、RGB2はセガロゴで止まりました。ゲットバストやクレイジータクシーと同じパターンのようです。

新しいピンそろったが届きました。10年くらい頑張ってほしいｗ

今後持ち運ぶことが増えそうなので、ホリのSwitch2のキャリングケースを購入。

ドリキャスの15kHz RGBについて調べていたら、ストIII 3rdでは、電源を入れて、カプコンのロゴが出るまで、スタートとLを押しっぱなしにすると240pモードに切り替わる裏技があるという情報を発見。 が、全然うまく行きません。15kHzモードにしていると、普通に480iで立ち上がっちゃいます。

しつこく調べたら、別のところでスタートとYを押しっぱなしという情報が見つかりました。こっちで試したところ成功。

うーん、どういうことなんだ？ 海外版と違うとか？

TYPE-X2のバトルファンタジアを動かしてみたり。なんかやけにほっそりしているような・・・ｗ

ああ、なるほど。基板側がデフォルトで16:9設定になっているのか。4:3のKVC液晶に出したことで縦長になってるのねｗ

基板は 4:3向けの設定 (640x480) にもできて、解像度の変更はディップスイッチの2番 (マニュアルでは「2晩」になっているｗ) で行うとのこと。

ってスイッチがない！？

と思ったら、黒い板の下から出てきました。これ、両面テープで貼り付けてあるだけなのかｗ。事故防止のために元々は封印してあるとかなんですかね。黒くてつるつるしているので、赤外線が出るポートか何かなのかと思ってましたｗ

2番のスイッチをオフに変更。

上下に黒帯が入って、普通な感じになりました。よしよし。

画面化けの症状が出ているスーチーパイIIIのROMボードですが、一旦外して、怪しいところがないか目視で観察した後、再度M/Bに戻してカバー無しで動かしてみたところ、画面化けが再発しました。

すかさずテストモードに入れてROMチェックをかけましたが、今回も全部GOODです。うーん、わからん。テスト時とそうじゃないときとで、データの経路が違うんだっけ？

何かもうよくわからないんですが、ROM12のBADに関しては、貼り直したらGOODになった実績があるので、これと同じことが起きているんじゃないかと考え、全ROMの足にフラックスを塗って、はんだを一旦溶かして固め直してみました。

ROMカートリッジの基板にカバーをネジ止めした状態で長時間動かしたり、何度か装着→起動→取り外しを繰り返したりしてみましたが、画面化けは再発せず。もやもやは残りますが、これで一区切りとします・・・ｗ

15kHz RGBの2モードの一方でのみ正常動作し、他方ではNGなタイトルについてググってみたら、穴場開発事業団さんの掲示板のログに、穴場開発事業団さんの出しているドリキャス用RGBケーブルのTYPE-2 (RGB2相当らしい) での動作実績 (動作しない実績) の書き込みがありました。これは貴重な情報。以下にタイトル一覧を引用させて頂きます。

• ペンペントライアイスロン
• グランディアII
• ストリートファイターZERO3
• スーパーストリートファイターII X
• パワーストーン
• バイオハザード3 ラストエスケープ
• ヴァンパイア クロニクル
• ぷよぷよ〜ん
• メモリーズオフ コンプリート
• セガラリー2
• ぷよぷよDA!
• シスタープリンセス
• リバイヴ
• チェリーブロッサム
• スーパーロボット大戦α
• クレイジータクシー
• Piaキャロットへようこそ!!2.5
• クイズ ああっ女神さまっ
• クライマックスランダーズ　
• カノン

あれ、グランディアIIは前に試して、どっちのモードでも正常に立ち上がるのを確認したような気がするけど。ほらこの通り・・・

・・・と思ったけど、よく見たら、RGB2だとタイトル画面が縦に2倍に引き伸ばされた状態で表示され、上半分の画面と下半分の画面が頻繁に切り替わる動きになりますね。なるほど、これは異常だｗ。何かしら映ったことで見逃していたようですｗ

RGB1だと480iで立ち上がり、画面の描画も正常に。これが期待される状態ですね。挙動的にはぷよぷよ〜んに近いかな。「RGB2は本来 240p モード」という仮説を補強する証拠になるかもｗ

パワーストーンもすぐ試せるので試してみました。RGB1だと480iで起動するものの、RGB2だとセガロゴで停止。ゲットバスとかクレイジータクシーと同じパターンですね。

上記掲示板のログを見ると、穴場開発事業団さんのTYPE-1のケーブル (RGB1相当) でのみ映るタイトルについての話題も挙がっていましたが、リストを作成された方もわからないようでした。RGB2だけで正しく映って、RGB1だとだめなやつ、実在するのだろうか・・・。

先日フラックスを洗浄したスーチーパイIIIのROM、念のためNAOMIに装着して動かしてみたところ、画面化けの症状が再発・・・。まじか。

その後も様子を見ていたら、画面がブラックアウトした状態でデモが進まなくなったりも。うーん、何か最初に不良に出くわしたときの症状を彷彿とさせるような・・・。しかしROMテストを見ると今回は全部GOODです。うーん？

触診できるよう、カバーを外して長時間ヒートランさせてみましたが、再現せず。うーん、カバーに起因するROMボードのたわみか？あるいは熱起因？ 何だろうなぁ

熱かどうかを切り分けるために、ROMボードのカバーを基板にネジ止めしない状態ではめてしばらく動かしてみましたが、これでも現象は再現しませんでした。そうなると、熱ではない可能性が高い？

長年愛用してきたサンハヤトのピンそろった、ちょっと前に片側のバネ部分のプラスチックが劣化して割れてしまい、そのままだましだまし使っていたんですが、本日お子様によって完全に破壊されてしまいましたｗ

調べてみたところ、買ってから15年近く経過していました。うちから出荷したCPicS2のPICすべてに使ったりしているので、まあお疲れ様でしたという感じですね。ちょうどプライムデー期間中なので、新しいやつをAmazonでポチっておきましたｗ

お昼ごろになってようやく昨日のバリウムが出ました。24時間以上かかるとは・・・ｗ

まだ15kHzの調査をしていますｗ。今日試すのは、ぽめさんに教えて頂いた、15kHzの片方のモードだと正常に起動しないタイトルの1つ、ぷよぷよDA。

試してみたところ、RGB1では普通に480iで立ち上がるものの、RGB2だと起動途中で本体が勝手にリセットされました。RGB2のみリセットになるパターンは初めてな気がします。色々あるんだなぁ。

人間ドックに行ってきました。視力が一段と落ちていてショックです。一方、なぜか聴力は左右とも異常無しとのこと。なぜだｗ。そして珍しくバリウムが出てくれないｗ

ドリキャスのバンガイオー、おそらく20年ほど前に中古で見かけて、買おうか迷って結局買わなかったという記憶があるんですが、何か今になって急に欲しくなり、調べたら安いのがあったので買ってしまいました。中身だけですがｗ。元々店頭体験版だったやつなのかも？ (ゲームラボ年末年始2024の漫画でハンバーガーさんがネタにしてましたが、店頭体験版の中身は最後まで遊べるというか、そもそも製品版とまったく同じっぽいです)

げげ、よく見るとレーベル面の外周近くにもの凄い剥がれが・・・(汗)

光りにかざしても、向こう側が透けて見えないので、反射層は無事なようです。露出している部分は、ロゴの縁取りや顔と同じ感じなので、印刷層の緑や黒の層が削れて、一番下の層が見えてる状態かな。怖い。

他にも問題があるんじゃないかとドキドキでしたが、VA1本体 + httpd_ackで、エラーが出ることもなく、無事ダンプできました (写真撮り忘れ)

あ、これVGA非対応ソフトか。ひょっとして、かつて迷って見送ったのはこれが原因だったのかも？当時は15kHz環境とか多分なかったし・・・。いや、XRGB-3がギリギリあったか？うーん、思い出せんｗ。 (追記: ここに当時の記録が残っていましたｗ。どうやらプレミア価格だったから避けただけの模様ｗ)

15kHzの設定だと、ジョジョなどと同様に、RGB1でもRGB2でも240pで立ち上がりますね。

去年の秋くらいから使っているホーザンのH-722というフラックス、無洗浄タイプだと思って使っていたんですが、ふと気になって調べてみたら、手はんだの場合は洗浄が必要な製品ということが発覚。しまった、勝手な思い込みだったか・・・

修理でこれを使った基板は大体記録が残っているんで、今から調べて対処することはできると思うんですが、問題はどう洗浄するかです。手持ちのサンハヤトのフラックスクリーナーは臭いがキツすぎて使いたくないんですよね・・・ (本当はさっさと捨てたいんだけど、適切な捨て方を調べられておらず、そのまま残ってる感じｗ)

無水エタノールでもベタベタが落ちると思うけど、それでいいのかなーと思ってググってみたら、IPAで落とすのもありっぽい情報が。ほほう、IPAなら臭いもきつくないので良さそうですね。たくさんあるしｗ

というわけで、早速、先日直したスーチーパイIIIで試してみることに。洗浄前はこんな感じ。フラックスがROMの足だけでなく、その周辺にも広がっていました。

フラックスが残っていそうなところにIPAを綿棒とかで塗りつけて、ティッシュペーパーっぽいので拭き取る作業を繰り返します。最初は黄色いベタベタが付いてきましたが、次第に取れて、基板側もすべすべになりました。いい感じかも。

IPA、ありですね。他のもこれで落としていこう。

マリオカートワールド、特に話題にしていませんでしたが、Switch2が来てからほぼ毎日、エアロバイクをこぎながら遊んでいます。で、今日、ようやくグランプリのスペシャルカップの150ccで60ポイント取れました。

これでグランプリは全コース、全排気量で星3つ達成です。終盤より序盤のレースの方が大変でしたｗ

次はサバイバルの方を攻めてみたいところですが、あっちは100ccですらクリアがやっとみたいな感じなので、色々大変そう・・・ｗ

ちょっと前から、去年と似た感じでまた左耳が詰まった感じの症状が発生しているため、耳鼻科に行ってきました。聴力検査中、なぜかお腹が鳴りまくってめちゃくちゃ大変だった上に、左耳の高音域が全然聞こえていなくてショック。で、その結果、またあのまずい薬が大量に処方されましたｗ

あれ、でも、去年より味が若干マシな気も・・・？ ああ、メーカーが違うのか、なるほど。

何か昨日に引き続き、15kHzの2モードの調査を続けています。で、ぷよぷよ〜んが、今まで見たものとまた違う挙動を示すことを発見しました。

RGB1の構成で起動すると、普通に480i で立ち上がります。

が、RGB2の構成で起動すると、信号的には 240p になるんですが、画面は正常に表示されず、画面の左上 1/4 だけが表示されたような状態になりますｗ

で、以下はこの挙動から思いついた仮説です。

• 実は15kHzのRGBにはメインも裏もない
• RGB1 (6番ピンがオープンで7番ピンがGND) は、本来は 480i モード
• RGB2 (6番ピンがGNDで7番ピンがオープン) は、本来は 240p モード
• ただし、こう定義はされてはいるものの、非公式モードだからか守られることはなく、そのタイトルが対応している15kHzモードで立ち上がるようになっているのが大半
  • 大体のソフトは480iに対応していて、RGB1でもRGB2でも480iで立ち上がる
  • 240pにしか対応していないソフトは、RGB1でもRGB2でも240pで立ち上がる (ジョジョ、ガンバード2など)
• 一部のソフトは、240pに非対応の場合にRGB2が指定されたら安全側に倒して起動しない動きになったり (ゲットバス、クレイジータクシーなど)、未定義なために異常動作となったり (ぷよぷよ〜ん) する

これなら、15kHzに2モードあるというのも納得です。果たしてその真相や、いかにｗ

この前もちょっと書きましたが、普通に(≒ソフトにパッチを当てたりせずに)ドリキャス本体から15KHz RGBで映像を出力させるには、以下の2種類の方法が存在します。

• AV端子の6番ピンをオープンにして7番ピンをGNDに落とす (RGB1)
• AV端子の6番ピンをGNDに落として7番ピンをオープンにする (RGB2)

で、RGB1がメインのモードで、RGB2が裏モードみたいな関係らしく、RGB1では正常に表示されないタイトルでも、RGB2だと表示される場合があるみたいな説明が 東京RGBホスピスさんのところをはじめ、あちことに書かれていたりします。 ただ、具体的に、RGB1がNGでRGB2がOKなタイトルが何なのかや、どう映らなくなるのか、逆のパターンはあるのか等々、詳しい情報が全然見当たりません。これは気になります。というわけで、ちょっと手持ちのソフトで調べてみることにしました。

調査にはこのDC VGA デミロを使います。

デミロ自体は、元々は15kHz出力に対応しておらず、コンポジットビデオ出力 (6番ピンと7番ピンが両方オープン) と VGA出力 (6番ピンと7番ピンが両方GND) の2モードしかないんですが、スイッチを増設するなどの改造をして、6番ピンと7番ピンを独立して設定できるように改造してあります。また、VGA端子からは、H-SynCの代わりにC-Syncを出せるようにもしてあります。

ひとまず手近なところにあった数本を試したところ、多くは両方のモードで普通に映ったんですが、ゲットバスが特殊な感じでした。

RGB1だと普通に480iで起動するんですが・・・。

RGB2だと、起動途中でセガのロゴから進まない状態となります。

また、Xでぽめさんに教えて頂いたクレイジータクシーで試してみたところ、こちらも同様の結果となりました。RGB1だと480iで起動し、RGB2だとセガのロゴ表示のところで止まります。

なるほど、RGB2が裏モード扱いなのは、そういうことか・・・。

その後も色々と手持ちのタイトルを試した結果、ギガウイング、ストゼロ3 (マッチングじゃない方)、カノン の3タイトルについては、RGB1とRGB2のどちらに設定しても、ゲームが起動する前に本体が再起動する挙動を示すことがわかりました。こんなのもあるんですな。

また、試したタイトルの大半はRGB1でもRGB2でも480iで立ち上がりました。RGB1やRGB2 で240pで立ち上がったのは、試した中だとジョジョとガンバード2くらいで圧倒的に少数な感じ。まあ、元々15kHz RGBのアーケード移植作品でもない限り、240pで出すモチベーションもないか。

スピードアタックのI/Oマトリクス、調べたらこんな感じでした。

というわけで、これを麻雀配線のマトリクスにマップしてみました。

なるべく遊べるボタン配置になることを意識して割り当てたことで、むき出しのコンパネでも割と普通に遊べましたｗ

起動しないスピードアタック、原因がメモリエラーであると推測し、メモリ周りを見てみることに。とりあえずソケットに刺さっている主記憶の16kbitのSRAMを外してTL866CSで見てみました。

うーん、主記憶にエラーはなさそうです。まあ、症状的にもVRAMっぽい感じだしなぁ。

続いてVRAMと思しきSRAMを見てみます。2114系みたいです。とりあえず剥がす前に、動かしながら信号をロジックプローブで観測してみたところ、6Dのチップだけ、データ線が常にHighに張り付いていることが判明。これか？

外してみました。

テストにかけてみようと思ったんですが、うちにある機材は2114のテストには対応していませんでした。残念。こうなると、ダメ元で交換するしかないですね。しかし2114を搭載した部品取りできそうなジャンク基板なんて、うちには・・・あったｗ

正体不明ですが、麻雀のコピー基板か何かです。ROMのパッケーが壊れたりしていてボロボロ。これの中央付近に、日立のHM427114P-3が使われていました。

元々スピードアタックに搭載されている東芝のTMM2114AP-15の応答時間は150ナノ秒くらいなのに対し、HM472114P-3は300ナノ秒くらいかかるようで、だいぶ遅いです。ただ、MAMEのソースによると、CRTコントローラの動作クロックは1.5MHzらしいので、まあ行けるんじゃないかとｗ

さあどうだ・・・。おお、立ち上がった！

スピードアタック！

良いですね、この雰囲気ｗ

テストモードにするとI/Oの確認もできるようです。MAMEのソースだけだと、ボタンとの対応がぱっと見よくわからなかったんで、これは助かりますね。

今日はスピードアタックのハーネスを作ってみます。適当な部材はないかとジャンクハーネス箱を漁ってみたところ、麻雀配線のカードコネクタの付いた配線が見つかりました。こんなものが存在していたとはｗ。これを使いましょう。

配線とはんだを除去して清掃。

とりあえず電源、映像、音声のみを配線してみました。

動かしてみます。

おお、何か出た！

しかし、このぐちゃぐちゃな画面から先に進みません。微妙に動いたりするので、メモリチェックでFailして再起動を繰り返していたりするのかも・・・？

久しく裸のまま使っていたPixel 3 XLですが、やっぱり滑りやすくて不便な感じ。で、調べたら、Amazonのマーケットプレイスでお手頃なのが売られていたので、いまさらながらTPUのケースを買い直しました。

おお、いい感じです。

本当は Pixel 5a (5G) がこのポジションを引き継ぐはずだったわけですが、まあ、ご存知の通り文鎮化してしまったがゆえ・・・

セタのスピードアタックの基板です。ジャンクとのこと。

よく見ると部品が一部抜かれています。まずCPU (Z80というかD780C-1) がありません。

また、3Fの部品もありませんでした。一瞬ヒヤリとしましたが、画像検索した結果、過去のヤフオクの出品物の画像から、ここは74LS00ということが判明。危ない危ないｗ

これらの他には、取られた部品はなさそうです。そしてジャンク箱を漁ってみたところ、部品取り用の四川省の基板に、ちょうど両方の部品が搭載されていることを発見。よしよし。

さっそく外して確保しました。

そしてスピードアタックの基板に装着。

ハーネスがないので続きはまた後日。MAMEのソースによると、操作系はマトリックスらしいです。動作を確認するだけなら、麻雀ハーネスに変換しちゃうのが手っ取り早いかな。