2025年11月30日から2025年11月1日までの日記を表示中
2025年11月30日 (日)
■ドンキーコングバナンザ
このところゼルダ無双 封印戦記ばかりやっていたんですが、気がつけば2回目のイベント期間が終わりそうだったので、慌ててエメラルドラッシュをプレイ。が、久しぶりすぎて色々ミスりまくり、初回クリア時のスコアは100万点に惜しくも届かず、一発クリアに失敗しましたw
二度目のチャレンジで無事100万点を超えてスッキリw
フィギュアをゲット。まったく思い入れがないので、うーん・・・という感じw
[コメントを書く]
2025年11月29日 (土)
■基板
[コメントを書く]
■Fail2ban
Windowsから自宅のLinuxマシンにSCPでファイルを転送しようとしたんですが、ユーザ名の指定を忘れたまま3回連続で認証ミスって、Fail2banにかかって、LAN内なのにBANされる事態に。事故ったのが自宅でほんと助かりました・・・w
[コメントを書く]
2025年11月28日 (金)
■基板
NAOMIのCF作成プログラムを書き始めてみました。Linuxだと難しいことを考えずにCFのデバイスファイル (/dev/sdbとか) をfreadで読んでfwriteで書き換えられるので、中身さえ決まれば何でもできるのがありがたいですね。
[コメントを書く]
2025年11月27日 (木)
■基板
IOデータの512MBのCFメディアを新たにゲットしました。
今回のは普通にNAOMIのDIMMボードで使えました。PCからの読み書きがめちゃくちゃ速い上に、今までで一番お安かったのが何とも・・・w
で、今日はFAT16でフォーマットしたCFのブートセクタのBPBのところをパースして読んでみたりしていました。
[コメントを書く]
2025年11月26日 (水)
■基板
FAT16でフォーマットしたCF上にツールでファイルを配置するにあたって参考になる情報がないかと検索してみたら、知りたいことがほぼ全部書いてありそうなページを発見。 めちゃくちゃ詳細かつわかりやすい解説で、非常にありがたいですね。
また、LinuxでFATの詳細を確認したりできるツールはないかと調べてみたらfatcatなるツールを発見。 実際のCFの中身をぱぱっと確認できるのが便利ですね。これまたありがたい感じ。
[コメントを書く]
2025年11月25日 (火)
■基板
ここへ来てようやくNAOMIで安定してCFからゲームを起動させられる状態を確立できたので、Linuxで作業ができるよう、gcfi 相当のツールを自作してみることにしましたw。ちゃんとやるにはFATとかも押さえておく必要がありそうですね。
[コメントを書く]
2025年11月24日 (月)
■光沢シート
ハセガワのミラーフィニッシュを買ってみました。模型用のやつです。
調べたら、裏面 (貼り付ける側) もミラーになっているらしいので (透明な素材に裏側から貼ったりする使い方を想定しているっぽい)、反射層が削れちゃっているCDの補修に使えるかなーとw
[コメントを書く]
■基板
CFからゲームを起動させる際、サイズが小さいとOKだけど、サイズが大きいとNGとなるケースがあるようです (確率の問題?)。そこで、なるべくサイズが大きいファイルをテスト用に確保すべく、ダンプ済みのGD-ROMのイメージからGD ROM Explorerを使ってゲーム本体をexportし、サイズを比較してみました。結果、手持ちのNAOMI/NAOMI2のGD-ROMの中で一番本体のサイズが大きいのは旋光の輪舞 (無印の方) ということが判明。サイズは254.25MiBでした。ほんとDIMMの容量ギリギリいっぱいな感じですねw
ちなみに、その調査の過程で、たころんとメルティブラッドAC (Ver.B) のダンプに失敗していたことが発覚しました (GD ROM Explorerで読み込んだらエーラが出たことで気づいた)。ダンプし直したら正常なデータになったので、おそらく以前ダンプした際に、httpd-ackからの転送で用いたFirefoxの拡張 (DownThemAll!!) になんか問題があったのではないかと推測されます。前回ダンプ時と比べると、環境は大幅に改善しており、ノウハウも色々と蓄積されているので、思い切って一通り取り直してみるのもありか・・・?
[コメントを書く]
2025年11月23日 (日)
■基板
NAOMIのCF起動の実験に使いたくて512MBのCFを追加で3枚購入しましたw
右下のMC 3000というやつ (中身はKingston製) は普通に使えました。
一方で、32MB品がバッチリだったんだから当然いけるだろうと思って買ったプリンストンとバッファローの512MB品は、なんとどちらもダメでした。smartctlの出力を見るに、中身は同じメーカーのOEMっぽい? いけるやつとだめなやつで何が違うのか、そのうち波形を見て比べてみたいところです。
[コメントを書く]
2025年11月22日 (土)
■基板
一昨日届いた変換名人のCF-IDE変換アダプタは、コネクタが40Pメスコネクタなため、今までのCF-IDE変換基板と交換して使えませんw。そこで、ジェンダーチェンジャーを作成してみました。
ワイヤーが無駄に長いのは、元々基板を入れないで、コネクタのピン間を直接ワイヤーで結線した形で作ろうとしていた頃の名残ですw。はんだ付けしていたら、熱でピンの周りのハウジングが溶けてしまい、一部のピンがハウジングから抜けてきてしまったため、ワイヤーを再利用しつつ、この形で作り直しました・・・w
変換名人のCF-IDE変換アダプタにCFを装着し、変換アダプタをジェンダーチェンジャーの片側に装着。もう片側にはIDE-USB変換ケーブルを取り付けてPCに接続してみます。
無事認識されることを確認。よしよし。
ここからはNAOMIに接続して実験していきます。といっても、昨日まで使っていたCF-IDE変換アダプタとの違いは、3.3Vで動かせることくらいなんですが。
とりあえずプリンストンの32MBで、外から5Vを入れて起動することを確認。このCF-IDE変換アダプタは、FDD用電源コネクタから電源を取った場合でもダイオードを経由するため、若干電圧が落ちることになります。
そのままバッファローの32MBに差し替えましたが、こちらはダメでした。難しい・・・。
電源を別系統から取っているのが問題と考え、NAOMIマザーから電源を取るようにしてみました。
お、起動した!やっぱりマザーボードから取る方がいいんだなぁ。
ジャンパを差し替えて3.3Vにしてみました。
お、動きますね。
じゃあLexarはどうか。まずは5Vで確認。
おお!初めて読み込みが始まった!・・・が、メモリチェック90% のところで止まって起動せずw
ジャンパを差し替えて3.3Vに変更してみます。
うおお、起動した!なんと3.3Vにするのがポイントだったようです。
1GBのメディアが使えるということは、これであらゆるタイトルで実験できるということに。これは嬉しいw
[コメントを書く]
2025年11月21日 (金)
■飲み
飲み会でした。お疲れ様でした。
[コメントを書く]
■BEEP
[コメントを書く]
2025年11月20日 (木)
■基板
変換名人のCFアダプタが届きました。ググると、これを使って起動に成功している方がいらしたり、AliExpressではこれを改造したと思しきNAOMI向けCF用アダプタが売られていたりするので、何かしら良いところがあるのかなと思い・・・。
信号線の変換自体は、変換アダプタによって変わることはないと思うんですが、この変換アダプタでは、ジャンパを切り替えることで、デフォルトの5Vモードから3.3Vモードに切り替えることができます。
って、ジャンパを見たら、デフォルトで3.3Vモードになってるしw
基板を観察してみると、ダイオードが合計で4個搭載されているようです。裏側に2個実装されているダイオードは、直列につながっており、JP2の切り替えでバイパスされるようになっていました。これで+5Vを+3.3Vに落としているようです。
一方、表側のダイオードの片方は、FDD用電源コネクタからの+5Vに、そしてもう片方はなんと40ピンコネクタの20番ピン (IDEだとキーになっていてピンがないところ) につながっていました。どういうことだと思って調べてみたら、ここから電源を取る製品があるとの情報が。DiskOnModule (DOM) というのか・・・。というか、よく考えたらeXボードのゲームのメディアがこれかw
これまで使っていたCF-IDE変換アダプタ (Amazonで買ったんですが、実はこれ、変換名人の別の製品のデッドコピーなのかも・・・) にも、よく見たら20ピン側にダイオードが入っていました。こっちから電源を取ると、0.7Vくらい落とせるということか・・・。
ひょっとして、今までのCF-IDE変換アダプタでプリンストンのCF以外が全然認識できないのも、この辺が関係していたりするのかも・・・?というわけで、試しにIDEの20番ピンに無理やりピンヘッダを取り付けて、CFがダイオード経由で電源を取れるようにしてみましたw
まあ、もっとも、ここ数日、CFからの起動が全然うまくいかない状態で、電源どころの話じゃないんですけどね。ほんと、もはやキーチップの中身が壊れたとかくらいしか考えられない感じで・・・って、もしかしてそういうこと!?
早速自作のダンパーでキーチップを読もうとしてみたんですが、全然読み出せない状態です。なるほど、こりゃ起動するわけないな。で、改めてよく観察してみたら、すぐに原因がわかりました。PICの18番ピンが思いっきり曲がっていて、ちゃんとソケットに刺さらない状態でした。そりゃだめだわ・・・。
キーチップを分解して足を戻してやったところ、無事プリンストンで起動するように(電源はNAOMIのM/Bから取って、IDEの20番ピン経由で入れている状態)。ああ、やっと戻ってくることができましたw
で、そのままバッファローの32MBのCFを試してみたところ・・・
なんとこちらも起動!今まで一度も起動に成功したことがなかったのにw。うーん、電源か、電源なのか。
まあしかし、相変わらずLexarの1GBはだめですねw
[コメントを書く]
2025年11月19日 (水)
■3DS
お子様に3DSを貸し与えていたら、なんと適当に操作して本体を初期化してしまった模様・・・。
青ざめましたが、ニンテンドーネットワークIDのお陰で購入済みのコンテンツをすべて再ダウンロードして復元することができました。
ふぅ。もう貸さないぞw
[コメントを書く]
■基板
この前切った50P SCSIケーブルの片割れを使って、もう一つNAOMIのDIMMボード用のIDE変換ケーブルを作ってみることに。
ダンピング抵抗も入れておらず、ほんと繋いだだけです。
これにCF-IDE変換アダプタを取り付けてみましたが、まあ起動しませんね。残念・・・
ひょっとしてNAOMI側を壊しちゃったとか!?いやでも、GD-ROMドライブを繋ぐと普通に起動するなぁ。うーん、ほんと何がだめなんだ。
[コメントを書く]
2025年11月18日 (火)
■基板
昨日、CFからのゲームの起動に成功したのはプリンストンの32MBのメディアなんですが、同じ環境でもバッファローの32MBとLexarの1GBでは起動してくれませんでした。残念。
で、これらがダメなのは、まだ信号品質に問題があるからなのではないかと考え、CF側が出力になる信号 (DMARQ、INTRQ、IORDY) のところにもダンピング抵抗を挿入してみました。
が、何かむしろ悪化する結果に。プリンストンの32MBですら起動しなくなってしまいました。がーん。
追加したダンピング抵抗を迂回するように配線を戻してみたんですが、それでも全然起動してくれません。やばいな、何だろう・・・。
[コメントを書く]
2025年11月17日 (月)
■基板
NAOMIのCFからの起動がうまくいかない問題、これまでの感じからすると、やっぱり信号品質の問題な気がしてなりません。ダンピング抵抗とか入れたら改善するんじゃ・・・。そこでGDドライブを分解して、基板の50ピンコネクタ付近を観察してみたところ、データバスに82Ωの抵抗が入っていることを発見。なるほど、やっぱりダンピング抵抗的なものが入っているのか。
さっそく手元にあった75Ωの抵抗 16本を、変換基板のデータバスに挿入してみました。場所がなさすぎて、こんな風に立ててありますw
さあ今度こそどうだ・・・。
うわー、起動した!ついに起動しました!ダンピング抵抗凄い!
ちなみに、ダンピング抵抗を取り付けた後、テスターで確認したら、なぜか1MΩが2個も見つかるという事故があったりしました。よく見ると全然違うんですが、カラーコードの雰囲気が何となく似ているせいで、以前仕分けした際に75Ωに混ざってしまっていたものと思われます。
カラーコード、今日日色々と問題のある仕組みだと思うんですけど、ほんとなんでずっと当たり前のように使われているのか・・・。変えようという機運はないんすかね。
[コメントを書く]
2025年11月16日 (日)
■基板
NAOMIのCFからの起動がうまくいかない問題ですが、中間コネクタつきのフラットケーブルの反対で信号が反射しているのが良くないのではないかと推測し、思い切ってフラットケーブルを切ってみましたw
が、特に改善は見られず。相変わらずバッファローの32MBメディアはエラー26 (OPTION BOARD MALFUNCTIONING.) になります。
また、プリンストンの32MBメディアの方も、3周くらい読み直しした後、結局エラー21 (THIS GAME IS NOT ACCEPTABLE BY MAIN BOARD.)で終了。こちらも全然良くなっていません
ググってみると、電源周りの問題だったみたいな情報が出てきたので、試しに+5VとGND の間に積層セラミックコンデンサや電解コンデンサを入れてみましたが、特に変化なし。
うーん、簡単ではないですね。
[コメントを書く]
2025年11月15日 (土)
■基板
昨日作った変換基板、80芯のPC用IDEケーブルが良くないのかと思い、シンプルな40芯のケーブルをSystem 573から借りてきました。
が、やはりダメですね。エラー25 (CAN NOT ACCESS GD-ROM DRIVE.)に。
で、改めて配線を確認してみたところ、なんと思いっきり間違えていて、片側の配線が逆順になっていることが明らかに(汗)。そりゃ動かんわけだ・・・。そして修正するよりも作り直した方が圧倒的に楽そうだったので、大人しく別基板 + 柔らかい線材で作り直しましたw。GNDの接続が全然最適化されていなくてアレですが、とりあえず最初は他所で動いた実績があるものを真似ようと思い・・・。
こんな感じにCF-IDE変換アダプタを接続します
作り直した方だと、プリンストンの32MBメディアの読み込みが開始・・・しそうですが、すぐにエラーになっちゃいますね。
メディアをプリンストンの32MBからバッファローの32MBに交換してみます。
こっちはエラー26 (OPTION BOARD MALFUNCTIONING.) に。
ちなみに最近ゲットしたレキサーの1GBのメディアはもっとダメでしたw。GDドライブを接続したときと同じように、接続しているとシステムが起動すらしません。せっかくFAT16で初期化できて、なおかつ何でも入る容量のものを手に入れたというのにw
[コメントを書く]
2025年11月14日 (金)
■基板
gcfiで作ったCFを実際に動かすべく、DIMMボードとGDドライブの間のやり取りを観察するのに使った中間基板に、IDE 40ピン接続用のピンヘッダを立てて配線してみました。
裏側はこんな感じで酷いですw。ケチって余りまくっている硬い線材を使ったのが良くなかったw
ここにPC用のIDEケーブルを繋いで、ケーブルの反対側の端にCF-IDE変換アダプタを取り付けることで、CFにアクセスできるようにしようという作戦です。
が、まったく起動する気配なし。エラー25 (CAN NOT ACCESS GD-ROM DRIVE.)になります。
うーん、何が悪いんだろう。 (追記: 後になって、裏側の配線が半分間違っている (逆順に配線されている) ことが判明しました。何から何まで酷かったです・・・。反省)
[コメントを書く]
2025年11月13日 (木)
■基板
NAOMIのDIMMボードをCFに接続するための変換ケーブル等を作る前に、そもそもgcfiがどんな風にCF上にデータを作るのか、CFの中身を観察して、例のblogの中身と照合してみたり。なるほど、確かに合致する・・・。
[コメントを書く]
■ゼルダ無双 封印戦記
ようやく始めることができました。そうか、今回はリンクがいない時代の話だから、本当にゼルダ無双なんですねw
[コメントを書く]
2025年11月12日 (水)
■基板
4系のファームウェアが書かれたDIMMボード + 非Net DIMMの小基板の組み合わせでも、ファームウェアに手を入れることでGD-ROMドライブの利用が可能になることがわかりましたが、4系ファームウェアの目玉機能 (?) であるCFブートはどうなんだろうと気になり、実験すべく色々と調べ始めました。
ひとまず、CFにはGD-ROMの中身を丸ごと入れる必要はないようで、ゲーム本体のバイナリが収まる容量であれば良いようです。ただ、メディアがFAT16でフォーマットされている必要がある都合上、2GBを超える容量のものは使えない模様。で、手元には32MBと32GBの2種類しかないため、実験するには32MB一択ということにw。このサイズに収まるのは、ファームウェアアップデータ (2MiB) 以外だとスターシーカー (18MiB弱) くらいで、その次に小さいと思われる斑鳩 (32MiBピッタリ) はギリギリ容量オーバーで入りません (32MBのCFには32MiB分書けないのでw)。まあ1つでも入るものがあれば実験としては十分でしょうw
また、CF上のデータの配置にも、色々と制約があるようで、さらには置いたデータに何かしらの加工も必要なようです。検索してみたところ、この辺について詳細に解説しているblogが1つだけ見つかったんですが、英語の文法もさることながら、書いてあること自体にも明らかな間違いが多く (どっちもわざとやっている?)、ここからちゃんと動くツールを自作できる気がしませんw。内容は参考にしつつも、実績あるツールがあれば、まずはそっちを使った方が良さそうです。
で、良いツールはないかと探してみたところ、gcfiなるWindows上のコマンドプロンプト上で動作するフリーのツールがありました。シンプルな実行ファイルが複数用意されている、好みのタイプのやつですねw。
というわけで、早速IDEポートのある古いデスクトップ機を引っ張り出してきて試してみることに。わざわざIDEポートに接続しているのは、CFにデータを置く際に必要となるメディア固有のシリアル番号をATAのIDENTIFY DEVICEコマンドで読み出して調べておく必要があるためです (普通のUSB接続のカードリーダーだと、これができない)。ちなみに一度調べてしまえば、後はUSB接続のカードリーダーでも行けるようです。
gcfiに同梱されているataidでシリアル番号を取得した後、gcfiを実行してみたところ、CFに必要なファイルが生成・コピーされました。後はこれで起動することを確認できればいいわけですが・・・今の所これをDIMMボードに接続する術がないので動作を確認できませんw。次はDIMMボードをCFに接続するための変換ケーブル等の作成ですね。
ちなみにCFのシリアル番号の読み出しですが、Linuxだと smartctl コマンドで取り出すことができます。また、その際、手持ちの USB-IDE変換ケーブル + CF-IDE変換アダプタ (lsusbするとJMicronのJM20337というチップ名が表示される) が使えました (ataidだと手持ちの機材ではうまくいかず)。新しいCFカードを使う際に一度だけ必要とはいえ、Linux環境がある場合、こっちの方が圧倒的に便利ですねw
% sudo smartctl --identify -d auto /dev/sdb ... 10-19 - . Serial number (String) 10-13 . 0x5051:4930:3030:3030 "PQI00000" 14-17 . 0x3030:3030:3020:2020 "00000 " 18-19 . 0x2020:2020 " "
[コメントを書く]
■ドンキーコングバナンザ
[コメントを書く]
2025年11月11日 (火)
■基板
4.03のファームウェアが書かれたDIMMボードにGDドライブを接続するとDIMMがハングしたような状態になる問題、これまで観察したことから推測するに、最初に打ち込んでいる自己診断コマンドの完了タイミング(割り込みが出るタイミング?)の問題っぽい気がしています。そして中華のGDドライブエミュレーター(?)を接続した場合、自己診断コマンドにちゃんと応答しないままタイムアウトっぽい状態で先に進んでいることを考えると、自己診断コマンドは、必ずしもちゃんと対応する必要はないということに。もしそうだとすると、最初から自己診断コマンドを出さなくても起動するのでは・・・。
というわけで、プログラム中で自己診断コマンド (0x90) を発行しているっぽいところがないか、ダメ元で逆アセンブル結果を探してみたところ・・・なんとあっさり見つかりましたw。レジスタに 0x90を書いていて、その手前では、波形で見たのと同じ順番で、値をATAレジスタと思しきところにWriteしています。レジスタに 0x90を書いているところ自体が限られるとはいえ、こうも簡単に見つかるとは・・・。波形をしつこく見ていたお陰ですねw
で、ATAのコマンドを調べてみると、NOPコマンド (0x00) というのがあるようで、自己診断コマンドをこれに置き換えることができそうです。というわけで、早速ファームウェアイメージの当該箇所の0x90を0x00に書き換え、CRC32 が 0xFFFFFFFF になるように末尾の4Byteを書き換えたファームウェアイメージ (1MiB分) を作成してみました。これを強制更新フラグを立てたアップデータと結合して、LAN経由で流し込みます。
更新できました。
それでは小基板を非Net DIMMのものに置き換えて、GDドライブを接続して電源オンしてみます。まあきっとダメだろうけど・・・って、GDドライブがつながった状態でも立ち上がるようになったし!しかもちゃんと読み込みに行っている!
起動した!凄い!まさかこれで改善するとはw
というわけで、4系のファームウェアが書かれたDIMMボード + 非Net DIMMの小基板の組み合わせで、GDドライブが認識できない問題、解消です。やったー。(追記: その後、何度か追試をした結果、しばらく間を開けて電源を入れた場合に症状が再発することがわかりました。確度を上げるには、何かもうひと工夫必要そうです)
[コメントを書く]
2025年11月10日 (月)
■基板
NAOMIのDIMMボードとGDドライブの間の信号を観察するにあたり、手元にあるATAのドキュメント (Seagateのやつ) だけだとよくわからないところが色々とあったので、CQ出版の解説書を買ってみましたw
今回は大変お安く手に入ったのでよかったですが、これに限らず、この手の古い技術の話を扱った書籍は、是非電子版で買えるようになってほしいところ・・・。
[コメントを書く]
2025年11月 9日 (日)
■ドンキーコングバナンザ
[コメントを書く]
■基板
DIMMボードとGDドライブの間の信号をロジアナで観測できるようになったので、色々と信号を観察してみました。まずは4.03のDIMMボード + 非Net DIMMの小基板 + GDドライブの組み合わせから。最初に一瞬やり取りがあった後、すぐに止まってしまうようです。
もうちょっと細かく見ると、最初にSector Numberレジスタを読み出したり、Device/Headレジスタに 0xA0 を書いたりして・・・
Execute Device Diagnostic コマンドを叩き込んでStatusレジスタをポーリングし・・・
しばらくして、ビジーが解除されたところで停止しているように見えます。GDドライブ側が応答しているのに、DIMMボード側が次の信号を出してこないような感じ?
Net DIMMの小基板を搭載している場合も、最初の波形は非Net DIMMの小基板を搭載した場合とよく似ています。
が、こちらはしばらく間が空いた後、続きが始まります。
最初のシーケンスの末尾を見ると、Net DIMMの場合、Execute Device Diagnosticコマンド起因のビジーが下がった後、Sector Count/Interrupt Reason レジスタを読んでいました。うーん、つまり、非Net DIMM小基板の方は、Execute Device Diagnosticに対するGDドライブの応答を処理する際、Sector Count/Interrupt Reasonを読みに行く手前でDIMMボード側がハングしているということ・・・? (追記: 非Net DIMMの小基板を付けた場合でも、Sector Count/Interrupt Reasonを読みにいくケースがありました。もちろん(?) その場合も、シーケンスはそこから先には進みませんw)
また、例のGDドライブエミュレーター(?)については、最初から隙間なくやり取りが続いている感じです。
ただ、拡大してみるとずっとこんな感じ。ひたすらStatusレジスタをポーリングし続けているだけでした。どうもドライブ側がExecute Device Diagnosticに応答するまでの時間が異常に長いようです (実はExecute Device Diagnosticに対応していない可能性も。最終的にタイムアウトしてDIMMボード側が諦めている?)。GDドライブエミュレーターを接続していると、NAOMIの電源を入れてから画面が出るまでに超遅時間がかかることと関係しているのかなw
あと、4.03のファームウェアが書かれたDIMMボードに非Net DIMMの小基板を取り付けた上で、Triforceに接続したパターンの波形も確認してみました。この組み合わせだと、何故か普通に起動するので、何か秘密があるのではないかと思ったわけですが・・・なんとシーケンスが全然違いました。Triforceの場合、DIMMボードのファームウェアが動くのではなく、メディアボード側が制御する形になるとかなのかも?
[コメントを書く]
2025年11月 8日 (土)
■基板
昨日作った信号観測用のユニバーサル基板ですが、ロジアナのプローブがゆるゆるで全然使えないことが判明w。ロジアナのプローブを刺す用のピンヘッダに、通常よりも細いものを使ったのが裏目に出た感じです。泣く泣く隣に普通の太さのピンヘッダを追加で立てましたw
で、新たに立てたピンヘッダに、ZEROPLUSのロジアナ (LAP-C 10604) を接続してみました。16chしかないので、必要最低限のところを観測する感じでw
お、それっぽい波形が取れている?
本当は32chのHantek 4032Lの方を使いたかったんですが、なんかSigrok/PulseViewが思うように動いてくれず・・・。見る信号を厳選すれば16chでも何とかなりそうなので、当面はLAP-C 10604で頑張りますw
ちなみに16chのLAP-Cを改造して32ch化する方法があったことを思い出し、手元のものを開けて確認してみたんですが、うちのはZP322MC-5搭載で、改造不可のやつでした。残念w
[コメントを書く]
■ドンキーコングバナンザ
[コメントを書く]
2025年11月 7日 (金)
■基板
DIMMとGDドライブの間の信号を観測したいんですが、接続に使われているのがハーフピッチ50Pのコネクタ (外付けのSCSI機器でよく使われているやつ) なので、なかなか敷居が高い感じです。何とかして楽に観測する方法はないかと考えて思いついたのがこちら。SCSIの外付けMOドライブです。
もちろん使うのはドライブそのものではなくこちら。両端がハーフピッチ50Pメスコネクタで、間に 25x2 の50ピンのメスコネクタがついたフラットケーブルを拝借しますw
ひとまずDIMMボード - SCSIケーブル - フラットケーブル - SCSIケーブル - GDドライブという順で繋いで、GDドライブからゲームが起動できることを確認。ケーブルが長くなると信号的に問題が起きそうですが、一応これくらいならセーフな模様w
続いて、フラットケーブルについている 50ピンのメスコネクタから信号を引き出す基板を用意します。中央の2列の25ピンのピンヘッダがフラットケーブル接続用で、上下に1列ずつある25ピンのピンヘッダにロジアナのプローブを接続します。
裏側はこんな感じ。廃材を活用していますw
フラットケーブルを取り付けてみました。いい感じかも?
[コメントを書く]
2025年11月 6日 (木)
■ゼルダ無双 封印戦記
[コメントを書く]
■ドンキーコング バナンザ
[コメントを書く]
■基板
4.03が書かれたDIMMボード + 非Net DIMMの小基板の構成にGDドライブをつなぐとNAOMIが起動しない問題ですが、ふと手元にあるMADE IN JAPANと書かれた、どう見ても中華製の怪しいGDドライブエミュレーター (?) の存在を思い出し、試してみることに。
絶対ダメだと思ってたんですが、なんと起動しましたw
ドライブ側が応答し始めるまでにだいぶ時間があるようですが、ひょっとしてここに起動成功の可否を左右するヒントがあるのかも?ちょっと信号を観測してみたい感じです。
[コメントを書く]
2025年11月 5日 (水)
■ドンキーコングバナンザ
ゼルダ無双 封印戦記の発売までに何とかエメラルドラッシュを終わらせたかったんですが、なんと気がつけば封印戦記は明日発売w。というわけで、今日はちょっとエメラルドラッシュに集中的に取り組み、リゾートの階層のレベル4〜6を一気に終わらせましたw。流石にコツを掴んだか、3レベルともノーミス。このままレベル7もさくっと終わらせられるかな。
[コメントを書く]
2025年11月 4日 (火)
■DVDケンマくん
今日はドリームキャストのバンガイオーの店頭体験版と思しきメディアをDVDケンマくんmateで研磨してみます。
このメディア、 Samsungドライブ搭載のVA1以降の本体では問題なく動いて、ダンプもリトライすらなく完走するんですが、ヤマハドライブのVA0本体だとダンプに失敗します。たしかゲームも、VA0本体だとちゃんと起動しなかったような・・・
ケンマくんで研磨した結果、少し先に進むようにはなりましたが、結局リトライ多発で失敗に。
というか、研磨してから気づいたんですが、このメディア、反射層に穴が3箇所ほどあるようで、向こう側の光が透けて見えますね・・・w。この状態でもSamsungドライブだとエラー無しで読めてしまうというのが凄いw
ヤマハドライブだとこの穴を訂正できないのかなーと思ったんですが、ヤマハドライブがエラーを出しているのは、セクタ番号的にもっと外周の方で、穴の位置のあたりのセクタはヤマハドライブでも普通に読めているっぽいです。最外周には、目視だとひどい傷も特に見当たらないんですよね。うーん、もう少し研磨すべきか否か、悩ましいw
[コメントを書く]
■ドンキーコングバナンザ
[コメントを書く]
2025年11月 3日 (月)
■DVDケンマくん
先月届いたものの、なかなか試せていなかったDVDケンマくんmateを開けてみました
本体です。
そして付属品。わかってはいましたが、まあなかなか大変そうです・・・w
最初はなぜかジャンクで買ったドリキャスに入っていたぼろぼろのゆずのCDでお試ししてみます。
このCD、盤面をクリーナーで清掃してもこの有様で、以前、PS本体で試しに読ませてみた際は、一部のトラックしか再生できませんでしたw
カバーを上げてセーフマット (ゴムシートみたいなやつ)を敷いて、その上にCDをセット。
最初のステップではカバー側のバフホルダーにハイパッドバフというのを取り付けます。ここでは研磨剤は使いません。
電源を入れて蓋を抑えて約30秒。おお、全体が曇った感じにw
ハイパッドバフ側には白っぽい削りカスがこびりついています。この汚れは、付属のスポンジに付属の研磨ミストなる謎の水を含ませて拭き取るようです。
次はフェルトバフでの研磨になります。CDの盤面に研磨剤を垂らしで指で適当に広げます (実はこんなに塗らなくてもいいのかも)
バフをフェルトバフに交換して同様に30秒ほど研磨。
いい感じかも?
さらにこの後は同様にバフをスポンジバフに付け替え、スポンジバフ用の研磨剤を塗布して、また30秒研磨します (実は、フェルトバフで研磨する前に、いきなり間違えてスポンジバフで研磨しちゃってたりするんですがw (写真はその時のもの))
最終的にこんな感じになりました。多少細かい傷は残っていますが、当初見られたガビガビしたものや同心円状の傷はまったく見られません。これならエラーなく再生できそうです (追記: 後日MPFでダンプしてみてC2エラーが出ないこと & 音飛びなどなく最後まで聴けることを確認しましたw)
それでは本命。盤面に傷があるせいか、データトラックでエラーが出てるけど、面倒で手研磨をしていなかったチェキッ娘の見るCDです。
このCD、盤面の外周付近に同心円状の傷がたくさんあり、以前MPFでダンプした際はC2エラーが出まくって、redump.orgのデータベースとも合致しませんでした。
研磨してみたらこんな感じに。同心円状の傷は見えなくなりました。
細かい傷は残ってますが、MPFでのダンプが完走。C2エラーはゼロで、チェックサムもredump.orgのDBと一致しました。やった。手研磨でもエラーなしまでは持っていけた可能性はありますが、かかる手間がまったく違いますね。10分そこらで終わるとか凄すぎるw
次はGD-ROMにチャレンジ。ドリキャスのセガラリー2です。
このソフトは手研磨で頑張って、ドリキャスのSamsungドライブの本体でダンプに成功してはいるんですが、リトライを取り切るまで頑張れませんでしたw。 盤面には、手研磨ならではのランダムな傷の下に、同心円状の傷が残っています。当時リトライが発生していたのはトラック23なので、位置的にこの辺の傷が関係していると考えられます。
ケンマくんmateで研磨したことで、手研磨の痕跡はなくなり、同心円状の傷も消えましたw。超きれいw
そしてリトライが多発していたトラック23もエラーなくダンプに成功。素晴らしすぎるw
GD-ROMも問題なくいけることが確認できたので、続いてNAOMIのぷよぷよフィーバーに行ってみます。
こちらは、元々Samsungドライブ搭載のGDドライブで普通に読めていたものの、ヤマハドライブのドリキャス本体では、手研磨してもエラーを取り切れなかったものになります。 NAOMIのGDドライブには、ヤマハのドライブユニットは使われていないと思うので、実用上は全然問題ないんですが、せっかくなのでw
ケンマくんのお陰でこちらもピカピカに。外周近くの傷もどこかに行ってしまいました。
改善したかどうかの検証のためにヤマハのドライブユニットを搭載したVA0本体を出してきましたw
リトライすら出ずに完走しました。凄い、凄すぎる!
この際、過去に手研磨した他のものも、色々とやり直しておきましょうw
[コメントを書く]
■基板
先日、NAOMIのDIMMボードのファームウェアにパッチを当ててみた際に、パッチの有無をバージョン番号で区別できなくて軽く混乱してしまったので、バージョンの書き換え方を確認してみました。
とりあえず 3.17 を見てみると、バージョン番号は、アップデータ側は先頭の方の8箇所と 0x7e4からの2Byteに、ファームウェア本体の方は 0x1a5206からの2Byteにあるようです。ここを3.18相当の値に書き換えて、後半 1MBのCRC32が0xFFFFFFFFになるように末尾の4Byteを調整したところ、無事3.18 としてアップデートできそうな感じになりました。
ちゃんとDIMM自身も、自分は3.18と認識してくれているようです。これでこの先、何かする際も安心かな。
[コメントを書く]
■ドリキャス
再研磨したぷよぷよフィーバーをVA0本体でダンプする際、VA0本体がなかなかhttpd-ackのCD-Rを読み込んでくれなくてハマったんですが、httpd-ackのバイナリをDreamShellと一緒にSDカードに入れておいて、プレスされたDreamShellのブートローダから起動させれば、CD-Rを経由せずに立ち上げられるのではないかということに気づき、試してみることに。
httpd-ackはMIL CDのイメージの他に、ELF形式のバイナリが配布されています。これをそのままDreamShellに持っていっても動かないんですが、binutilsで変換することで、DreamShellでも動かせるようになるようです。というか、同じこと考えてる人がいるようで、ここに変換手順そのものがありましたw
ここで使うsh-elf-objcopyは、Ubuntuの場合、SH向けのbinutilsのクロス環境のパッケージ binutils-sh-elf をインストールすれば入ります。上記サイトのコマンドそのままで、httpd-ack.bin ができました。
% sh-elf-objcopy -R .stack -O binary httpd-ack.elf httpd-ack.bin
あとは httpd-ack.bin を DreamShellの入ったSDカード上の適当なところにコピーしてドリキャス側に取り付け、プレスCDから起動させたDreamShellでFile Manager を立ち上げて、そこでhttpd-ack.bin を選んでやると・・・
そのままhttpd-ackが立ち上がりました!普通に使えます。凄い。CD-Rとの相性がいい670-10471F 1号機以外では、もう全部この方法で立ち上げることにしますw
[コメントを書く]
■ドンキーコングバナンザ
昨日、エメラルドラッシュの氷河の階層レベル7をクリアしたわけですが、なぜかセーブされていなかったようで、もう1回遊ぶことに・・・。もう絶対無理でしょと思いきや、コツを掴んだのか、あっさりクリアできてしまいました。しかもスコアも昨日よりアップしてるしw。でももうやりませんw
[コメントを書く]
2025年11月 2日 (日)
■ドリキャス
昨日色々いじったのとは別の、もう一台の 670-14071F (1号機) を動かしてみたところ、こちらはMIL CDのCD-Rの読み込み成功率が極めて高いことがわかりました。というか常に一発成功みたいなレベル。
昨日のやつとの良し悪しの差はどこからくるのか気になり、ドライブを交換して実験してみることに。
まず2号機のマザーに1号機のドライブを取り付けてみました。
CD-Rに焼いたDreamShellが一発起動しました。
次に1号機のマザーに2号機のドライブを取り付けてみました。
こっちはまったくダメですね。というわけで、認識率の良し悪しの差は、普通にドライブユニットに起因していると見て良さそうです。
VA2.1の場合、ドライブユニットの中にはモーターなどのメカ部分とレーザーくらいしかありません。
個体差を調整できるとしたら、このボリューム部分くらい?ここをいじることで、レーザーの出力を調整できるらしいです。
元の抵抗値 (750Ωくらい)からちょっとずつ下げていったところ、270Ωくらいで読み込みがたまにうまくいくように。その後、CD-RのメディアをRiTEKからMaxellに変えたら380Ωでもバッチリ読み込みに成功するようになりましたw
が、CD-Rの認識率が改善した一方で、普通のGD-ROMを認識しなくなってしまいましたw。どうやらCD-RとGD-ROMは、両立しないようですw。抵抗を元の値に戻して、調査は終了としましたw
プレスCDはレーザー未調整の状態でも普通に読んでくれるので、メディアの反射率の問題なんですかねー。昨日動かしたSD Rip等、未調整の状態でも読み込んでくれるCD-Rもあるにはあるので、CD-Rのメディアの良し悪しも関係しているのかもしれません。当時なら太陽誘電のメディアで試すとかもできたんでしょうけど、今となっては・・・。ちなみに、前述のSD Ripが書き込まれているメディアがどこのものか気になってImgBurnで調べてみたところ、CMC Magnetics Corp.との情報が。うーん、Verbaitmということ?
[コメントを書く]
■ドンキーコングバナンザ
エメラルドラッシュ、どうにか氷河の階層のレベル7をクリアできました。いやー、苦戦したw。ここは序盤のスキルの引きが悪いと全然ダメですね。
これで難易度5段階中の3というのがまた恐ろしい。この先どうなるのかw
[コメントを書く]
2025年11月1日 (土)
■基板
先日、初期型のTriforceで起動できなかったバーチャストライカー4を、後期型のTriforceで試してみることに。
無事起動しました。良かった良かった。
バーチャストライカー4 Ver.2006も起動してくれました
念のため、初期型Triforceでバーチャストライカー4 Ver.2006の方も立ち上げてみましたが、例によって「ファームウェアのバージョンがゲームの要件を満たさないからアップデートしてね」というメッセージが。
とりあえずアップデートを進めてみます。
一応終わりました。
が、再起動しても同じ状態にw
うーん、やっぱりバーチャストライカー4系は、初期型Triforceだと動かないということなのかな。まあ、後期型が手元にあるので困ることは特にないんですが、ググってもその辺の話が見つからないのがちょっと気になりますw
[コメントを書く]
■ドリキャス
NAOMIのGDドライブでCD-Rの認識率がいいやつとそうでないやつがあったので、ひょっとしてドリキャスでも同じなのかなと思い、うちにあるNAOMIのGDドライブと同じドライブユニットを搭載している VA2.1 基板の本体 (670-14071F) の2号機の方を引っ張り出してきました。
が、この本体、CD-Rどころか、プレスのMIL CDすら起動してくれません。なぜだ・・・。
まさか、外側は670-14071Fだけど、中身は670-14071G (VA1基板のMIL CD非対応タイプ) のニコイチ個体だったりして・・・? というわけで開けてみましたが、ドライブユニットからフラットケーブルが生えているタイプなので、VA2.1基板の本体で間違いなさそうです。(追記: このとき一度開けてましたw)
基板にもちゃんとVA2.1って書いてあるしw
が、BIOSを見てびっくり。型番が MPR-23588-X2 じゃないですか。このBIOSは、MIL CDへのアクセスがソフト的に封じられているタイプで、670-14071G に乗っているのと同じやつです。うむむ、670-14071F 本体にもこのバージョンのBIOSが乗っているやつがあったとは・・・。
とりあえず剥がします。
MX29LV160TMCに1個前のリビジョンのBIOSを書き込んで貼り付けました。
無事MIL CDのゲームが起動するようになりました。よかった。
せっかくなので、DreamShell経由でBIOSの書き換えができるかどうかも見ておこうと思います。VA2.1基板の改造情報は見つけられなかったんですが、VA1基板のときと同じなら、フラッシュメモリ (29LV002TC) のWEと同じところに配線しておけばおそらくOKなはず。というわけで、配線を追ってみたところ、315-5640の横のチップコンデンサのところから取れそうな感じです。とりあえず配線してみました。
後はDreamShellを起動して、書き換えられることを確認すればOKです・・・。って、DreamShellのブートローダーから、シリアルポートの先のSDカードが見えないんですが・・・。
SD Ripからも見えません。
うーん、SDカード自体はちゃんと接続されているんですが・・・。
まあ、気になるところではありますが、今はCD-Rの認識率の差を見るのが目的なので、調査はまたいずれ。ちなみにこの本体、CD-Rの認識率も超悪いです。色々とダメだw
[コメントを書く]
2025年11月30日から2025年11月1日までの日記を表示中
トライフォースってモニターによってテストモードで設定変える必要あるんでしょうか?
例えば、バーチャ2ならCRTとプロジェクターみたいな感じで。
プロジェクタかを選べるんですね。
Triforceにそういう設定があったかどうかは記憶が
定かではないので、今度起動した際に確認してみます。
ただ、バーチャ2の設定がメガロ/メガロ2筐体向けの
ものだと考えると、Triforceの時代には、その手の
設定は廃止になっていそうな気も・・・。
また、15kHzか31kHzかの切り替えは、ディップスイッチで
可能だったと思います。そして15kHzにすると、
480iで映像が出力されるようになったような覚えが
あります。が、これもちゃんと覚えてないので、
今度起動した際に確認してみます。
15kHz DIPにあるんですね、できないと思ってました。
バーチャ2のプロジェクターとCRTの設定は、アストロシティだと、プロジェクタにしないと白飛びします。てっきりCRTだと思い込んでしばらくプレーしていたんですが、変えてみて、色が濃くなって引き締まったのでビビりました(笑)
今、バーチャストライカー4をどうやって2人用するの???ってなってます汗
なるほど・・・。
Triforceのテストモードを確認してみましたが、そういった
ビデオ信号まわりのメニューはなさそうでした。
もしかして色がおかしい感じなんでしょうか。