バブルシステムの情報

Charlesさんページにバブルシステムについての解析が載っています。


2007年のことになりますが、私とGuru氏でKonami Bubble Systemの基板についていくつかテストを行いました。ここで、その動作の仕組みについて忘れる前に説明しておきたいと思います。

システムは128KのワークRAMをDRAMとして実装した68000を使用し、最初の4Kは2個の2Kx8 SRAMチップで置き換えてある。SRAMは正体不明のMCU(64ピンSDIP)と共有されていて、必要に応じて読み書きを行っている。このMCUは68000を停止させることが可能で、バブルメモリと直に接続されている。68000がセクタリード/ライトのリクエストを出すために使われる、専用のハードウェアレジスタが$40000にある。MCUは共有RAMの$F00-$F7Fをこのリクエストに対するセクタバッファとして使用している。

パワーアップリセット後、MCUは68000に実行させるベクタテーブルとブートプログラムを共有RAMに書き込む。Guru氏はこのプログラムがゲームプログラムに上書きされる前に取り出すため、SRAMをNVRAMと置き換えた。その結果が次の通りである:

  • 一定時間待つ
  • ウォッチドッグを始動する
  • MCUが取得したデータを14C-D00よりコピーする。これは不良セクタのビットマップで304バイトと思われる。128バイトの各セクタ毎に2432ビット、または合計で304Kである。各セクタは実際には132バイトだが、使えるデータは128バイトである。MCUがRAWセクタをRAMに書き込んだ後、BIOSが不要データを切り取る。
  • オフセット$78000が$5555の場合、$78002に飛ぶ。これは、ドーターボードコネクタに接続した外部EPROMに該当する。おそらくは開発用だろう。
  • バブルメモリのセクタ$001、$001、$801を読み込む。このデータは使用されない。たぶんこの後の本番アクセスに備えたダミーリードと見られる。セクタ番号のビット11が特別な目的を持つかもしれない(例えば、セクタ$001と$801が同じなど)。
  • セクタ$181からRAMの$10000へ8セクタを読み込む。このとき、132バイトのRAWセクタを128バイトセクタにコンバートする。
  • バブルメモリから最初のゲームプログラムを1K読み込んだところで、$10000にジャンプする。これはRAMのなかでMCUと共有されていない箇所。

この時点からゲームが動作し始め、セクタからメモリへの読み込みを継続しながら、ゲーム固有の命令を実行する。ワークRAMの下位4KにはシンプルなBIOSがあり、#0がセクタ読み込み、#1がセクタ書き込みのトラップをする。しかし、ゲームがハイスコアなどをバブルメモリに書き出していたかや、セクタの書き込みがRAWフォーマットかそうでないかなどは不明。

保存とエミュレートという目的から言えば、各ゲームのバブルメモリー内データを全て読み出すことがゴールと言える。これを行うためには、68000でトロイの木馬を実行させ、MCUに対してセクタの読み込みをさせる必要がある。68000のプログラムコード自体もバブルメモリーから読み込んだり、MCUの内部ROMからコピーする必要があるため、独自コードを実行するのは簡単ではない。SRAMをROM(この場合書き込み不可にしたNVRAM)と置き換えると、起動時にMCUがデータの読み込みをしなければいけないため、正常に起動しないと思われる。そのため、ドーターボードのコネクタを使用するのが残された手段のようだ。

シグネチャの確認を行ったり、68000の実行コードを記憶させたカスタム基板をドーターボードに取り付けることができるかもしれない。また、NVRAMやUSBインタフェースなどを追加して、セクタの読み込みに応じて保存させることも考えられる。他には、68000をフルークモジュールと置き換え、起動プログラムがバブルメモリーから読み込まれたプログラムに制御を移したときに一旦ブレークし、そのアドレスをトロイの木馬で上書きする方法もあるだろう。

いずれ、正確な動作のためにはMCUの腑分けや解析、読み出しが必要になると思われるが、バブルメモリーのゲームは大変希少で高価なため、基板にアクセス可能で、しかもこのような作業に対するリスクを冒す人を探すのは難しい状態である。当座は、バブルメモリーの吸い出しとMCUのシミュレーションで差し支えないだろう。

Charles MacDonald's Home Page

前の記事
次の記事