#14 武蔵まとめ（その１）（２００６－０１／３０）
＜まだ書きかけ＞
■今日は、ＭＡＭＥ０．３５のコンパイルをして、
ＭＡＭＥ０．３５内のＭＵＳＡＳＩ２．０ＡにＣファイルを生成させ、チェック等してました。
■「ＭＵＳＡＳＩ」について、だいぶ把握できたので、現在判明した知識をまとめておきます。
用語の定義：（注意：正式な用語の定義ではありませんが、このページではこの定義の用語で統一します）
１． 「ｍ６８ｋｍａｋｅ．ｃ」（「ＭＵＳＡＳＩ」生成のＣプログラム）と
「ｍ６８ｋ＿ｉｎ．ｃ」（「ＭＵＳＡＳＩ」生成の設定ファイル）を
合わせて「ＭＡＫＥ６８Ｋ」と呼ぶ事にします。
２．「ＭＡＫＥ６８Ｋ」をＣ言語の稼動するコンピューター（一般的にはＤＯＳ／Ｖ）で（ＯＳは何でも構わない）
コンパイルし実行させると以下のファイルを「ｍ６８ｋ＿ｉｎ．ｃ」の設定に従い生成します。
「ｍ６８ｋｏｐａｃ．ｃ」（命令コードＡＣ系の処理プログラム）と
「ｍ６８ｋｏｐｄｍ．ｃ」（命令コードＤＭ系の処理プログラム）と
「ｍ６８ｋｏｐｎｚ．ｃ」（命令コードＮＺ系の処理プログラム）と
「ｍ６８ｋｏｐｓ．ｃ」（ＭＵＳＡＳＩ起動時の初期設定プログラム）と
「ｍ６８ｋｏｐｓ．ｈ」（ＭＵＳＡＳＩが使うヘッダファイル）を
合わせて「ＭＵＳＡＳＩ」と呼ぶ事にします。
３．「ＭＵＳＡＳＩ」にＭＵＳＡＳＩとの「６８０００用のインターフェイス」（６８Ｋ用の接続ファイル）を
追加し、コンパイルすると、エミュレーター等でＭＵＳＡＳＩが動作可能です。
■ＭＵＳＡＳＩの原理
ＭＡＫＥ６８Ｋ
■入手ファイル経路（「→」は、現時点で、管理人が、いるかいらないかの区別。）
表記が同じＭＵＳＡＳＩ３．３となっていても複数のＶｅｒがあるので注意。詳しくは
ここ。（このページは詳しいけど、生成後のファイルを比較しているので、少しピント外れ。
生成前のファイルを比較しないと。駄目ジャンってのはやってみてから気がついた。）
（最新版なのに、２００１年から２００６年まで進化しない訳がない。）
○ＰＳＰ版、ＤＧＥＮ１．００ＳＲＣ（２００５年）「dgen_psp_100src.zip」(870,176[bytes])
ttp://syn-k.sakura.ne.jp/dgen_psp/dgen_psp_100src.zip
ＳＹＮ＿Ｚ様のＨＰ内にある。
。ＭＡＫＥ６８Ｋ「」「」→どちらか一方がいる。（→新コアを作るなら参考にする）
。ＭＵＳＡＳＩ２．０Ａ「」（この武蔵はＭＡＭＥ０．３５ＳＲＣとほぼ同じ物。）→いらん。
○ＭＡＭＥ０．３５ＳＲＣ（１９９９年７月４日）「」過去のこのＶｅｒが（チェックに）必要だった。（ＭＵＳＡＳＩ２．０Ａ）
ttp://www.mame.net/oldmame.html
。ＭＡＫＥ６８Ｋ「」「」→どちらか一方がいる。（→新コアを作るなら参考にする）
。ＭＵＳＡＳＩ２．０Ａ「」（この武蔵はＰＳＰ版ＤＧＥＮ１．００ＳＲＣとほぼ同じ物。）→いらん。
○ＭＡＭＥ１．０３ＳＲＣ（２００６年1月）これは世界最新のＭＵＳＡＳＩ３．３。
ttp://www.mame.net/downmain.html
。ＭＡＫＥ６８Ｋ「」「」→いる！（→新コアを作るなら参考にする）
。ＭＵＳＡＳＩ３．３「」（この武蔵はＶｅｒが最新。現時点２００６－０１／２７）→いらん。
○ＰＳＰ版、ＮＥＯＧＥＯ_ＣＤ_０．５ＳＲＣ（２００５年）「neocdpsp-0.5.src.zip」
http://yoyofr.fr.st/ （javaスクリプト有効でないと、駄目かもしれない）
（上部のツールバー「Projects」から「pspNEOCDPSP」を選択し、
「Download - Binaries / Sources」のソースを選択しＤＬ）
。ＭＡＫＥ６８Ｋ「」「」→いらん。
。ＭＵＳＡＳＩ３．３「」（この武蔵はＶｅｒが古い。クロック周りのバグがある。）→いらん。
。Ｃ６８Ｋ「」「」→保留。（→要、クロック周りの正当性チェック）（→新コアを作るなら参考にする）
☆気になる事。
∇お魚さんの奴は、まだファイル開けてすらない。[MDP022s.zip]
新コア（ＰＳＰでのみ動作が速く、クロックバグはＭＡＭＥ１．０３のＭＵＳＡＳＩ３．３準拠）を作るのなら、
これも調べないと、もぐり。
∇sougenさんのPSPGenesisもソース落としてどっかにあった筈。
ttp://psp-news.dcemu.co.uk/pspgenesis.shtml [PSPGenesis-v0.15(Source).zip]
これも調べないと、もぐり。
∇そおいえばGensも調べないと。
（仕方ない、今日どれかやるか）
ｙｏｙｏＦｒについて、Ｆｒがついてるからピーンと来たかも。そう、おフランス。
ＤＧＥＮも、おフランスだし、Ｇｅｎｓはドイツだし、ノルウェーはハッカーの国だし。
おぃ日本。メガドラ開発しても、負けてるＺｏ。→ごめんなさい、いい過ぎです。
ＮＮＮＮＮ
ＮＮ
ＤＤＤＤＤＤＤ
ＤＤＤＤＤＤＤＤＤ
ＤＤＤＤＤＤＤＤＤ
ＦＦＦＦＦＦＦＦ
ＦＦＦＦＦＦＦ
ＦＦＦＦＦＦＦＦ
ＩＩＩＩＩ
ＩＩＩＩＩ
ＩＩ ＩＩ
すごくいいかげんなヨーロッパ地図。
ファイルのＶｅｒｓｉｏｎ
■ＰＳＰで実行する場合のメリット／デメリット。
☆yoyoFr_ＰＳＰ_ＮＥＯＧＥＯＣＤ内のＭＵＳＡＳＩ３．３
メリットなし、速攻で「ＭＡＭＥ１．０３ＳＲＣ内のＭＵＳＡＳＩ３．３」に置換せよ。
（但し、違いはクロック周りのみ）
☆ＭＡＭＥ１．０３ＳＲＣ内のＭＵＳＡＳＩ３．３
メリット：世界最新のＭＵＳＡＳＩ。現時点でもっともクロック周りのバグが少ない。
デメリット：ＰＳＰで実行させると、実装上の問題からか、重い。
ＰＳＰ_ＤＧＥＮ１．００で乗せ変え実験をすると、約１０fps程度のパフォーマンスダウン。（Ｖｓｙｎｃなし）
☆ＭＡＭＥ０．３５ＳＲＣ内のＭＵＳＡＳＩ２．０Ａ
☆ＰＳＰＤＧＥＮ１．００ＳＲＣ内のＭＵＳＡＳＩ２．０Ａ
上記２つは、ほぼ同じもの。
メリット：ＰＳＰで実行させると、ｆｐｓ測定では速いっぽい。（が、本当は速くないかも知れない）
デメリット：クロック周りがバグだらけなので、本当に速いのか信用がない。
（単に設定クロックより命令を少ししか実行できていないので、
結果的に速そうにfpsの結果が出るだけという可能性がある。
実際はＭＵＳＡＳＩ３．３と、それ程差がないのかも知れない。
クロック周りのバグが山盛りの現状ではｆｐｓベースでは性能が算定できない。）
ここから、先を読んで全て理解出来るのならば、
もう一般人ではありぇません。マニア！
何故、こんなにクロック周りのバグが（２００１年にもなって）山盛りかというと、
そもそもモトローラーの蒔いた公式資料（データーシート）が
クロック表記がめちゃくちゃ（実機と全然違う）だからだ。
それでも２００１年になって、解析が進み、実機との差が少なくなっては来た。
これは、２００６年になって、さらに解析が進んだという事だ。
（マニアご用達な、「シフト系命令」は実は「可変クロック」に、対応してきた）
２００１年ごろは、マニアでは常識の「裏クロック仕様」。これはいろんな人が実機で解析したもの。
は、かなりＭＵＳＡＳＩ２．０Ａで、取り込まれたので、客観的にみて、そこそこの完成度はある。
が、２００６年になって、さらに解析が進んだ事により。もっとちゃんとゲームが動作する様になった。
現時点のＭＵＳＡＳＩ３．３でも、まだクロックにバグがある。
たとえばＤＩＶ（６８０００の割り算命令）は、割る値によって、著しくクロックが変わる嫌な命令だが、
ＭＵＳＡＳＩ３．３では対応していない。（最悪値になる）
この系統の命令は、もっと速く終わる可能性がある。ＭＵＬ（掛け算系）も同様だ。
まあこの手の命令はタコなソフトでしか（重要な部分では）使用していないし、
（普通は初期化とか計算速度を問わない部分で使用する。一度でもデーターシートのクロック欄を
見たことのある人ならば、つまりまともなプログラマーならば）
割り算命令におもいっきりバグがある。（エミュレータが落ちる）Ｇｅｎｅｃｙｓｔでさえ、
あれだけ沢山ゲームが動くのだから、
この辺はこだわる理由がないのだけれども。実機とは確実に違う部分だ。
でも、Ｇｅｎｓがあれだけ動くんだから、きっと必要ない。
「ソーシャルキングダム」はＧｅｎｅｃｙｓｔで（魔法使いの沼のイベントで）落ちるから、（アドレスが表示される）
ＲＯＭの割り算命令の部分にパッチ当てて、Ｇｅｎｅｃｙｓｔで、最後まで遊びました。
あの部分の割り算命令は、（確かＤＩＶＳ）どうもあまりに割り算がとろいから簡易ウェイトとして、
使用してるだけです。取っ払って（ＮＯＰにして）も、ゲーム進行に全然影響がない。
最近のＭＵＳＡＳＩ３．３ではシフト系の可変クロックに対応してきた。（シフトする値によってクロックが変わる）
６８０００内部では割り算も掛け算もシフトと加算を組み合わせて実行しているだけなので、
（マニアが実機で測定し割り出した事実。これは１９９０年ごろだ。確か）
割り算アルゴリズムの解析が進めばＭＵＳＡＳＩ３．３でも対応してくるかもしれない。
クロックの値は、数種類しかない事が判っているので、シフトアルゴリズムを元に特定できれば、
テーブル化すればいいだけなので、簡単だ。
だが、肝心のシフトアルゴリズムの詳細が、判明していない。
これは、とりうる引数すべてについてクロックを特定する。
（たくさん同命令をならべループさせ、測定、後でループ分のクロックを引く）
ので、測定に膨大な手間。がかかるし。
（一つの数について最低５分ぐらいは、実機で測定しないと確定しない。
全数測定するのならば、プログラム展開時間を０として計算しても、
（３２ビットは４２９４９６７２９６らしいから）「（４２億）掛ける（４２億）掛ける（５分）」
測定だけで何年もかかる。全数測定など非現実的だ。）
だから、結果を元にアルゴリズムを推測し、アルゴリズムを組み。
シフトの変わり目がクロックの変わり目なので、その近辺だけ、集中的に測定し、
推測したアルゴリズムの正当性を検証する必要がある。
いずれにしても、手間がかかるので２００６年現在、詳細はまだ判明していない。
腕に自信のあるハッカーはぜひチャレンジしていただきたい。
