＃８ＭＵＳＡＳＩ３．３（２００６－０１／２５）

☆ＭＵＳＡＳＩ３．３に拘ってみる。（２００６－０１／２５）

（注：このＤＧＥＮは１．００です。最新のＤＧＥＮはもっとずっと進んでいます。
スキルがあり、開発をしたい方は開発者に直接コンタクトをとって下さい。
私は開発者とは全く関係のない第三者です。
あくまでこのページの話は実験用途（教育用）です。）



昨日のＭＵＳＡＳＩ２．０Ａ→ＭＵＳＡＳＩ３．３置換で、
約１０ｆｐｓパフォーマンスが低下した。
ということは、

■Ver 1.20 ( 2005.12/01. )
  ・既存の68Kコアをバージョンアップ（MUSASHI 2.0A を 3.3 に変更）
  ・高速な68Kコアを実装
  ・既存の68Kコアと高速な68Kコアを設定で切り替え可能にしました
  ・Z80コア入れ替え
  ・キーコンフィグにコア切り替えとリセットを追加しました
  ・高速な68KコアとZ80コアは NeoCDPSP(Yoyofr) のものを流用しました

「既存の68Kコア」＝＝「ＭＵＳＡＳＩ２．０Ａ→ＭＵＳＡＳＩ３．３」
「高速な68Kコア」＝＝「Ｃ６８Ｋ」

/*********************************************************************************
 *
 * C68K (68000 CPU emulator) version 0.80
 * Compiled with Dev-C++
 * Copyright 2003-2004 Stephane Dallongeville
 *
 ********************************************************************************/

という事だ。
うちでは、っていうか。この開発に使っている非力なノートＰＣでは、
恐らくメモリが足りなくなって、スワップの嵐になり、八時間ぐらいコンパイル
しても帰ってこないので、現在こちらのコアのコンパイルは保留中だ。
「ＲＡＭ６４ＭＢ、仮想メモリ自動、ＨＤＤ残り２３４ＭＢ（現在）」

コンパイル負荷を減らすため、「c68kini.inc」を（ＤＯＳ／Ｖ用のＣ言語で変換）
テーブルに展開し、
static const void *JT_ROM[0x10000]=
{
 &&OP_0x0000,&&OP_0x0000,&&OP_0x0000,&&OP_0x0000,&&OP_0x0000,&&OP_0x0000,&&OP_0x0000,&&OP_0x0000
,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC
,&&OP_0x0010,&&OP_0x0010,&&OP_0x0010,&&OP_0x0010,&&OP_0x0010,&&OP_0x0010,&&OP_0x0010,&&OP_0x0010
,&&OP_0x0018,&&OP_0x0018,&&OP_0x0018,&&OP_0x0018,&&OP_0x0018,&&OP_0x0018,&&OP_0x0018,&&OP_0x001F
,&&OP_0x0020,&&OP_0x0020,&&OP_0x0020,&&OP_0x0020,&&OP_0x0020,&&OP_0x0020,&&OP_0x0020,&&OP_0x0027
,&&OP_0x0028,&&OP_0x0028,&&OP_0x0028,&&OP_0x0028,&&OP_0x0028,&&OP_0x0028,&&OP_0x0028,&&OP_0x0028
,&&OP_0x0030,&&OP_0x0030,&&OP_0x0030,&&OP_0x0030,&&OP_0x0030,&&OP_0x0030,&&OP_0x0030,&&OP_0x0030
,&&OP_0x0038,&&OP_0x0039,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x003C,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC
,&&OP_0x0040,&&OP_0x0040,&&OP_0x0040,&&OP_0x0040,&&OP_0x0040,&&OP_0x0040,&&OP_0x0040,&&OP_0x0040
,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC,&&OP_0x4AFC
,&&OP_0x0050,&&OP_0x0050,&&OP_0x0050,&&OP_0x0050,略
うりゃーって感じの。
データー量が２５６kBytes（多分アドレス３２ビットだから、６４kBytesｘ４）の
テーブルにしてあるが、（ちなみにソースは１６６kBytes→７８５kBytes）
いずれにしろ、ちーともコンパイル。終わらなかったので、保留にしてある。

うちはノートＰＣしかインターネットに繋がってないので、ＤＴＰを活用する為には、

ο無線ＬＡＮカード買ってくるか、
ο手持ちのＬＡＮカード双方にいれるか、
οＣＤにcygwin焼いて、ＤＴＰに持っていく（動くのかなぁ？）か、

その辺をやらないと、なんともならないかも。（ＤＴＰはメモリは何Ｇもある。）

そういう、訳で「高速な68Kコア」＝＝「Ｃ６８Ｋ」は、保留中。
（現実逃避ともいう）
「物買いに行くの→めんどい」
「ＣＤ焼くの→いいかげんに焼くと後で訳判らなくなるし、物が増えるのはめんどい」

しばらく、
「既存の68Kコア」＝＝「ＭＵＳＡＳＩ２．０Ａ→ＭＵＳＡＳＩ３．３」
を弄ってみる事にする。

基本的に、ＭＵＳＡＳＩ３．３というのは何か。というと、
今まで（２００１年当時）の６８ｋコアで、６８０２０関係のコアは、
複数あるものの、まともに（ゲーム等が）動作するコアは（２００１年当時）
これしかなかった。
２００１年当時のＭＡＭＥのあの、アッセンブラ６８０２０コア
（一般的にはバグだらけと思われているが）だって、その一個前のＶｅｒに比べて、
画期的に良くなったんだよ。（２００１年当時）
なんせ、（ＤＯＳ／Ｖマシンで）あのアッセンブラコアＦ３に組み込んだら、
「レイフォース」が動いたし、但しコアのせいでジョイスティックの操作は不能だった。
（もちろんＭＵＳＡＳＩ３．３なら何の問題もなく動いた）
当時６８０００のコアは腐る程あったが、６８０２０のまともに動くコアは
「ＭＵＳＡＳＩ３．３」しかなかった。（ＭＡＭＥもＲＡＩＮＥも）
もう、５年も前の話なんで、今はどおなってるのか知らない。

そおいう訳で、ＭＵＳＡＳＩ３．３から
６８０１０
６８０２０
関係をすべて外す事にする。だってメガドラはこの辺いらないもん。（Ｆ３は要るの）
これは、どおいう事かというと、ＭＵＳＡＳＩ３．３は６８０００のみを
使用する事は、端から想定していない。
設定で６８０００だけにしても、大量の（１／３位？）６８０２０関係の
コードが残る仕組みになっている。もし、このような想定。
「例えば、６８０００＋６８０１０のみ使う」とか考えてあれば#defineになって、
いる筈であるが、「制御変数」になっている為、たとえどんな最適化が入っても
コンパイル後に、ごみ（６８０２０関係）が残る。ここを手でちまちま、削除してやる。
（#defineにしといてくれれば、そんな必要ないのに）
２００１年当時のＣＰＵは、既に１ＧＨｚを越え、とても早かった為、
こんなオーバーヘッド、あってもなくてもどおでも良かった。
ＭＡＭＥの実行ファイル既に何十メガ（無圧縮時）もあった。
（注意：みんなが持ってるバイナリの数メガのＭＡＭＥは、「ＵＰＸ」による圧縮が入っているのだよ。
これは実行時にメモリに自動で展開（解凍）してから実行する。）

今わたしがいじってるＥＢＯＯＴ.ＰＳＰが約１．１ＭＢ（無圧縮）とは、
容量や実行時オーバーヘッドの考え方の桁が違う。

それから、クロックテーブルや６８０２０の命令テーブルも不要な部分を削除。
例えばこんな感じ
「m68kops.c」
/* Opcode handler table */
static opcode_handler_struct m68k_opcode_handler_table[] =
{
/*   function                      mask    match    68000消費クロック */
	{m68k_op_1010                , 0xf000, 0xa000,   4},
	{m68k_op_1111                , 0xf000, 0xf000,   4},
	{m68k_op_moveq_32            , 0xf100, 0x7000,   4},
//	{m68k_op_cpgen_32            , 0xf1c0, 0xf000,   0},/
//	{m68k_op_cpscc_32            , 0xf1c0, 0xf040,   0},/
略
	{m68k_op_sle_8_aw            , 0xffff, 0x5ff8,  16},
	{m68k_op_sle_8_al            , 0xffff, 0x5ff9,  20},
//	{m68k_op_traple_16           , 0xffff, 0x5ffa,   0},
//	{m68k_op_traple_32           , 0xffff, 0x5ffb,   0},
//	{m68k_op_traple              , 0xffff, 0x5ffc,   0},
	{m68k_op_bra_16              , 0xffff, 0x6000,  10},
//	{m68k_op_bra_32              , 0xffff, 0x60ff,   0},/
	{m68k_op_bsr_16              , 0xffff, 0x6100,  18},
//	{m68k_op_bsr_32              , 0xffff, 0x61ff,   0},/
	{m68k_op_bhi_16              , 0xffff, 0x6200,  10},
//	{m68k_op_bhi_32              , 0xffff, 0x62ff,   0},
略
あまりに沢山あるのでほんの一部だ。
ここは、前記の「c68k」みたいに、
「ジャンプテーブルにして展開」するか
「巨大なswitch()文にして分岐」するか
の流派があるが、このままではとろすぎるんで、
少なくともどちらかに移行して実行速度を
稼ぐ必要がありそうだ。
（訂正：今ソース見たら、ＭＵＳＡＳＩ３．３は前者のタイプ「ジャンプテーブルにして展開」です。一応）

例：「ジャンプテーブルにして展開」は、大体こんな雰囲気。(中身はてきとー)
static void **op_tbl[65536];  /* 具体的な実行命令のサブルーチンの先頭アドレス集 */
exec(){
	do{
		fech();
		(optbl[now_op])();	/* １命令実行 */
	}(remain_clock<0);
}
例：「巨大なswitch()文にして分岐」は、大体こんな雰囲気。(中身はてきとー)
exec(){
	do{
		fech();
		swtich()	/* １命令実行 */
		{
		case 0x0000:
				op_0000();remain_clock-=4;
			break;
		case 0x0010:
				op_4afc();remain_clock-=8;
			break;
		...
		case 0xe120:
				op_e120();remain_clock-=12;
			break;
		}
	}(remain_clock<0);
}
注：両方（原理の）説明用で、実際に作ったりした訳ではない。

そおいえば、どっかのバカな雑誌が、クロックのエミュレートがないから、動作が適当。
なんて事（ずっと昔に）書いてあったけど、「クロックのエミュレートがない」エミュレーター
なんて存在しないぞ。あの初期の頃のＶｅｒのＶ６０（だっけ？）でさえ、クロックわからんから１命令あたり
１０～１５クロックね。（それで動いちゃう所は、ある意味カルチャーショックだったが）とかやってるのに。
正確なクロックはエミュレーターの生命線です。
だからｃ６８ｋ（２００４年）は「ＭＵＳＡＳＩ３．３（２００１年）のクロックテーブルだけ流用しました。」
とかなってるんだよ。

ＳＹＳ１とかそれ以前のＳＹＳ８６とか、２００６年現在。進化はしているものの、
どうしても正確なタイミングが判らなくて、
未だに正確に動いていない。（特定のＣＰＵに５～１０％のウェイトが特定のタイミングで入るらしい）
ゲーム立ち上げて、リセットを何回かかけると画面がバグる筈。（本物ではもちろんそんな事にはならない）
ＳＹＳ１よりＳＹＳ２の方がその辺、（変なウェイトがないから）実は簡単だったりする。

□あれぇ。エンバグしちゃった。今実機でチェックしたら、
Ｌ、Ｒ、キーが何故か効かない、エンバグは慣れてるし、
最悪この前のソースに戻ってちまちま今のソースを移植すれば、
いいだけなんだけど。ちょっとめんどくさいな。この前って、ずっと前だし、ＶＤＰ弄ってた頃。
あーめんどくさいな。きっと、昨日の夜中寝る前に日記上げて、チェックしたから、
それ以降の日付のファイルだけ見れば良いんだけど。寝る前に弄った分について、記憶がない。
（２００６－０１／２５、１９：５０現在）

→エンバグじゃあなかった。原因はＳＡＶＥ．ＣＰＰの仕様を変えた為。
前の設定ファイルを全部消したら、うまく動く様になった。

せっかくだから「ＢＦ０３チェック」

この前（ＭＵＳＡＳＩ２．０Ａ／ＧＣＣ４．０．０）
ＯＦＦ
７９～８０ｆｐｓ
補間付５５１２ｋＨｚ
７２～７３ｆｐｓ
補間付１１０２５ｋＨｚ
７０ｆｐｓ
２２０５０ｋＨｚ
６５～６６ｆｐｓ
４４１００ｋＨｚ
６０～６１ｆｐｓ

昨日（ＭＵＳＡＳＩ３．３／ＧＣＣ４．０．０）
ＯＦＦ
６９ｆｐｓ
－１０～－１１
補間付５５１２ｋＨｚ
６３ｆｐｓ
－９～－１０
補間付１１０２５ｋＨｚ
６１～６２ｆｐｓ
－８～９
２２０５０ｋＨｚ
５７～５８ｆｐｓ
－８
４４１００ｋＨｚ
５０～５１ｆｐｓ
－１０

今日（ＭＵＳＡＳＩ３．３／ＧＣＣ４．０．０）[dgen100A06]
ＯＦＦ
６８～６９ｆｐｓ
－１
補間付５５１２ｋＨｚ
６２～６３ｆｐｓ
－１
補間付１１０２５ｋＨｚ
６０～６１ｆｐｓ
－１
２２０５０ｋＨｚ
５７ｆｐｓ
－１
４４１００ｋＨｚ
５０ｆｐｓ
－１

うん、誤差だ。誤差。いらないルーチンを削ると、（明らかに不要なものをなくしたのに）
１～２ｆｐｓ落ちる事があるので、誤差のうちだ。

重要な事は、ｆｐｓを１０位押し下げている根本原因を見つけてないという事。
例えば、単純にパフォーマンスアップさせたいだけならば、コアの中の割り算削るとか出来るけど、
ＭＵＳＡＳＩ２．０Ａがそうなってるから、あえてその辺は弄っていない。ＭＵＳＡＳＩ２．０Ａも見つつ、
ＭＵＳＡＳＩ３．３で、変わった部分のみ弄っている。

すわっエンバグかっ？と肝を冷やしたので、バックアップを取ることにした。
名前は「dgen100a06」DGE10A06.zip１，１２８ｋｂ。
気分で（開発用）バックアップを取っていて今７個目って事。
（作業が進んだからバックアップを取るのではない。意味があるから取るのでもない。
定期的に時間で取っている。最悪１日程度の時間のロスで済むからだ。）

現在バックアップ状況
DG10DAME ZIP     2,110,000  06-01-25  21:10 DG10DAME.zip
DGE10A00 ZIP     2,104,621  06-01-25  21:07 DGE10A00.zip
DGE10A01 ZIP     2,104,105  06-01-25  21:06 DGE10A01.zip
DGE10A02 ZIP       611,676  06-01-25  21:04 DGE10A02.zip
DGE10A03 ZIP       610,458  06-01-25  21:04 DGE10A03.zip
DGE10A04 ZIP       669,578  06-01-25  21:02 DGE10A04.zip
DGE10A05 ZIP       721,059  06-01-25  21:01 DGE10A05.zip
DGE10A06 ZIP     1,154,588  06-01-25  20:53 DGE10A06.zip