#8 メガドラＤＡＣ実装してみた。
メガドラＤＡＣ実装したよ「実験版DGEN」のＡ０９とＡ１０で聞き比べてみて。（別館の一番下にある）。 （２００６－０２／０８） ■管理人がギャースカ言ってるメガドラのＤＡＣ特性を実装してみた。（別館にあります） １．中音が強調されて聞きずらい。 これはＰＳＰのスピーカーの周波数特性ですから、なんともなりませんね。 デジタルフィルター等実装する気はない。ただし、もしかしたら、ＳＣＥのライブラリで、 なんとかなる可能性はある。（ＰＳＰのスペックが判ってないだけで、 既にフィルター入ってるかもしれないじゃん） ２．時々変なノイズがはいる。 これは、エミュの速度がとろいから、データーを取りこぼすのが原因です。 現在、音バッファが、基本的に一フレーム分しかない。（実装の都合で２フレーム分とって、 ぎったんばっこんやってる。） ＰＳＰで聞くと、多少聞きづらい所（中音の強調）はあるけど、リニア特性に比べたら遥かにましでしょ？
■今日はメモリの話。 っていうか’－ｌｃ’の話。 過去の日記を読むと、ＣＤに焼いてバックアップ取りました。だの、進めたんだけど、コンパイルエラー ないから、ＰＳＰに転送して実行したら起動できなくて、ソースを数時間戻した。だのあきらめただの。 ゴミに捨てた。だの。 そんな記述が、煩雑に出てくる筈。
全ては’－ｌｃ’のせい。(c)ルパン V.S. クローン（のマモーの音声で読む）
とにかく理屈上は正しい筈、なのに動かない。エラーも出ない。全て’－ｌｃ’のせい。 すわっ！エンバグかっ。 管理人、人間だし、人間は間違える生き物だし、間違えた場合に殆どは気がつくけど、 １００％完全に気がつくとは限らない。 つまり、間違えるのがあたりまえ。 これは、人間の特性なんだから、どうこう言っても始まらない。
そおいう特性がある。と認識して、対抗手段を講じれば良い筈。
管理人が用意した、対抗手段は数知れずあるが。 基本的には、
「あき、らぁめがぁ～かんぢぃん」(c)プップクプー（のつぼ作りの人の音声で読む）
なんてね。（あながち冗談でない所が恐ろしい） それならば、「あきらめられる様にする為の仕組み」を作れば良い。
ＣＤに焼く。ＨＤＤやＰＣが壊れてもＯＫ． ＷＥＢにＵＰ。ＷＥＢのサーバーが壊れなければＯＫ．
なんてこった。別館は単なる外部ハードディスクじゃん。 ミラーリングしてるから、えーとＲＡＩＤ０＋１かな。（嘘つけ） まあいいや、所詮２～３時間ずつしか作業しないし。 動かなくなっても、まあ２～３時間ぐらいいっかって言って全部破棄して元に戻してた。
もう、そんな苦労とは、おさらばだ！(c)管理人（心の声で読む）
’－ｌｃ’外したら、何処弄っても、そんな事（コンパイルＯＫで起動しない）はおきなくなった。 ’－ｌｃ’のばかーーーーーー。
あーーすっきり。 ってな訳で、今迄ちょっと弄るとすぐ動かなくなる。メモリ関係をいじって見た。 っていうかまともにソース（読めないが）読んだ。「src￥cpp￥ｍｅｍ．ｃｐｐ」 古い。古臭い。あと、訳わからん。(aoo3はjoypad1、aoo5はjoypad2) ５年前の基準と比べても、古臭いソースだ。実験の匂いしかしない。
■５年前の基準データ（ＭＡＭＥのソースより） /* Gen I/O */ ＃１は 方向と Ｂ、Ｃボタン（マークⅢ互換の為） ＃２は（方向と）スタートとＡボタン（確か方向も読めたと思う。自信がないが） /* cgfm info $A10001 Version ＢＩＯＳが見る（リージョンビット） $A10003 Port A data ←ａｏｏ３ １Ｐ用ボタンや方向のデータ８ＢＩＴ分（切り替えて＃１、＃２どちらか読む） $A10005 Port B data ←ａｏｏ５ ２Ｐ用 $A10007 Port C data $A10009 Port A control １Ｐ用、ボタンデータ（＃１と＃２）を切り替える。 $A1000B Port B control ２Ｐ用 $A1000D Port C control 以下は通信ポート $A1000F Port A TxData いらん $A10011 Port A RxData いらん $A10013 Port A serial control いらん $A10015 Port B TxData いらん $A10017 Port B RxData いらん $A10019 Port B serial control いらん $A1001B Port C TxData いらん $A1001D Port C RxData いらん $A1001F Port C serial control いらん */ リージョンビット詳細。（本体を空けると、このポートに直結しているジャンパピンがあった。（Ｄ６、Ｄ７） 全シリーズ共通。Ｄ０～Ｄ３はおそらくＶＤＰのチップ番号。Ｄ５はメガＣＤを繋ぐと０になる。 Ｄ４はおそらく未使用（Unused/Resurved）ではなくて、ＶＤＰが正常なら０。） /* Charles MacDonald ( http://cgfm2.emuviews.com/ ) D7 : Console is 1= Export (USA, Europe, etc.) 0= Domestic (Japan) D6 : Video type is 1= PAL, 0= NTSC D5 : Sega CD unit is 1= not present, 0= connected. D4 : Unused (always returns zero) D3 : Bit 3 of version number D2 : Bit 2 of version number D1 : Bit 1 of version number D0 : Bit 0 of version number */
とにかくＬＯＮＧはゲシっと削除。（ちゃんとＷＯＲＤとＢＹＴＥ作ってあればいらん） （例えば、ＷＲＩＴＥ） void md::misc_writelong(unsigned a,unsigned d) { misc_writeword(a ,(d>>16) ); misc_writeword(a+2,d&0xffff); } あーすっきり。（６８０ｘ０プログラマなら、ＬＯＮＧだけ特別な仕組みなぞ、ありえない事に気が付く。 ＢＹＴＥとＷＯＲＤは多少違いがある。（実は殆どないが））
懸念だったＺ８０のミラーリングもサポート。（注：２０００年代のメガドラエミュでは常識） （0x0000-0x1fff）と(0x2000-0x3fff)は同じ。（ミラーリング） void md::z80_write(unsigned int a,unsigned char v) Ｚ８０はＢＹＴＥのみだぉ。 { if( a < 0x4000 ){ z80ram[(a&0x1fff)] = v; } else if( a < 0x4004 ){ myfm_write((a&3),v,1); } else if( a == 0x6000 ){ write_z80_bank(v); } else if( a == 0x7f11 ){ mysn_write(v); } else if( a >= 0x8000 ) { ＜ここから先はバンク切り替え＞ 以下略
そんで、Ｚ８０（のメモリ）ちやんと作ったから、６８０００から気兼ねなく呼ぶ。 void md::misc_writebyte(unsigned a,unsigned d) { if( a > 0x00dfffff ){ ram[(a^1)&0xffff] = d ; return ; } ○書き込みだからＲＡＭ優先 else if ( a < 0xa00000 ) //MAX_ROM_SIZE) ○ＲＯＭに書くのはないんだけど。 { このエリアの書き込みは、 save_update = 1 ; ←ＳＲＡＭ更新したつ ＳＲＡＭの事を意味している。 rom[(a^1)] = d ; return ; } else if( a < 0x00a08000 ) /*shered Z80*/ { z80_write((a&0x7fff),d); ←あるもんは、使おう。 } else { 以下略
ちなみにＷＯＲＤ（つまりshort）は、 void md::misc_writeword(unsigned a,unsigned d) { 中略 // else pass onto writebyte misc_writebyte(a ,(d>>8)); misc_writebyte(a+1,d&0xff); }
ＲＥＡＤも似たようなもん。まだ訳わからんの「パッド関係と」「調停関連」残ってるけど、 結構すっきりしてきた。（まだまだ） それにしてもここまでピーーーーだとは、知らんかった。 すべては’－ｌｃ’のおかげ。 感謝感謝なむー。（２００６－０２／０８、１４：００）
メモリ乗せ変えたんで、「ＢＦ０３チェック」やってみた。 ずっと前（ＭＵＳＡＳＩ２．０Ａ／ＧＣＣ４．０．０）
| ＯＦＦ | ７９～８０ｆｐｓ |
| 補間付５５１２ｋＨｚ | ７２～７３ｆｐｓ |
| 補間付１１０２５ｋＨｚ | ７０ｆｐｓ |
| ２２０５０ｋＨｚ | ６５～６６ｆｐｓ |
| ４４１００ｋＨｚ | ６０～６１ｆｐｓ |
| ＯＦＦ | ８０ｆｐｓ |  ＝ |
| 補間付５５１２ｋＨｚ | ７３ｆｐｓ | ＝ |
| 補間付１１０２５ｋＨｚ | ７０ｆｐｓ | ＝ |
| ２２０５０ｋＨｚ | ６４～６５ｆｐｓ | －１ |
| ４４１００ｋＨｚ | ５４ｆｐｓ |  －６～－７ |
何故４４１００だけ重いんだろ。ＤＡＣのテーブル分はまあ吸収できたかも。 っていうかＢＦじゃあＤＡＣ使ってないし。違う方法のチェックもしとけば良かったかも。
今日（ＭＵＳＡＳＩ２．ＸＸ／ＧＣＣ４．０．０）「Ａ１２」
| ＯＦＦ | ８３ｆｐｓ |  ＋３～４ |
| ５５１２ｋＨｚ | ７５～７６ｆｐｓ | ＋２～３ |
| １１０２５ｋＨｚ | ７３ｆｐｓ | ＋３ |
| ２２０５０ｋＨｚ | ６８～６９ｆｐｓ | ＋３ |
| ４４１００ｋＨｚ | ６０ｆｐｓ | ０～－１ |
線形補間とって、インテル変換工夫しただけ。
■インテル変換工夫した。 #if 000 #define GET_WORD( src ) ((*((unsigned short*)src) << 8) | (*((unsigned short*)src) >> 8)) #else /* ＰＳＰではこっちの方が軽いじぇ。 */ static inline int GET_WORD(unsigned char *src) { return (src[0] << 8) | src[1]; } #endif どおも、ＰＣのＲＩＳＣと違って、ＰＳＰのＲＩＳＣはシフトが苦手らしい。 ＰＣのＲＩＳＣはシフトが異常に速いから、ああいうソースになってる。 がＰＳＰのシフトはそこまで速くない。多分ね。 その分、ＰＣのＲＩＳＣでは、既に非実用的になってきている。「char」がＰＳＰでは使えるっぽい。 （場合による）ＰＣだと、charで書いてある所をintに直すだけで、速度がアップするの常識なんだけど。 ＰＳＰでその技は使えない。逆にcharで足りるんだけど（フラグとか）ＰＣの場合charよりint（３２bit）の 方が速いからっていって、intにしてある場合が（ＰＣのソースは）ある。 これをcharに変更して試してみるのも、いいかもしれない。（場合による） align関係（の速度）はどおいう事になってるのか現段階では判らない。
上記のマクロは何をしてるのか動作を補足しとく。 上のタイプはショートでフェチ、が２回。ショートのシフト２回。ＯＲ１回。 下のタイプはキャラでフェチ、が２回。ショートのシフト１回。ＯＲ１回。アドレスインクリメント１回。
現実に下の方が速くなってるんだから、普通に考えれば、 キャラのフェチ、が早いか、ショートのシフトがとろいかだろ。 或いは、キャラで内部レジスタ（もしくはキャッシュ）を消費しない可能性もあるが。
でも、現実的に考えてシフトがとろいと考えるのが一番ありそうな想定だと思うんだか、如何がかな？
■線形補間とった。 switch(F2612_ddd){ case 3: *((unsigned short*)bufR++) = rt; *((unsigned short*)bufR++) = lt; *((unsigned short*)bufR++) = rt; *((unsigned short*)bufR++) = lt; *((unsigned short*)bufR++) = rt; *((unsigned short*)bufR++) = lt; *((unsigned short*)bufR++) = rt; *((unsigned short*)bufR++) = lt; /*no break;*/ case 2: *((unsigned short*)bufR++) = rt; *((unsigned short*)bufR++) = lt; *((unsigned short*)bufR++) = rt; *((unsigned short*)bufR++) = lt; /*no break;*/ case 1: *((unsigned short*)bufR++) = rt; *((unsigned short*)bufR++) = lt; /*no break;*/ case 0: *((unsigned short*)bufR++) = rt; *((unsigned short*)bufR++) = lt; /*no break;*/ }
なんか知らんが、悪さしてたみたい。（ルーチンが）あるだけで駄目なんだよ、きっと。 （先読みキャッシュもしくはａｌｉｇｎ）
駄目だな、ついオタクなネタにはしって。一般人にはついてけないかも。 この辺とか（パフォーマンスとか）考えられる様になったのは、すべて’－ｌｃ’を取っ払ったおかげなんだよ。 不要なルーチンがしがし削除してんのに、ガンガン速度が低下する状態では、何もできませんって。 あと、ＣＰＰのクラスライブラリをひとつのＯＢＪに閉じ込めた事も大きい。これやんないと、リンカを疑いだして、 訳、判んない事になるのは明白。これも大きいなぁ。 現状サウンドが重い事がはっきりしているので、これをなんとかすればなんとかなるかも。
「Ａ１２」は、現状ＦＳＫＩＰ１で５５１２ｋＨｚかＯＦＦなら６０ｆｐｓぐらいの表示になって、秒間３０コマ書くゲームもある。 （どうせＰＳＰの液晶は中間色の反応速度がない。明暗差がある場合は速い） でも、音悪すぎ。うるさいから下にタオルなど詰めで誤魔化すか、１１０２５にして、少しとろいのは我慢するか。 どっちかだな。もちっと速くしないとＳＦＣならともかくメガドラは実用的には遊べんなぁ。 いずれにせよ、遊ぶだけなら他のエミュで。まだ現実的ではないです。
ＰＣ（ＤＯＳ／Ｖ）のＲＩＳＣでは多少効果のあった手法。ループ前にアドレス加算を試してみた。 が、逆にＰＳＰでは遅くなった。逆効果だ。６８０００で言えばプリ／ポスト．インクリメント．アドレッシングの ような物がＰＳＰのＲＩＳＣ（Ｒ４０００）にもあるに違いない。 （これがあるＣＰＵでは逆効果になってあたりまえの実験） こんなソース。
{ int R_Output_3; int R_Count_3; int R_Period_3; R_Output_3 = sn_Output[3]; R_Count_3 = sn_Count[3]; R_Period_3 = sn_Period[3]; do { int nextevent; if (R_Count_3 < left76) nextevent = R_Count_3; else nextevent = left76; if (R_Output_3) vol76[3] += R_Count_3; R_Count_3 -= nextevent; if (R_Count_3 <= 0) { if (sn_RNG & 1) sn_RNG ^= sn_NoiseFB; sn_RNG >>= 1; R_Output_3 = sn_RNG & 1; R_Count_3 += R_Period_3; if (R_Output_3) vol76[3] += R_Period_3; } if (R_Output_3) vol76[3] -= R_Count_3; left76 -= nextevent; } while (left76 > 0); sn_Output[3]= R_Output_3; sn_Count[3] = R_Count_3; /* not need it restore the sn_Period[3] */ }
これは８６ＲＩＳＣでは、効果があるが、６８０ｘ０やＳＨシリーズやＲ４０００では、逆効果の模様。 ＰＣ（ＤＯＳ／Ｖ）の場合。sn_Output[0]とsn_Output[3]は、（最適化しても）アドレス加算が入る為。違う。 上記ＲＩＳＣチップでは、３のような小さい数は、命令自体に吸収され、変わらない。 逆にロード／ストアの無駄分やメモリやレジスタを多く消費してパフォーマンスは落ちる。 ＰＳＰでは、上記のようなコーディングは、無意味で無駄。