#11ＭＵＳＡＳＩ３．３の最新版のソースを手に入れる作業(2006-01/28)
■（注：このＤＧＥＮは１．００です。最新のＤＧＥＮはもっとず-----っと遥か彼方に進んでいます。
（現在本家の最新版は１．３０）
スキルがあり、開発をしたい方は開発者に直接コンタクトをとって下さい。
私は開発者とは全く関係のない第三者です。
あくまでこのページの話は実験用途（教育用）です。）
□今日はＰＳＰとあんま関係がない話なんだけど、全然関係がない訳ではない。
□一体最新版のＭＵＳＡＳＩはどういう事になってるのか、チェックしてみます。
（１４：３２、まだ全然やってない）
□まず、ＭＵＳＡＳＩの公式サイトは存在しないので、
ＭＡＭＥの最新版（１．０３Ｂ）から抜いてきます。（２００６－０１／２７時点、つまり昨日ＤＬした）
最新版は「ＭＡＭＥ０１０３Ｓ．ＺＩＰ」（約１１ＭＢ）です。
□大体こんな感じですね。
もちろん最終的にＰＳＰに乗せる事を考えています。
□今日、計画している作業は、ごく普通のマシン
（今日のターゲットＰＣはPentium3、0.766GHz。レトロだにゃ、
めちゃめちゃ改造してあるので、ＤＴＰだけど、最近のPentiumMノートぐらい静か）
で、極普通にＭＡＭＥをコンパイルするだけです。
最近のＭＡＭＥディストリビューションはＧＣＣ共に頭がいいので、バカでもチョンでもできます。
あ、Ｗｉｎ版はよく知らないんで、あくまでDOS版（Win-consoleで実行）のコンパイルの話です。
（最近のDOS版は理屈上は動く筈なのに、NativeDOSでは、DPMIサーバーとの兼ね合い
（相性というかバグというかで）で動かない場合があります。Win-console(ＤＯＳプロンプト)なら、
１００％動作します。が、WinＸＰは知らない。（っていうか多分駄目））
（昔１９９７年頃は大変だったんだよ。該当するAllegroライブラリが手に入らないんで、
何日もソースを書き換えてる間に次のＶｅｒ（数日で更新）が出てしまうという。）
□なんでこんな作業がＰＳＰと関係があるのかというと、単純にソースを取り出したいだけです。
でも手順として、多分このやり方が確実で一番早い。
１．まずＤＯＳ版ＧＣＣをいれる。
２．「最新版のＭＡＭＥ」のＭＡＫＥを書き換え、
ＣのＭＵＳＡＳＩを使うように設定し（多分）、（←そんなの今のＭＡＭＥでは無いみたい。
アセンブラ系のコアは削除されちゃってます。）
「何のゲームでもいいから、６８０００を使ってるゲーム」にし、
「タイニーコンパイル」する。
普通にコンパイルしたら、最近のＰＣでも時間の無駄です。（普通にやったら６０ＧＢ以上のソースだよ）
最近の3GHzぐらいのマシンでやれば、「タイニーコンパイル」なら、数秒で終わる筈。
普通にコンパイルしたら多分１０分ぐらいかな。（やってないから、わからん）
３．コンパイル終了したら、\src\cpu\68000と\obj\cpu\68000をもってくる。
この中の*.oのファイルは単なるごみだから消す。残りも全部消しても良い。
要は、（３．）の「\obj\cpu\68000」の中の*.c（自動作成されたＣのソースファイル）が必要な訳です。
判ったかな？
ＯＢＪにＣのファイルが自動作成される仕組みなんです。
じゃあやってみるよ。（２００６－０１／２８、１５：１６）
うまくいったらＭＵＳＡＳＩ２．０Ａもやらなくっちゃ。
まず、ＤＯＳ版の「djgpp-gcc343.zip」（１６．３ＭＢ）を解凍し、
カレント（C:\）辺りに移動。名前を少し短く「gcc322_27oct2004」して。（念の為）
ＤＯＳプロンプト立ち上げ、全画面にして（この方が速い）
「install↓」
これで、多分AllegroからSealから何から、
（うわ、ＮＡＳＭもＵＰＸもＤＰＭＩサーバーもあるよ）
面倒な設定はぜええんぶinstallしてやってくれます。
（Ｐｅｎ３の0.766GHzマシンで２分ぐらいって所でした。もちっと早かったかも）
細かいＶｅｒｓｉｏｎメモ：
（GCC322,Allogro4116,seal107p,nasm098-38dos_win,upx125dos_win,csdpmi5b)
(unz551x3,zvg_sdk11a）
ＺＩＰのライブラリはＭＡＭＥ本体のソースに含むみたいですね。
何処にも書いてないけれど、ＴＸＴＩＮＦＯとかもしっかりインストールされてます。
（ＴＸＴＩＮＦＯってのは単なるヘルプ。しかし昔のＭＡＭＥは、
これがないとコンパイル通らない時代があった。全然必要ないのに...）
インストール終了したら「SET↓」で環境変数が書き換わってるかチェック。
この時点でＰＣの電源を切ったら、多分環境変数が設定されてないから、
次回以降はコンパイルできないでしょう。（今すぐならできる。）
次回以降ＤＯＳ版ＧＣＣ（正式名はＤＪＧＰＰ）を使う気があるのなら、
ＡＵＴＯＥＸＥＣ．ＢＡＴに、
「SET PATH=C:DJGPP\BIN;%PATH%」と
「SET DJGPP=C:\DJGPP\DJGPP.ENV」の２行を加えると便利です。
専用のバッチにしてもいいし（使う時に実行）。手打ちでもいいんですけど。
どうせ忘れるし。
インストールが終わったら、さっき解凍した「gcc322_27oct2004」フォルダ（１５．５ＭＢ）は、
ゴミ（一時フォルダ）ですから、全部削除してしまいます。
（「何とか．ＺＩＰ」てのがいっぱいある奴）
こういう物をすかさず削除しとくのは重要です。なんたらＺＩＰっていかにも重要そうだし、
間違えてバックアップ取ってしまうと目も当てられない。しかも、なんだろ？とかいって、
ＺＩＰひとつづつ開けて調べるとかバカな作業（つまりは忘れてるからですが）始めると
時間がいくらあっても足りないです。これはさり気に危険物だと思って間髪入れずに
消しましょう。
えー１５ＭＢぐらいごみみたいなもんだから、どおでもいいジャン。とか思ったあなた。
全然判ってません。これが本当に忘れ去られると、結果的に何十ＧＢにも膨れ上がって
しまう事もある。から危険だといっているんですってば。（要するに、容量は本質的には
関係がない。無限の時間を吸い取る事が重要。危険物。要注意。）
元の「djgpp-gcc343.zip」があれば、いらないです。
っていうか元も（ＣＤに焼いとけばＨＤＤには）要らないです。
インストール先は強制的に「Ｃ：\djgpp\」（５０．１ＭＢ）です。
（これはこの世界では決まった約束事なので変えない方がいいです。
変えると設定で苦労する場合がある。環境変数見ないタコなプログラムとか）
ＧＣＣの設定は「C:\DJGPP\DJGPP.ENV」をテキストエディターで開いて、
書き換えればいいんですが、素人が弄る必要がないです。（私もいじった事ないです。）
ちょっと覗いて見たら「外部から書き換えるから直接弄るんじゃねぇ」って、
まるでVisualC++みたいな事が書いてありました。
きっと./Configureとかで書き換える事想定してるんだろな。
つまりはそういう時代みたいです。
☆やっとソースリストの解凍「ＭＡＭＥ０１０３Ｓ．ＺＩＰ」（約１１ＭＢ）を解凍して。
「ＭＡＭＥ．ＺＩＰ」（約６３ＭＢ）が出てきます。さらに解凍して、
「mame」フォルダが（６１．８ＭＢ）出来ます。
間髪入れずに、「ＭＡＭＥ．ＺＩＰ」（約６３ＭＢ）は削除です。
ほら！そこ、いいじゃん６３ＭＢぐらい。なんて愚痴垂れない！
これが迷走して増えた時の怖さを知らないんですってば。
俺のＨＤＤは４００ＧＢだぁ？４００ＧＢぐらい管理が悪いとすぐなくなりますよ。
ソフト開発ってのは日常的にこういう事の繰り返しで、でかいファイルがあっても、
だんだん必要か不必要か判らなくなってくる恐ろしい世界なんです。
例えば映画のファイルなら、１ＧＢあってもそれ以上でも、
見れば必要／不必要の判断が一瞬で付く。
下手したらタイトルだけでごみかどうか判る。
こういうものはＨＤＤにいくらあっても影響がない。
たとえ４００ＧＢのＨＤＤが全部埋まっても整理が楽チンです。（そもそも整理の必要がない）
ソフト開発関係のファイルは一見もっともらしそうで、ごみっぽくない分
無限にバックアップが繰り返されてしまう。本質的に嫌な奴らです。
一見もっともらしそうなもの「ファイル」は、危険物だと認識しておかないと駄目です。
なんだかよく判らんから、とっとけってのは、「本質的に管理技術がマイナスです」
ゼロじゃなくって、「実質損」ですわ。まあ、やってりゃ判る話なんですけど。
やってないと絶対に判らなくて、意味不明でしょうなぁ。
あ、「管理技術」って要するに「お掃除する技術です」。これはかなり重要な技術なんですよ。実は。
□えーとＤＯＳ版の「mame」フォルダの位置は、特にこだわりがないのならば、
カレントがいいです。（理由がある）複数mameを開発する気があるのなら、「c:\emu\mame」
とかにしておきます。設定ファイル（自動作成）の都合があるんですよ。
一度も動作をさせる前に、場所をきちんと決めておいた方がいいです。
一度動作させてしまったら、手で設定ファイルのパスを書き換えます。
ここでは「c:\EMU_WK\MAME103S」にしました。
「タイニーコンパイル」はmakefileを
# TARGET =tiny
TARGET =tiny
にして、コメントを外し、ＤＯＳ版なので、
# MAMEOS = msdos
# MAMEOS = windows
MAMEOS = msdos
# MAMEOS = windows
にし、
\src\tiny.mak
に好きな事書けば良いです。何を書くかというと、まず「ターゲットのゲーム」を
決めてその他の＊．makファイルから必要部分を抜いてくるだけです。
標準でチープなゲームが入ってるので、コンパイルできるみたいですが、
この辺、今回の目的と関係ないので、割愛します。
「でも自分のPCであのゲームMAMEで重くてやってらんない」ってのがあれば、
タイニーコンパイルで専用版を作成するだけで、見違える程早くなる場合があります。
参考まで。
さて、「タイニーコンパイル」ですが６８０００が欲しいだけなので、
「\src\tiny.mak」
CPUS+=M68000@
を追加するだけです。(この場合'@'は区切りの意味がある)
では、「c:\EMU_WK\MAME103S」に行って、（前記の環境変数がきちんと設定されている必要がある）
ｍａｋｅ↓
これで、待ってりゃうまくいく筈だったんですが、意外なことにエラーが出てます。
ＣＣ１、しらねぇオプション：「-Who-unused-functions」
ＣＣ１、しらねぇオプション：「-Wdeclaration-after-statement」
（今日は違うＰＣだからカット＆ペースト出来ないから、エラーの直訳です。）
要するに、ＧＣＣのＶｅｒが「新し過ぎる」か「古過ぎるか」どっちかなんですが、
判断がつかないです。本質にぜんぜん関係のないエラーなんで、
「makefile」を編集して外してしまいます。
まんなか辺のCFLUGS +=の中の２行をカットしてendifの下に
略
-Wformat-security \
-Wwrite-strings ←￥を外す
endif
# -Who-unused-functions ←￥を外す
# -Wdeclaration-after-statement ←￥を外す
# extra ...略
って感じで取っておきます。（後でどういう編集をしたのか証拠を残す為です。）
行末の￥は、次の行に続くという意味ですが、ｍａｋｅｆｉｌｅでは、不要な￥があると、
くっついて欲しくない所がくっついてしまいます。これはトラブルの元ですので、
不要な￥は、外しておきましょう。
って、またやりやがった
http://www.mame.net/zips/dm103s.zip
がないとコンパイルできない。
これは似た名前のうううんとふるいＶｅｒでもＯＫの筈。（１７：５３、とりあえずご飯、夕食）
■
（新兵器開発しますた）
「って、またやりやがった」って、読んでる人はなにが、やりやがったのか理解できないかも、
しれないですけど。
恐らく世界中どこ探してもＭＡＭＥ用の「dm103s.zip」なんて、ファイルはこの世に存在しないです。
これは、ＭＡＭＥのＤＯＳ版を苦労して（何度か）コンパイルした人でないと、判らない事です。
ホームページはエディターの一括置換か、スクリプト（たぶんこっちの可能性が高い、しかも多分perl。）で、
自動生成してるから、あういう事になってるんだと思います。
あのページは多分。
元の設定ファイル→（自動生成スクリプトで変換し、ＵＰ）→
契約サーバー→（サーバー上で広告をインクルード）→表示。
という流れになっていて、（証拠がある。特に「width=510」の辺、解かる人にしか判らないネタかも。
広告を外して「width=510」を少し広げてみれば意味が判る）
perlスクリプトでVer番号をはめ込んでいるだけです。（多分ね）
ああ、一番楽チンな方法だと思ったのに。
これならＭｉｎＧＷ入れて素直にＷｉｎ版コンパイルした方が早かっただろな。
しょうがない。管理人秘蔵の五年前のソース探してきて、６８０００だけ入れ替えるか。
ＳＲＣ￥ＭＳＤＯＳ￥以下をここにコピーすれば、多分コンパイルとおると思う。たぶんね。
（dmXXX.zip）は５年前のでも通ると思うよ。でも最近のソースは「ＶｏｏＤｏｏ」ネイティブで
サポートしてるみたいだね。
ＭＡＭＥで使う限り、「ＲＡＤＥＯＮ９８００ＰＲＯ」でも「ＲＡＤＥＯＮ」の最低機種でも、
対した違いはないって知ってた？（ＧｅＦｏｒｃｅも同様）
そりゃバス転送速度が違う分は、違いがでるけれど、
それ以外「３Ｄ」を一切利用しないので、（たとえ見た目は３Ｄバリバリのゲームでも）
２Ｄのスペックのみが重要。（アルファブレンディングもアンチェィリアスもスペキュラーも、
もちろん３Ｄ関係のもろもろもぜえんぶＭＡＭＥはソフトでやってる。たとえ出てきた画像が
ＰＳ２並に綺麗でも、さらに６０ｆｐｓ動作していても。）
ＳＹＮ－ＺさんのページでＭＭＸ読んでたら、「MilleniumⅡ」とか懐かしい単語が出てきたんで、
思い出したけど。（注：これはＭＡＭＥが誕生した頃のMatroxのビデオカードです。ＡＧＰは、
あったけど、出来たばっかりで、まだ普及するかどうか解らない状況だった。眉唾だった。
その前の規格があっさりこけたからね。今ならせめてＧ２００とかＧ４００でないと通じないかも、
いや最近は名称に「Ｘ」が入らないものは既にビデオカードと気がついてくれないぞ。多分）
「MilleniumⅡ」（ＰＣＩ版）だの（レジスタ設定が特殊で非公開なので、専用カスタマイズが必要）
（実は３２０ｘ２４０とかおいしいモードが、ハードレベルではレジスタ叩くだけで出来るんだから
ＢＩＯＳでサポートしとけよ。）
「ＡＴＩ＿ＲａｇｅⅡ＿ＰＲＯ」（ＡＧＰ版）（だっけ、これはＡＴＩだからＲＡＤＥＯＮ系）だの、
明らかに過去のグラフィックボードを、今のＰＣ（ＡＧＰバスは必要）
ＬＧＡ７７５のpen4マシンで挿して実行した場合。さして見劣りしないっていうか、殆ど変わらない。
（せいぜい差が数ｆｐｓ）
だって、重いゲームは、ＣＰＵがネックでビデオボードのバス転送帯域なんて殆ど誤差だもん。
（つまりＡＧＰｘ２倍でもオーバースペックで使わんという事。使わなければｘ２倍でもｘ１６倍でも変わらん。
ましてやＰＣＩ-Ｅｘｐｒｅｓｓなんて）
これが同じ古いカードでも「Ｔｏｒｉｏ ６４Ｖ」クラスになると、あれは完全なゴミです。素直に捨てましょう。
って事になるのだった。（露骨に転送速度がとろい）
管理人去年ぐらいにこのくだらない実験をして、ちょっと「MilleniumⅡ」のＷＲＡＭを見直したのだった。
でも結局使わないけどね。（数～１０ｆｐｓ程度、差が付くから）
ただし、お絵かきしかしないＰＣなら目に優しくて良いかもしれない。
ＭＡＭＥで対応してきてる「ＶｏｏＤｏｏ」はこの辺、どおなんだろ。ＭＡＭＥが３Ｄファンクションネイティブで
サポートしたとして、あるいは自分で変換部分を作るとして、（プレステやＳＹＳ２２なら出来ない話でないし、
もうやってるよね。Ｖｉｖａ-ｎｏｎｎｏとか）
今の時代のビデオカードでも、「ＶｏｏＤｏｏ２」以降の「ＶｏｏＤｏｏ」でもさほど差がつくとは、
思えない。（プレステ程度なら何の問題もない）
絵的にナニな所のあるＧｅＦｏｒｃｅ系やちょっと好みのあるＲＡＤＥＯＮ系よりも
発色はいいと思うから（これはきちんとガンマを設定した場合。但しＶｏｏＤｏｏ系はコントラストが
甘いという欠点がある）、パフォーマンスに差が出なければ、試してみる価値はある。
（ちなみに現時点のこれらのカード商業価値はマイナスです。つまり世間ではゴミ）
←管理人、日記なのをいいことに、すぐに余計な横道に走る悪い癖があるな。
■
１．たまたま持ってた「dmame82s.zip」を使った。
（確か。２００４年の七月にＤＬした奴（タイムスタンプより）、もっと新しい方がいいに決まってる。
管理人はこの頃インターネットやってないから、ＤＬできるチャンスは貴重だったんだよ。）
２．「#pragma once」をすべての「＊．ｈ」から取った。
３．「dmameXXs.zip」のＶｅｒが古いから、「dmame82s.zip」の中の（src\msdos\の下の）
「ＰＡＩＲ型定義構造体」が全く同じものかち合っていたので、取った。
４．「src/mame.c」の
//static UINT32 mame_string_quark(const char *string);
//static int input_is_coin(const char *name);
//static void input_is_coin_free(void);
をコメントアウト。（この関数は存在しない）
５．「src/usrintrf.c:317」の`setup_menu'関数の定義 もコメントアウト。（この関数は存在しない）
で、とにかく６８０００のコンパイルまで辿りついた。（文章にするとながーーーいがこの間５分位）
ＭＵＳＡＳＩの仕組みを書いておくと、
「ｍ６８ｋｍａｋｅ．c」をコンパイル
→ソース類を自動抽出。
「自動抽出されたソース類」をコンパイル
→オブジェクト完成。
つまり、ＭＵＳＡＳＩ３．３を完全にＭＵＳＡＳＩ２．０Ａ化する（クロックテーブルを取っ払う）為には、
元の「ｍ６８ｋｍａｋｅ．c」を直さなきゃ絶対に駄目です。
「自動生成されたファイルを、手でちまちまクロック類を直すなんて、エンバグするから絶対に無理」。
これは世界の共通認識です。仮に一つもエンバグしなかったとしても、
「全く信用が無い」これも世界の共通認識で～す。ょお。
「ｍ６８ｋｍａｋｅ．ｅｘｅ」で抽出したソース一覧。（自動作成）
「m68kops.h」
「m68kops.c」
「m68kopnz.c」
「m68kopdm.c」
「m68kopac.c」
■さてと、何のかんのあって、無事「ＳＲＣ」抽出に成功しました。（今２０：５７分）
この（６時間－２時間）＝（経過－食事や休憩）＝４時間をかえせー。って叫んでも仕方がない。
まあ、のんびりやってるから良いんですけど。仕事じゃないし。でも、たかがコンパイルで、
４時間はかけすぎじゃアホ。って自分に突っ込んだりして、てへ。
とにかく「make68k」のライセンス表示を見てびびった。２０００年やんけ！
２００１年って話は、一体何処から来たんだろう。
はあ、そうですか。本家は２０００年ですか。
でも、ライセンス表示は２０００年だけど、多分世界で一番新しいＭＵＳＡＳＩ３．３。
だって、本家だもん。
本家のkerlさんはmame.netだもん。
そうそうＭＵＳＡＳＩのオフィシャルサイト無いって書いたけど、訂正しちゃぉ。
ＭＡＭＥ．ＮＥＴですね。ついでにさとうたつゆき様も、
ＭＡＭＥ．ＮＥＴに決定。誰が決めたかって？いつ決めたかって？
もちろんわたし。今決めました。
文句があっても世の中言ったもん勝ちっていう、
なさけない裏のルールがありますからね。
戦争も勝ったもんが正義。なさけなや。
まあ、いいや。
で、中見ると、新しいです。対応ＣＰＵは、
６８０００
６８００８
６８０１０
６８ＥＣ０２０
６８０２０
６８０４０
あれ？６８０３０は？６８ＥＣ０３０は？きっと手におえなくて、
別ファイルなのかもな。６８０６０とかＭＡＭＥなら対応してそうだから、
きっとそっちだな、６８０４０は、作りかけたけど、あまりの嫌な違いに挫折中なのかも。
あの辺ＲＩＳＣだから、ひょっとしたら、実行順序が変わる特殊な命令があるかも知れないじゃない。
サイクルなんて、考えたらパニックだよきっと。
で、「ｍ６８ｋｃｏｎｆ．ｈ」があったから、
/* ======================================================================== */
/* ============================= CONFIGURATION ============================ */
/* ======================================================================== */
/* Turn ON if you want to use the following M68K variants */
#define M68K_EMULATE_008 OPT_OFF
#define M68K_EMULATE_010 OPT_OFF
#define M68K_EMULATE_EC020 OPT_OFF
#define M68K_EMULATE_020 OPT_OFF
#define M68K_EMULATE_040 OPT_OFF
に変えてもう一度コンパイルしてみる。
→結果、さっきとまったく一緒（自動生成されたソースが）。
これは気分なんですね。っていうかソースを自動生成する段階では変わらんって事か。
ＯＢＪを作成する段しか「ｍ６８ｋｃｏｎｆ．ｈ」は関係ない。事が判りました。
