＃３ＧＥＮ日記いじればいじるほど遅くなる。
■いじればいじるほど遅くなる。（２００６－０１／１９） 昨日もＤＧＥＮを弄ってた。 （注：このＤＧＥＮは１．００です。最新のＤＧＥＮはもっとずっと進んでいます。 スキルがあり、開発をしたい方は開発者に直接コンタクトをとって下さい。 私は開発者とは全く関係のない第三者です。 あくまでこのページの話は実験用途（教育用）です。）
いじればいじるほど遅くなる。 ＲＩＳＣを甘く考えていたらしい。 どうも普通のＰＣ以上にキャッシュが重要だ。 っていうか、ことごとく普通のＰＣでキャッシュの大きい／小さいのレベルで考えるバランス感覚とは、 だいぶ違う。 Ｃ＋＋での記述してあるクラスを破壊してＣに変更したとしても、返って速度が低下するかもしれない。 なぜなら、ＳＴＡＴＩＣにして明示的に中に閉じ込めて置けば大丈夫かもしれないけど、 クラスから開放されて、実行ファイルの配置位置がとっ散らかるからだ。 それにリンカの場合によりけりだが、（このリンカの特性に詳しくない。これはＭＡＰファイルを読む） 杞憂かも知れないが、 関数もとっち散らかるかもしれない。まあ、このへんは余計な心配かもしれないが、 そう単純でもなさそうだ。 現状少しクラスの外に出したりしてるが、遅くなったり、変わらなかったり、している。 ＶＤＰレジスタをキャッシュ式にしたらかなり速度が低下した。（３８→３４）ｆｐｓぐらい。 同じ部分を最新のＤＧＥＮ１２０で実行すると（４０～４５）ｆｐｓぐらい。ｆｐｓが一定ではない。 これは速度のチェックだから、ＶＳＹＮＣなし、最大６０ｆｐｓ、フレームスキップ０（こま落としなし）、 それから音源はＯＮで１１０２５ｋＨｚの設定時。 某ゲームの一部の場所でｆｐｓが一定する部分があるので、そこで見た。 （ＢＧが重ね合わせ多重スクロール、ＯＢＪ殆ど出ない、音源Ｚ８０鳴りっぱなし、の場所） 失敗は成功の元。 速度が低下するのは、ここ（つまりメモリ関係）がとても重要だからだ。 詳しくソースを見てないが、もしかしたらＤＭＡ転送が、 ＶＤＰコマンドを呼ぶのかもしれない。 （その場合はとてつもなく遅くなりそうな事が容易に想像つくでしょ？） 速くなるＲＯＭカートリッジも存在するので、それは多分ＶＤＰコマンドのＤＭＡを使ってないんだろう。 （上記の実験カートリッジは、明らかにＤＭＡ使ってる。） つまり、メモリ関係をブラッシュアップすれば速くなる可能性を秘めている。
音源の初期化テーブルを少し削ったら（１４１／２５６）、サイズが少し小さくなった。 「ｓｎ７６４９６．ｃ」 前略 #ifdef _PSP10 extern short gain_table[][15]; #endif //_PSP10 static void SN76496_set_volume(/*int chip,*/int volume,int gain) { #ifdef _PSP10 //struct SN76496 *R = &sn[0/*chip*/]; int i; gain &= 0xff; for (i = 0;i < 15;i++) { SN76496_VolTable[i] = ((gain<141)?(gain_table[gain][i]):(10922)); } SN76496_VolTable[15] = 0; #else //_PSP1 後略
このテーブルは、大体あってるが、本質的には正確ではない。ＭＡＭＥのあれ（ゲイン特性関数）は近似式。 （頭とお尻を合わせただけ）。実機は微妙にカーブが違う。これはオシロで測定してみれば、すぐ判る。 ＭＡＭＥではそこまでやってない。（測定に手間かかりすぎ） でも、ＹＭのＡＤＰＣＭデーターとかは、ちゃんとサンプリングしてるんだよ。（やるなあ） この問題はＰＳＧ/ＳＳＧ（ＡＹ－３－何だっけ）でも共通で、いまだに解決してない。 まあ、常人にはこんな細かい事どおでもいいだろうけど、実機で再生し録音したの サンプリングデーターとエミュが吐き出したサンプリングデーターを一致させたいのならば、 必須の作業なんですけど。（既にそれは可能な時代だ）
だから、本家（さとうたつゆき様）のソースがそうなんだから、適当な近似式で良い。 （人間の耳じゃ違いわからんし）。 ＰＳＰの場合テーブルなんて（そんなくだらない事でキャッシュフローすると）勿体無いから、 近似式にしてしまえ。（整数で作るとしても。ｌｏｇの多項式展開がめんどくさければ、 二重の等差数列って手もあるし）
そうそう、音源関係も少し手を入れたが、パフォーマンス的には、 殆ど変わらない。 でも、多少は良くなってるみたい。 ＤＧＥＮは、ＭＡＭＥとかと違ってクロックの設定は基本的にとっ散らかって入ってる。 一っ個所だけちょっと違いそうなんで、手をいれた。
ＤＧＥＮはもともとフランスのエミュで、ＰＡＬは詳しいらしいが、 ＮＴＳＣはちょっと...（タイミングがよくわからん）という事らしい。お風呂にいってきまーす。■ミニミニ、プロジェクトＸ（（横暴過ぎるので削除）恐らく世界一正確なＸＴＡＬ情報。 ＧＥＮＳよりもＭＡＭＥよりも） みんなメガドライブ（ＮＴＳＣ）のクロックについて知らなすぎるので、特別レクチャー。 まずマスターＸＴＡＬは、５３．６９３１７５ＭＨｚ。 水晶本体に５３．６９３と書いてあっても、この周波数だ。 当時の水晶業界は近傍に似た周波数がないのをいい事に、 下３桁を省略して記述する癖があった。 区別できりゃあいい、それよか印刷のインク代がもったいないし、 読みにくいという、今からすれば考えられない事が常識だった。 「常識」は一般人は知らなくてよい、技術者だけが知っていればよいという風潮だった。 この周波数は特別な周波数だから、これ以外にはないし、理由もある。 ＮＴＳＣは今まで白黒テレビだったのに、カラーテレビになったので生まれた規格だ。 白黒のＹ信号（輝度信号）の他に、カラーのＣ信号（色差信号）が追加された。 このＹ、Ｃ信号が直に出てるのがいわゆるＳ端子。 （色差信号：色情報は「ＨＵＥ」つまり３６０度の角度で表し、次のドットの色との差分を 角度で持っている。つまり、＋３０度、－２３度、...等。延々信号（アナログの波形）に なってる訳。これで色が変えられるし付けられる） もともと、テレビというものは、ＦＭラジオと原理がいっしょだ。 ＦＭ変調する為には、基準となる。搬送波がいる。この搬送波に、画像信号（ラジオの場合は音声信号） を畳み込んで（ＦＭ変調して）その電波を送るのが基本原理。 カラーになって、Ｃ信号が増えたのは、何とかしなければならない。 幸い人間の視覚特性を検証してみた所、人間の特性としてカラーの質が落ちても、 白黒画像の質が保たれていれば、きれいに感じるという事が判明。 この原理を悪用？したのが、いわゆるＪＰＥＧ。メタメタに色信号圧縮してあるから、サイズが小さい。 （ここからは、波形の話ではなくて、周波数帯域の説明です。念のため） そんでチャンネルの端っこにテレビ用の音声帯域があった。（後期ではステレオに拡張された） （これを直に受信するとＦＭラジオでＴＶの音声が聞ける。原理が全く同じだからだ） しかも、都合のいい事にＹ信号は（ＦＭ変調した結果なので）帯域全部を使っておらず、 （これは安いラジカセで極端な低音や極端な高音を録音しても消えてしまうのと似たしくみ。 専門用語おなかいっぱいなら上手く説明できるんだが、私の説明力ではこの程度） 櫛状（ウェイブ状、今でいうウェイブレット関数風、つまり櫛状で両端は減衰）に たくさんつかったり、少し使ったりしている。 だから、新しく拡張した。Ｃ信号は、（これも都合のいい事にＦＭ変調すれば櫛状になる） Ｙ信号と音声信号の中間地点付近の丁度よさげな場所に配置した。（そういう理由なんです） ＋ 信号の強さ A Ｙ信号(画像) | Ｃ信号（色） | | | | | : | | | | | | | :音声信号（２つ） | | | | | | | | | : | | | | | | | | | | | : | | | | | | | | | | | || | : | | | | | | | | | | | |||||||: --+--------------|-----------|--|---->周波数＋ | |<--3.57--> | Ｙ中心 Ｃ中心 | (俗にいうテレビのチャンネル) Ｙ信号と重なりにくい様に、半波ずらして重ねた。 そのＹ信号の搬送波（中心）からＣ信号の搬送波（中心）までの距離が、 ３．５７９５４５ＭＨｚ。ＮＴＳＣ規格で決まっている。 ３．５７や３．５８と書いてあったら、間違いなく３．５７９５４５ＭＨｚ。 にた周波数は製造されていない。 たとえば３．５７００００ＭＨｚと書いてあっても３．５７９５４５ＭＨｚ。 ３．５７００００ＭＨｚは特注しない限り、水晶会社が作ってないんだから、 民生品で存在する訳がない。万が一あったらそれは１００％軍事用途だ。 もし測定できたら、技術者は測定機の精度を疑う。 この３．５７００００ＭＨｚというものが存在する理由は、技術を知らない現場が 勝手に数字を補ったり（例えばラベルの製造機が小数点以下６桁タイプに更新された） 技術の継承がないので、勝手に思い込んで（だって書いてあるし）発生した数字だ。 さて、一方ＳＥＧＡ。メガドラは初期版にＸＴＡＬが四つも乗っていたのは（もっとだっけ？） 設計どうりに動かなかったからだ。コスト無視のパッチあてがしてあったろう。 チップのバグが出たのなら、なにもあんな太い線で配線する必要など何処にもない。 あれはクロックラインだから、嫌でも太くする必要があった。 基盤がベークライトの超安物だった。 ガラエポ基盤のアーケードマシンの基盤を設計する感覚で設計してしまったので、 クロックラインがどうしても安定しない。
話がそれて来たようだ。 当時一般人が買う６８０００の価格が一万ぐらい。Ｚ８０数千円。メモリ数千円～万円。 クリスタル一個￥５００～￥１０００ぐらい。 メーカーが大量仕入れすれば、コストが安くなるが、メガドラ本体の定価が￥２１０００。 ２万を切っている店はなかったし、まだ売れるんだかどうだかよく判らない。 クリスタルは（当時）それなりに高い部品だ。 今みたいに、１０円以下のチップ１つで、あらゆる周波数が取り出せる時代とは桁が違う。 クリスタル四つも使って、量産すれば、完全な赤字だ。メモリも高いんだし。 （当時最先端のデュアルポートＲＡＭと言うものをＶＲＡＭとして使用していた。（Ｘ６８０００でも採用された）書き込みしながら、同時に読み込み（表示）できる。 当時のＰＣはＰＣ８８やＰＣ９８やＦＭ７７ＡＶやＸ１。これらは表示中に無理やり 書き込むとＶＲＡＭが単なるＤＲＡＭなので、物凄いノイズが発生した。 特にＦＭ７７ＡＶは実パレットが４０９６個もあったので、画像を表示しつつ 全パレットを更新する為には、数Ｖｓｙｎｃ必要という技術力が無ければ厳しい仕様。 後にＨｓｙｎｃの戻りにパレットを更新するという技術が開発され、改善した。 （発売時の販促デモで使用された） 要するにラスターパレットだ。ただしラスター割り込みなどない。自前で監視する。 この技術はアーケードゲーム業界に多分Ｎ社のＡ氏が広め、メガドラにも輸入されて、 それがＮ社のＢＦ。世間は意外と狭い。） だからメガドラはとにかくクリスタル一個で動作する様に設計されていた。
その一個のクリスタルの周波数は正確に５３．６９３１７５ＭＨｚ。＝＝ＸＴＡＬ。 ７．５分周回路で、６８０００に供給。（ＸＴＡＬ／７．５）＝７．１５９０９０ＭＨｚ。 当時のカタログには７．１６ＭＨｚと表記されていた。 ＮＴＳＣ回路（ＳＯＮＹの汎用チップ）にはＣ信号の基準搬送波を入力する必要があり、 それが３．５７９５４５ＭＨｚ。これは（ＸＴＡＬ／１５）＝＝３．５７９５４５ＭＨｚ。 Ｚ８０もこのＸＴＡＬを使い、たぶん（ＸＴＡＬ／１３．５）＝＝３．９７７２７２ＭＨｚ。 当時のカタログには約４ＭＨｚと表記されていた。でも、初期のメガドラには４．００００００ＭＨｚのクリスタル乗ってて、 そこから取っているのかも知れない。８．００００００ＭＨｚとかも乗ってるが、 どおなっているのか、現物を確認してない。既に初期版から完全な互換性がない。運命の十字架を背負ったハードなのだよ。 判った？
で、ＤＧＥＮ１００のソース。「ＭＤＦＲ．ＣＰＰ」 #define _scanlength (pal? ((7189547/50/0x138)) : (490)) //(8000000/60/0x106)) 違うだろ。 #define _scanlength (pal? ((7189547/50/0x138)) : (455)) //(7159090/60/0x106))
追記：２００６－０４／０５． えーだって、セガ公式ページでは、７．６７ＭＨｚだよ。 そりゃ、「公式ページが間違っとるんやろ」
よくある事だから、気にするな。 それで、megasisの7.67MHzが出てきた訳か。（わたしは、ずーっと謎だった） （注：古いＰＣのメガドラエミュ。途中の版でクロックが弄れる機能があったが、何故か初期値が7.67MHz） 納得。みーーんなセガが悪いんじゃねえか。 メガドラ１でごにょごにょあって、うやむやに誤魔化した「事件」があったんだけど。 ここには書けんが、いろいろあるの！！
■サウンドの謎。 今某ゲーム（ＢＦの０３）のサウンドテストで （このゲームはＦＭ６（とＰＳＧ？）しか使ってない。ＰＣＭはなし） ＦＭ音源のチェック中なんですが、
| ＯＦＦ | ７８ｆｐｓ |
| １１０２５ｋＨｚ | ６４～６５ｆｐｓ |
| ２２０５０ｋＨｚ | ６８～６９ｆｐｓ |
| ４４１００ｋＨｚ | ６８～６９ｆｐｓ |
なんで、音質悪い方が重いんや！
| ＯＦＦ | ７９ｆｐｓ |
| １１０２５ｋＨｚ | ６９ｆｐｓ |
| ２２０５０ｋＨｚ | ６５～６６ｆｐｓ |
| ４４１００ｋＨｚ | ５６～５８ｆｐｓ |
| ＯＦＦ | ７８ｆｐｓ |
| １１０２５ｋＨｚ | ６８ｆｐｓ |
| ２２０５０ｋＨｚ | ６３～６４ｆｐｓ |
| ４４１００ｋＨｚ | ５４～５５ｆｐｓ |
■ツールチェイン再び。 うちの開発環境はたぶんＰＳＰＳＤＫですが、「toolchain.sh」は一度も動作させてないし、 使ってません。「詳しくはHelloworld日記」 あれから、再び情報を少し調べて「Ｐｅｎ４マシンでツールチェイン実行し終わるのにＸ時間かかった」 等と書いてあるページもあったし、触らぬ神にたたりなしってとこで、いまだにやってませんが。 今日（２００６－１／１９）ＨＤＤの容量がなくなってきたので、ゴミ消し作業をしてたのですが、 （ＣＤ焼かなくても、残り１００ＭＢ→２８８ＭＢに延命した。） （あんまりくだらないものＣＤに焼くとあとで混乱して困る。） 「toolchain.sh」なんとなく覗いてたんですが、
「Ｘ時間かかったっていうのは マシンの性能関係なくて あんたのネットがとろいからや！」
あほらし。ツールチェイン自体は、 $WGET ftp://ftp.gnu.org/pub/gnu/binutils/$BINUTILS.tar.gz || { echo "ＤＬ失敗"; $WGET ftp://ftp.gnu.org/pub/gnu/gcc/$GCC/$GCC.tar.bz2 || { echo "ＤＬ失敗でちゅ"; $WGET ftp://sources.redhat.com/pub/newlib/$NEWLIB.tar.gz || { echo "ＤＬ失敗"; の三つを（ＧＣＣ，ライブラリ、ユーティリティー）ネットから落としてきて、 （つまりこのページでやってるのと同じことです） 足りないものは、 ## Grab the latest PSPSDK from Subversion. if test $BUILD_PSPSDK ; then rm -Rf pspsdk $SVN checkout svn://svn.pspdev.org/psp/trunk/pspsdk fi って感じで、「ＳＶＮ」でなんとかするみたいです。 上に貼ってあるのはバッチの一部で、例えば＄ＡＢＣって表記はＡＢＣって名前の変数。（環境変数） つまり環境依存部分ですね。上のは適当に「ＵＲＬ」が書いてあるところを、コピペしたんで深い意味は ないです。
「ＳＶＮ」っていうのは、要するに最新のソースを取得できるシステムです。 手でやるんなら、 svn checkout svn://svn.pspdev.org/psp/trunk/pspsdk って感じです。
■（２００６－０４／２７、追記） ＧＣＣって、 http://ftp.gnu.org/pub/gnu/gcc/ で、直接取ってこれるんだな。（ＦＴＰをＨＴＴＰ開放してる為）知らなかった。まあ、よく考えりゃ。あたりまえだけどさ。 最新版は４１０なんだ。えっと最近のＧＣＣ一覧。（動向）２００６－０４／２７、現在。 ３４０ ３４１ ３４２ ３４３ ３４４ ←ｓｙｎｚ氏はこれ。（環境作成済みＺＩＰが存在する） ３４５ ３４６ ４００ ←このブログでは現在これ。（環境作成済みＺＩＰが存在する）「ＰＳＰＳＤＫ以前」 ４０１ ４０２ ←ｎｋｏ氏は、これで環境作成、成功した。（自分でtoolschain.shを動かす）「これは多分ＰＳＰＳＤＫ」 ４０３ ←４０Ｘでは最終版になるんだ。一応公式の最新版。 ４１０ ←現在βっぽい。まだ時期早尚。 註：ＰＳＰ用のＧＣＣに改造する為。パッチ当てないと駄目だからな。名前だけ一緒なの。念の為。 詳しくはtoolchain,shを読む。