MAMEが今日で10周年を迎えました。同時に記念リリース0.112が出ています。what's new-Jはこちら。mame.devサイトもリニューアル、全リリースのソースとバイナリ、Wikiを使った開発者による未動作ドライバの情報ページも新設されました。さらに、R.Belmont氏が10周年記念復刻版 MAME 0.1も作成しています。pdf版の開発グラフはこちら。
ここはMAMEなどの海外情報の訳を扱っています。
バグ情報は MAME Testers を日本語化したものです。
訳は全て非公式なものです。このページによるトラブルについて、筆者は一切責任を負いませんので予めご了承願います。
バグ情報は MAME Testers を日本語化したものです。
訳は全て非公式なものです。このページによるトラブルについて、筆者は一切責任を負いませんので予めご了承願います。
Fujix
MAME10周年 ＆ 0.112出た
M1 v0.7.7u2出た
M1のクイックフィクス版が出ました。u1からの変更点は次の通り。
- モノラル出力を左からセンター出力に変更
- m1.xmlのエラーを修正
- tnzsを削除。tnzsjが内容的に同じできちんと動作するため
- 最新のNeoGeoサンプル暗号化に対応。kof2003、mslug5、svcpcb、samsho5、samsh5spに対応
- 動作していないテスト用ドライバのゲームを削除
- pacapp2追加
- c74.binのCRCを修正
Linux用のPPC版はプレステ3でも動く模様。日本語のゲーム名ファイルはこちら。
M1 v0.7.7u1出た
アーケードサウンドエミュレータM1の新版が出ました。外部ファイルで全てのゲームの定義を行うように変更、またTaito F3の改良（曲番号が変更されています）、チャンネル毎の音量操作が可能になりました。BridgeM1はそのまま動作しますが、チャンネル毎の音量調整には後ほど対応予定です。日本語のゲーム名ファイルはこちら。解凍してlists\jp\に配置します。
0.111u6出た
0.111u6のソース差分がリリースされました。what's new-Jはこちら。
0.111u5出た
0.111u5のソース差分がリリースされました。what's new-Jはこちら。CPS2は3本（spf2t、spf2xj、spf2ta）を除いて全てXORが外されました。これまでXORが無かったものもかなり動作可能になっています。また、BDFの読み込み時間対策としてキャッシュ保存機能が追加されています。
アレック64 WIP
Ville氏ページが更新、アレック64の進捗状況が出ています。MAME内での64エミュレーション自体はほとんどできあがっているので、少しの作業で対応できたそうです。スターソルジャーとビビッドドールズのスクリーンショットが出ています。
0.111u4出た
0.111u4のソース差分がリリースされました。what's new-Jはこちら。UIでUTF-8として文字描画をするようになったため、英字以外を表示するには「ユニコード対応のbdfフォント」が必要です。いいのを募集中。
【更新】24x24ドットのフォントでテストしたところ、起動に3分以上かかりました。いまのところ実用的ではない感じです。
とりあえずフォント
UIがUnicode対応になりましたが、普通の日本語フォントでは読み込みに時間がかかりすぎるため、必要な文字だけを追加してみました。といっても「上、下、右、左、軸、矢印、ボタン」だけです。とりあえずこれで表示は問題ないと思います。使い方は解凍してMAME本体と同じところに置くだけです。足りない文字を発見されましたら掲示板へお知らせを。
【更新】「無、変、換」を追加。
【1/24更新】MAMEのUIでは使わない記号や文字を削除（約1500字）。読み込みがかなり早くなります。「テ・キ・ー」を追加。
CPS2との戦いは続く
ということで、ニコラさんがXORでサポートされている既存のCPS2ゲームのチェックしたそうで、あるアドレスに7つ以上の(E,D)ペアがあれば数時間のアタックでキーが見つけられる模様。11本でアタックがうまくいかず、そのうち3本ではペアが2つしかないので別なアプローチが必要とのこと。ペアが4つのものについては裏技を使ってなんとかアタックできる見込みとのこと。
Haze氏WIP更新
Haze氏の個人WIPにマジカルキャットアドベンチャーの更新が出ています。Testersで出ていたラインスクロールを実装しています。
アーロンさんのクリーンアップ計画
去年一年間はドライバのクリーンアップを進めたAaron氏ですが、他の開発者にも役立つように作業予定のチェックリストを公開しています。
タイミング・割り込み：
- 基板の全てのクリスタルを#defineで記述
- 全てのCPUとサウンドクロックを#defineの周波数から生成
- 割り込みの発生タイミングと、発生元を再確認
- 割り込みのACK実装
- 正確なウォッチドッグ有効時間の追加
メモリ：
- リード・ライトメモリマップの統合化
- 完全なアドレス空間のマッピング。可能ならば回路図から
- 適切な場所ではAM_SHAREを使う
- メモリバンキングを新システム(memory_configure_bank)に変換する
グラフィック：
- レイアウトで可能なところでは決め打ちした値にあけてRGN_FRACを使う
- 共通のレイアウトは共有する(vidhrdw/generic.c)
- hblank・vblank・表示領域を正確にする。可能なら回路図から
- ディスプレイ情報を旧マクロから新マクロに変換
- 水平・垂直位置用により正確なタイミングルーチンを使う
- 適用できるところはタイルマップに変換する
- パレット生成にレジスタを使うよう変更する
- わかっているものについてはスプライト表示の最大数(スキャンライン毎にいくつかなど)を追加する
入力：
- 全入力ポートのタグ付け
- コード内のポート参照を全てタグを使うようにする
- 非DIP設定をconfigに変換する
- 適切な場所ではメモリオーバーライドに代えて、PORT_CUSTOMを使う
- コインカウンタを正確にする
- 基板出力を新出力システム経由で接続する
- DIPLOCATIONSを追加する
- DIPスイッチと入力の検証
ROM：
- メモリ領域を必要最低限にする
- ROM名が妥当・正確か調べる
- 未エミュレートのクローン版がないか調べる
その他：
- ソースファイルの整理： header, includes, constants, typedefs, macros, globals, inlines, code
- ドライバファイルを次の順に統一： address maps, input ports, graphics definitions, sound configs, machine driver, ROMs, driver init code, drivers
- セーブステートサポート
- グローバル変数を全てdriver_dataの後ろに移動
- ぐちゃぐちゃのコードをわかりやすくする
64bit MAMEベンチマーク
Aaronさんが64bitビルドを中心にパフォーマンスの徹底比較されています。VC対GCC、VCの最適化あり対なし、-mtオプション、32bit対64bitなどなど。特に、デュアルコア環境での-mtはタイトルによっては約3倍、平均でも41%もスピードアップしているのが目立ちます。GCCとVCでは、リッジレーサーとスターウォーズ以外は5%程度の向上、64bitでは3Dゲームで大きく向上しています。
0.111u3出た
0.111u3のソース差分がリリースされました。what's new-Jはこちら。Unicode関係のトラブルの修正、CPS2更新、その他OSDの大幅変更が入っています。
CPS2 coming to MAME
ということで、ニコラさんが4GBのCHDを192bitのキーに置き換えるためのコードをDevに提出されました。サイトからもコードをダウンロードできます。まだSボックスの動作について不明な点が多く、キーもオリジナルとは異なるとのこと。腑分けしたCPS2チップの写真からSボックスの内容がつかめるかもしれないそうです。この次は、XORしかないゲームからのキーの割り出しにチャレンジする模様です。
「CPS2基本動作解明」
との書き出しで、ニコラさんまたまた更新。動作の基本的な部分が判明、96bitのキーx2にまでたどり着いた模様。アルゴリズムは1)16bitのアドレスと96bitのキーで最初のフェイステル構造を通して16bitのサブキーを生成、2)16bitの暗号文、16bitのサブキー、もう一つの96bitのキーで2回目のフェイステル構造を通し、16bitの平文を生成するとあります。だだし、喜ぶのはまだ早いそうで、1回目のフェイステル用Sボックスの完全な割り出しが必要で、これができて初めて、8GBの完全なテーブルがあるタイトルについてはキーを求められるそうです。
一方で完全なテーブルが無いものは、キーがもっと小さかったり、ビットの再利用の可能性があるものの、それがどれくらいかはわからないので、最大で192bitのキーとして対応しなけらばいけないそうで、このサイズでは総当たりは問題外、XORの情報があったとしても差分攻撃ができる類ではないだろうとのこと。
【訂正】96bitが2つに訂正。
「CPS2はそんなに甘くない」
との書き出しで、ニコラさんの更新。4GBのサイズだったテーブルは128kBまで小さくなったものの、ハードウェアの実際の動作が解明されたわけではなく、オリジナルの8GBテーブルが無いゲームについては、まだキーを生成できない状態とのこと。
0.111u2出た
0.111u2のソース差分がリリースされました。what's new-Jはこちら。今回よりUnicodeファイルのサポートが追加されましたが不具合が出ているようです。まず、-cheatを有効にすると起動時に固まるバグがあります。また-ccでutf-8のmame.iniを出力するようになりましたが読み込めないので、Shift-JISなどに戻す必要があります。
CPS2でブレイクスルーか
スペインのAndyさんがCPS2の解析で進展があった模様です。にこらさんも合わせて更新しています。えーと、手短に言うと「今4GBあるテーブルファイルのサイズが768kBになるかもしれない」ということだそうです。
恭喜新年發大財!
あけましておめでとうございます。みなさんにとってよい一年になることを心よりお祈りしております。今年もよろしくお願いします。
Ville氏WIP更新
Ville氏のWIPがクリスマス更新。Taito 3Dハードがかなり進んできています。サイトによると、
Taito 3Dハードウェアの一番の特徴といえば、演算コプロセッサがカスタムチップの一つに統合されていることです。このコプロセッサは2つの役目があります。ひとつは、3D座標の2Dへの透視変換で、DSPの逆アセから簡単に割り出せます。もう一つは、かなりの難題だったのですが、ポリゴンとビューポートの交差座標の演算に使われていることがわかりました。
もう一つの演算ユニットが必要な理由が最初の頃はわからなかったのですが、演算処理を調べているうちに、どうやら何かの除算をしているのがわかってきました。さらにデータシートによればTMS320C51には除算ユニットが全く無いことも判明しました。
これらのTMS320C51のバグ修正により、3D描画はほぼ完全になっています。
0.111u1出た
0.111u1のソース差分がリリースされました。what's new-Jはこちら。
コラ氏のCPS2解説・その4
Nicola氏のCPS2解説つづきです：
この暗号解析は全く進展がありません。これまで説明してきたことは、もう1年以上前からわかっていることで、それ以来突破口が開けてないのです。もしかしたら、オープンにもっと多くの人が議論し合えば、貴重なフィードバックが得られるかもと思っています。
CPS2の暗号をハードウェア側以外からアタックしようとうする人はいないようです。個人的には、アルゴリズムの情報をさらに集めるにはハードから攻める以外にないと思っています。
ここまで説明してきた特徴は、キーの値がなんであっても常に成り立つものです。ですから、これがアルゴリズムそのものの特徴であり、ハードウェアに決めうちされたものと言えます。たとえば、カスタムCPUから抽出可能で、固定のsubstitution用のボックスがあるのはほぼ間違いありません。
CPUを解析してアルゴリズムを再構成すれば、キーの値にかかわらず既知の特性にマッチするかテストできます。これが一致しなければ、そのアルゴリズムは間違っています。一旦、適合するアルゴリズムが見つかってしまえば、キーの検索を始められるでしょう。
コラ氏のCPS2解説・その3
Nicola氏のCPS2解説、まだまだ続くよ：
Part1では暗号テキストのビット反転についてでしたが、ここではプレーンテキストでのビットについて見ていきます。
次の表は、パーセンテージではなく、ビットの変更回数の合計を16進数で示しています。
オレンジ色のはどのテーブルでも共通で変化しない値です。しかし、赤く示した値の方がおもしろい動きをします。これは、何種類かの値のうち一つになりますが、各列の2値の合計が常に一定の0x10000になります。
コラ氏のCPS2解析・その2
Nicola氏のCPS2解説、昨日の続きです：
相補的な特性が重要なのは、テーブルサイズが半分になるからというだけではありません。とはいうものの、この特徴を十分に活用しているわけではないのですが。
ここで、CPS2の暗号化についておさらいしておきましょう。
入力：
- ROMに保存された16ビットの値
- 16ビットのアドレス値 (1～17ビットの物理アドレス)
- ゲーム毎に変わるサイズ不定のキー
出力：
- 16ビットの復号化された値
ここでは、アドレスAにある値XをキーKとして、関数D(X,A,K)とします。相補的な特徴とは、どんなAについても必ず対応するA1が存在することです。つまり、
D(X,A,K) = D'(X',A1,K)
ということになります。
この発見が重要なのは、暗号化においてAがアルゴリズム的な影響を与えているからです。SegaのFD1094 CPUでは、各アドレスのキーは巨大なテーブルで保持されています。もしCPS2が同じ動作なら、相補的な特性は現われません。
これは特に驚くことではなく、Segaが巨大なキー＋シンプルなアルゴリズムを好むのに対し、Capcomは小さなキー＋複雑なアルゴリズムを好むことをKabuki CPUで見てきています。
残念ながら、AからA1を導く方法はまだわかっていません。ゲームによって変わるので、キーの関数であるのは間違いありません。
相補特性というのは、強力な暗号でも特別珍しいものではありません。ですから、アルゴリズムの欠点であるとは必ずしも言えません。たとえばDES暗号でも見られ、D(X,K) = D'(X',K') となります。
一般的に、相補特性はXOR演算が起きている兆候ともいわれます。相殺のために補数演算が起こるからです。例を見てみます。代理関数をfとして、次のようなアルゴリズムがある場合、
d = e XOR f(e XOR k)
補集合は
e' XOR f(e' XOR k') = e' XOR f(e XOR k) = (e XOR f(e XOR k))' = d'
とになります。もちろんこれはとてもシンプルな例ですが、この場合はx'が補集合でなくてもよいことに注意してください。たとえば、x' = x XOR 1と定義しても成立します。ですから、CPS2のアルゴリズムはこんなにシンプルでないのは確かです。
もっと現実的な例としてフェイステル構造（DES暗号はフェイステル構造を使っています）を挙げましょう。フェイステル構造を以下のように定義すると、
Li = R i-1
Ri = L i-1 XOR f(Ri-1 XOR Ki-1)
相補性がどのように出てくるかよく簡単にわかるはずです。
CPS2の暗号化がフェイステル構造を使っているという考えは確かに魅力的ではありますが、個人的には違うと思います。なぜならば、前回説明したデータの拡散がもっとよくなるはずだからです。