■ＭＡＭＥ１０６Ｓ（現時点で最新版のＭＡＭＥ）のＭＵＳＡＳＩ３３を引っこ抜いて、んでＳＥＧＡＤＲＩＶＥに乗せて試た。
（今度はちゃんとｍ６８ｍａｋｅ．ｃを改造する所から作った）
えっと、取り敢えず「ｍ４４＋」と銘々。んで、（ＥＢＯＯＴ．ＰＢＰが）６１１ｋｂｙｔｅｓ。つまり現在サイズが。
m22z05EBOOT.PBP ６２５ｋＢ
m33z05EBOOT.PBP ６０６ｋＢ
m44z05EBOOT.PBP ６１１ｋＢ
で、問題のＩＮＳＥＣＴＯＲ－Ｘを起動。
えーーー動かないジャン？？なんで？？（ｍ３３と同じで音楽が鳴りっぱなしになる。ゲームできない）
（ちなみにｍ２２では遊べます。）
もしかして最新の武蔵ってエンバグしてるのかな？（謎）
（２００６－０７／２０、０１：２７）
■次は（どおせＢＦ０３は伸びないだろーから）エリソルデモ。
これ、ＧｅｎｓやＤＧＥＮじゃ再現しないんだよなあ。んで、
エリソル、デモ＠５５１２。
ビル 電車 魚 クモ
ＳＴＡＧＥ ０２ ０８ １０ １６
ｍ２２＋版 ○？ ○？ ○？ ×
ｍ３３＋版 × ○？ ○？ ○？
ｍ４４＋版 ○？ ○？ ○？ ○？
おお、「完全再現？」する。が、嬉しくない事といったら...♪♪♪
（註：そんなん再現しても無意味だよお...）
（２００６－０７／２０、０１：４４）
■お約束のＢＦ０３。
結果： OFF 44 22 11 55
A32m22z05 84 62 71+ 76+ 79 625kb /GCC402_o3+uz402_o1
A32m33z05 81 59+ 68+ 73 75+ 606kb /GCC402_o3+uz402_o1
A32m44z05 81 59 68+ 73 76 611kb /GCC402_o3+uz402_o1
まあ、ＢＦ０３だけがベンチじゃないけど、体感的には（ｍ３３とｍ４４は）変わらんでしょ。オソラク。（やっぱ変わるかも？）
（註：ＢＦ０３は一部の機能（だって画面はほとんど使わんし。反面、音源とＺ８０は使う）なんで、
ＢＦ０３で全く同じ結果が出ても、ゲームをやってみると全く速さが違ったりする）
■「ｍ３３＋」と「ｍ４４＋」。パフォーマンス殆ど変わらんし、もう「ｍ３３＋」は要らんかなと思って「ｍ４４＋」で、
「ＭＷ４」を立ち上げたら、なんとタイトル画面バグってる！！
ちちちちちょーーーとマテ。眼の錯覚カト思ったつ。しかし現実は...
「ｍ２２＋」バグる。
「ｍ３３＋」バグらん。
「ｍ４４＋」バグる。
...。
■つまり、何が奇妙なのかマトメ。
インセクターＸ ＭＷ４ エリソル
「ｍ２２＋」 ○ × ×
「ｍ３３＋」 × ○ ×
「ｍ４４＋」 × × ○
じゃ、じゃんけんヤッテんじゃねーんだ。ナゼ？
（２００６－０７／２０）
■新武蔵君はガンヒーもＯＫらしい。「ｍ２２＋」、「ｍ３３＋」はダイズワールドの「レーザービーム」みたいな
「電気」みたいな「順番覚えゲー」みたいな敵でえみゅが死ぬんだけど、「ｍ４４＋」ではＯＫ。んで、「ブラック」まで
は行ったんだけど。疲れて、死んだ。タブンＯＫっぽいな。参考まで。（これ以上のチェックはステート付けないとさ）
（２００６－０７／２０、２２：１５）
■いちよ、ガンヒーＯＫちゅーメリットあるんで「A32M44Z05_tresure.zip」で別館にＵＰしといたでつ。よろ。
（２００６－０７／２０、２３：００）
■さてと、新武蔵君。あなたは一体何処が変わったの？
んで、segadriveの「ｍ３３＋」は良く判らんので、picodriveの「ｍ３３＋（違うもの）」に登場願った。
えっと、昔の事なんでワスレタが、大体合わせた時期もあった気がする。ってゆーか大体ってゆーか、
おおよそちゅーか、約ってゆーか。まあ、合わせよーと努力した時期もあった（と思う）。ちうわけで、
いまいち信頼性に欠けるが、まあ調べてみよ。
えっとハヤイ話しが、「picodriveのｍ３３＋のm68k_in.c」vs「segadriveのｍ４４＋のm68k_in.c」。
◇ｍ４４＋になって命令が追加されてる。
追加>bcc 32 . . 0110....11111111 .......... U 10
追加>bra 32 . . 0110000011111111 .......... U 10
追加>bsr 32 . . 0110000111111111 .......... U 18
それから「movem」の一部で、「pcdi」、「pcix」アドレッシング（ＰＣリラティブ系）は、別命令に分離した。
変更>movem 16 er . 0100110010...... A..DXWLdx. U 12
変更>movem 16 er . 0100110010...... A..DXWL... U 12 //「pcdi」、「pcix」アドレッシングを外す。
変更>movem 32 er . 0100110011...... A..DXWLdx. U 12
変更>movem 32 er . 0100110011...... A..DXWL... U 12 //「pcdi」、「pcix」アドレッシングを外す。
（註：「d」は「pcdi」。「x」は「pcix」の事）
こうやって、「pcdi」、「pcix」アドレッシングを外し別命令に分離。その追加された別命令は、
追加>movem 16 er pcdi 0100110010111010 .......... U 16
追加>movem 16 er pcix 0100110010111011 .......... U 18
追加>movem 32 er pcdi 0100110011111010 .......... U 16
追加>movem 32 er pcix 0100110011111011 .......... U 18
これで命令追加／変更は全部だな。あとは中身の詳細を見ないと何ともいえん。が、取り敢えずこんだけ。
■ちなみに基礎知識：
「pcdi」は、「ディスプレーメント付プログラムカウンタ相対形式」つまりd16(PC)。例えば、 movem.l _LABEL_START-_LABEL_OFFSET(PC),D0-D7/A0-A7とか。
（単なるＰＣ相対）
「pcix」は、「インデックス付プログラムカウンタ相対形式」つまりd8(PC,IX)。例えば、 movem.w 7(PC,D5),D0-D4/A5-A7とか。
（「ショートオフセット＋レジスタ」指定のＰＣ相対）
の事。（説明間違ってても、知らんもんね）
■予想だが、この辺のいずれかが上手くいかないと、エリソルやガンヒーは無理なんじゃないかな？
（註：synz様：例えばＣ６８ｋではＭＯＶＥＭ１６ｅｒＰＣＤＩマシンコード：0100110010111010つまりOP_0x4CBAは、
２４クロック消費してるの露骨に間違いですぜ。２４→１６。
ＭＯＶＥＭのこれら４つを直せば、もしかしたらＤＧＥＮ１６０の新コア？で直るのかも？）
１．原因は３２ビットアドレッシングがあるのに１６ビットアドレッシングで処理されちまってる。
２．movemのＰＣ相対系は「クロック」が違う。
のどっちかでしょーね。多分。で、本物の「ｍ６８０００」には？
（１．）の
ＢＣＣ３２は無いと思う。
ＢＲＡ３２も無いと思う。
ＢＳＲ３２も無いと思う。
つまりこいつらはｍ４４になって「エンバグ」してる可能性が高い。ううう、後で外して実験してみよ。
（２．）のｍｏｖｅｍ（ｍ６８ではブロック転送命令の代わりにマニアは良く使う。
例えば、movem.l (a7)+,d0-d7/a0-a6の一命令で一気に６０バイト連続転送出来る。ＦＩＬＬやＣＬＥＡＲなら、速いから有用だ。）。
ｍｏｖｅｍは複雑で（ｍ６８ｋえみゅでは）バグの温床なんだよなあ。よく調べないと何ともいえない。
「バグ」ではなくて「高速化の為に分離」した可能性もある。
後でしらべよ。
註：現在のＭＵＳＡＳＩ用語？では「ＢＲＡ３２」は、「bra.l」の事。例えばbra.l _LABEL とかの事。
ｍ６８０００には「bra.b」、「bra.w」はあるが、「bra.l」は存在しない。（ｍ６８０２０とかには「bra.l」はある）
後述するがちなみに、「bra.l」に相当するマシンコードを実行するとｍ６８０００では「bra.b」になる。
■前項（１．）疑問に思って調査してみた。で、なーる程。
本物の「ｍ６８０００」にはＢＣＣ３２、ＢＲＡ３２、ＢＳＲ３２は無い。がこれらの命令を実行した場合どおなるのか？
「ｍ３３＋」の対応は「ＢＣＣ１６、ＢＲＡ１６、ＢＳＲ１６」が実行される。
「ｍ４４＋」の対応は「ＢＣＣ８、ＢＲＡ８、ＢＳＲ８」が実行される。
どっちが本物動作かわからんが「ｍ４４＋」の対応も（可能性として十分）ありそうだ。
と思ってマシンコード見たら、なーんだどっちも「ＢＣＣ８、ＢＲＡ８、ＢＳＲ８」が実行されるじゃねえか！
つまり「ｍ４４＋」の対応は「エンバグ」ってゆーか動作は変わらないから「エン重」。重くなるダケ。
「ｍ６８０００」の「．」をうっかり「Ｕ」に「書き間違えた」って落ち。なあんだＭＡＭＥが悪いんジャン。
（註：あるいは原作者は、統合したかったのかも知れない。が、統合できないし、しても重くなるだけじゃん。
特にＢｃｃ（条件分岐）（つまりＣ言語でいえばｉｆ。）は頻繁に使う命令だろうし。）
ちうわけで「ＢＣＣ３２、ＢＲＡ３２、ＢＳＲ３２」はめでたく外れた。
コンパイルしなおして６０９ｋｂ→６０７ｋｂになった。
ＰＳＰ実機で動作確認してみた。動作変わらず。ＢＦ０３は、
結果： OFF 44 22 11 55
A32m22z05 84 62 71+ 76+ 79 625kb /GCC402_o3+uz402_o1
A32m33z05 81 59+ 68+ 73 75+ 606kb /GCC402_o3+uz402_o1
A32m44z05 81 59 68+ 73 76 611kb /GCC402_o3+uz402_o1
A32m44z05 81 59+ 68+ 73 76 607kb /GCC402_o3+uz402_o1 +unlessBXX32
ｍ３３＋より速くなってる。（マニアなら体感できる（？））
（２００６－０７／２１、１６：１６）
■さてと、まだやってないから妄想なんだが、３すくみの謎はどーもｍ４４＋が正しそうだな。
（だって正しくなきゃ、エリソルデモが再現される事などありえんでしょ？）つまり現在ＣＲＴＣの
実装でよくワカンナイから１２８クロック。とかなってる。あの辺。あの辺を直せは、「ＭＷ４」のタイトルが直ったり、
インセクターＸが動くよーになるんではないのかな？と思ってる。もちろん「パノラマコットン」や「バーニングフォース」や
「ターボアウトラン」等々。多々のソフトが影響を受けるから、慎重に直さんとあかんが、またＣＲＴＣ弄る必要が、
あるってこったな。
あと原因は解からんが現在のsegadriveはｍ３３＋の方が実機っぽかった。気がする。ｍ４４＋ではｍｐｕが正しい？分、
却って現状のＣＲＴＣでは変わってしまう気がする。（実機より速く終わる）マニアにしか解からん微妙な差だが。
っていうかａｕｔｏＦＰＳが悪いのかもしれん。いずれにしろ、まだぐちゃぐちゃしてる。原因が良くワカンナイ。
（２００６－０７／２１、１６：３２）
■ｍｏｖｅｍは、Ｃ６８ｋのファイル名「c68k_op4.inc」で言えば、
// MOVEMaR // movem16er,pcdi
OP_0x4CBA:＜中略（この中でもクロック消費）＞
//RET(24);//間違い
RET(16);//武蔵33@MAME106s
// MOVEMaR // movem16er,pcix
OP_0x4CBB:＜中略（この中でもクロック消費）＞
//RET(28);//間違い
RET(18);//武蔵33@MAME106s
// MOVEMaR // movem32er,pcdi
OP_0x4CFA:＜中略（この中でもクロック消費）＞
//RET(28);//間違い
RET(16);//武蔵33@MAME106s
// MOVEMaR // movem32er,pcix
OP_0x4CFB:＜中略（この中でもクロック消費）＞
//RET(32);//間違い
RET(18);//武蔵33@MAME106s
だろう。
んで、正確な消費クロックは、ワードは。１６＋４ｎ。ロングは１８＋８ｎ。（ＭＡＭＥ１０６ｓ以外の資料でも調べた）
ｎは（ｍｏｖｅｍで）積むレジスタの数（０から１６）。
ｎが０の場合は、何もしないで意味不明だが。そーゆー命令も許されるだろ。タブン。（アセンブラでは表記出来ない）
（２００６－０７／２２、０２：０７）
■あれえ？ｍ４４＋で「dbf」のクロック変えた（外す）らＭＷ４のタイトルが直る。
そおいや昔ｍ３３＋でバグってたから直したよーな記憶が？いやあれはＢｃｃだったかな？忘れちゃった。
いずれにしろ、武蔵３３はＢＸＸ系とＤＢＸＸ系は精査する必要があるな。
（２００６－０７／２２、０２：４７）
おお、「dbf」直すとｍ４４＋のエリソルデモＳＴＡＧＥ１６のクモの最後。尻切れトンボみたいに終わっちゃうのが、
ｍ３３＋みたいに直るです。やっぱＭＡＭＥのＭＵＳＡＳＩ３３のＤＢＦはエンバグですな。ＤＢＣＣの条件の所から、
「コピペ」で抜いてきたからこういう事になってる。ここはクロックも変えないと駄目です。実機（ｍ６８０００）でも
この辺のクロック計算はマニア度が高い。ちうか間違えがち。ｍ６８０００の「条件」とは何なのか？どういう
ロジックなのか考えれば消費クロックが見えてくる。
（２００６－０７／２２、０３：０１）
ヨシ、最新のじゃんけんはこうなったゾ。
インセクターＸ ＭＷ４ エリソル
「ｍ２２＋」 ○ × ×
「ｍ３３＋」 × ○ ×
「ｍ４４＋」 × ○ ○
これで少なくとも「３すくみ」のバランスは崩れたワケだな。
（２００６－０７／２２、０３：１０）
■いちよー、「A32M44Z05_tresure2.zip」で別館にＵＰしたです。設定ファイル込みで、１９９ｋｂですう。
（２００６－０７／２２、０３：３０）
■■「ｄｂｆ（ｄｂｒａ）の謎」（註：「ｄｂｆ」は「ｄｂｒａ」のマニアックな呼び方）
現在のＭＵＳＡＳＩ３３。最新版ＤＢＲＡのクロックおかしいです。えっと現在ｍ６８０００は、
M68KMAKE_OP(dbf, 16, ., .)
{
uint* r_dst = &DY;
uint res = MASK_OUT_ABOVE_16(*r_dst - 1);
*r_dst = MASK_OUT_BELOW_16(*r_dst) | res;
if(res != 0xffff)
{
uint offset = OPER_I_16();
REG_PC -= 2;
m68ki_branch_16(offset);
USE_CYCLES(CYC_DBCC_F_NOEXP);//12-2==10（計１０クロック消費）
return;
}
REG_PC += 2;
USE_CYCLES(CYC_DBCC_F_EXP);//12+2==14（計１４クロック消費）
}
参考１：基準消費は１２クロック
dbf 16 . . 0101000111001... .......... U 12
参考２：相対消費分。
#define CYC_DBCC_F_NOEXP -2
#define CYC_DBCC_F_EXP 2
になってるケドｍ６８０００の仕組み上。
M68KMAKE_OP(dbf, 16, ., .)
{
uint* r_dst = &DY;
uint res = MASK_OUT_ABOVE_16(*r_dst - 1);
*r_dst = MASK_OUT_BELOW_16(*r_dst) | res;
if(res != 0xffff)
{
uint offset = OPER_I_16();
REG_PC -= 2;
m68ki_branch_16(offset);
USE_CYCLES(CYC_DBCC_F_NOEXP);//12-2==10（計１０クロック消費）
return;
}
REG_PC += 2;
//12+0==12（計１２クロック消費）
}
だと思う。だと思うんだが、何故か両方上手くいかない。もちっと調べよう。
（２００６－０７／２３、２３：０７）
やっぱｄｂｒａヨクワカンナイ。何故か知らんがｄｂｃｃと（同じ）ではない。あたりまでは解ったんだか、
深い部分に謎が。
１．ｄｂｃｃ説（ＭＡＭＥ）
２．ｄｂｃｃだが逆説。（ｄｂｆはＴＲＵＥとＦＡＬＳＥの消費が逆説）
３．全然違う説。
ううう、なぜか２か３の気がするんだ。なんでだろ？
（２００６－０７／２８、２１：５６）
