Ａ２１ｂ遅くなってるが続行しよう。
現在別館からＤＬしたものを、
Ａ．「明らかに不要なルーチンの削除」
Ｂ．「ＶＤＰ、ＷＯＲＤ、ＲＥＡＤの変更」
Ｃ．「ＶＲＡＭ＿ＤＡＴＡ＿ＰＯＩＮＴＥＲの変更」
の３点しか変更してない。これを「Ａ２１ｂ」と名づけた。
「Ａ２１ｂ」にそれ以外の（破棄したよって日記で書いた）ＶＥＲのテクノロジーを投入しよう。
（Ａ．）は明らかに遅くなる。が、一度は通らないといけない道。我慢しよう。
（Ｂ．）は昨日の日記の変更。パフォーマンス次第では戻すが、理屈上おかしいよ。納得いかない。
（Ｃ．）は今日やった変更。現実にこの変更で、微妙に重くなってるが、それも理屈上おかしいので、直さない。
■（Ｃ．）について詳しく説明。
えーと、例えばＭＡＭＥの標準ＯＢＪ（スプライト）描画ルーチンでは、オフセットがかかってるの、知ってるかな？
えーと確か３２バイトだったよね。３２バイトはＰＣ（ＤＯＳ／Ｖ）のＡＬＩＧＮにとって都合の良いサイズ。
このオフセット何で存在するのか？というと、ＯＢＪ（スプライト）描画ルーチンがどお言う風に作るかワカンナイ
から、都合上ちっと横にはみ出すルーチンの方が、効率（ソースの読みやすさ、実行速度）が良いかもしんない。
じゃない？
そおいうわけで、横にはみ出すルーチン書いてもいいよ。ってオフセット分。
ＳＥＧＡＤＲＩＶＥ（つまりＤＧＥＮ）でも、同じ仕組みが用意されてる。
ええと、こいつの場合は縦にはみ出してもいいらしい。だってオフセットが丁度一ラスター分。
いや、縦にはみ出して良いんじゃなくて、やっぱ横用のオフセットなんじゃろ。
３２バイトなんて気持ち悪いし、だから気分で書いてあるんだと思う。それにどんだけはみ出すんだか、
よくワカンナイし。
Ａ２１では、ここのオフセットは、これ。
// The main interface function, to generate a scanline
void md_vdp::draw_scanline(struct bmap *bits, int line)
{
unsigned short *ptr, i;
// Set the destination in the bmap
dest = bits->data + (bits->pitch * (line + 8) ); //+ 16);
管理人が、初めてＤＧＥＮで見た時から、変わってないと思うよ。
「dest」って所はメガドラの画像を計算して、後で書き込む基準位置。あとで実際に描画する時に使う、
いわば「原点」だ。
「bits->data」は変な名前だが、結局ＰＳＰのＶＲＡＭの先頭番地。つまり、0x04000000にちと細工を施した物が
入ってくる。大雑把に言えばこの付近だがちと都合によりずらす。このずらす都合は
「psp_main.c」で、「md_setframe( PSP_Screen_GetTempBuffer( 16, 8 ) );」ってな感じで。
ええと、md_setframe()は、「bits->data」に値を入れるだけ、Ｃ言語とＣ＋＋言語の橋渡し部分だ。
PSP_Screen_GetTempBuffer()ってのは、関数ではなくて、単に数字を計算するマクロ。計算結果は、
ずらしたい量の整数になる。
「bits->pitch」は、管理人のエミュ「Ａ２１」では、ＰＳＰ＿ＶＲＡＭの一ライン分。つまり、
「LINESIZE x 2」。LINESIZE は５１２、「ｘ ２」はＰＳＰのＶＲＡＭの１ドットが２バイトだから。
さて、ここまで説明すれば、気が付くと思う。ええと、要するにそんなのは「定数」なんだから、始めの
定数計算マクロにいれちまえ。そしたら、
dest = bits->data + (bits->pitch * (line + 8) ); //+ 16);
が
dest = bits->data + (bits->pitch * (line ) ); //+ 16);
で済むジャン。しかも、「ラスター毎→フレーム毎」になるから計算量「１／２６２」だし。
（注：これ（計算量）は多分殆ど関係ない計算量＝＝計算負荷ではないので）
ええと、そおいう訳で、やってみたけど、重くなる。ＦＳＫＩＰ２、２２０５０、ＯｕｔＲｕｎで、（－２～－３ｆｐｓグライ）
だけど、こういうのも、単に減量してるだけだから、やっぱ直す気ないよ。
（１５：４５）
うーん、上のPSP_Screen_GetTempBuffer()は都合によりマクロじゃなかったし、ちとやり方を間違えてるので、
もう一回試行錯誤中。なんかちと勘違いした。上の（－２～－３ｆｐｓグライは違う奴の値、間違い）
（１６：３８）
画像の縮小保存とかいろいろ、その辺の機能もPSP_Screen_GetTempBuffer()とPSP_Screen_GetBackBuffer()を
使ってるから、どっかおかしくなるかと、思ったら何処もおかしくならないみたい。つまり、辻褄が合っちゃうみたい。
で、Ａ２１に比べて、ＦＳＫＩＰ２、２２０５０、ＯｕｔＲｕｎで、（－１～－２ｆｐｓグライ）今度はＣＰＰの中だけじゃなくて、
あちこち関連ヶ所を書き換えた。
いずれにせよ、Ａ２１よりトロイ事には、変わりがない。
（１７：２０）
■え～ん、やっぱ辻褄あってないじゃん。
なんか、ＰＳＰ実機で動作させると、上に８ドット分ずれる。ってゆーか、ソースよく読んで、
「何でＰＳＰ－ＤＧＥＮは、ずれないんじゃろ。」
そっちのほーが、実は不思議。まあ、手直しするのは、いいんだケド。いまいち府に落ちない気がするし。う～んワカラン。
（２１：０３）
■え～ん、ずれる、ほーこーが逆だよお。
一体何処をずらしたら良いものや、見当がつかなかったので。てきとーに。
switch(emc->screen_mode)
{
case SCREEN_1X:
md_setframe( PSP_Screen_GetBackBuffer_offs( 80, 16 ) );
break;
case SCREEN_FIT:
md_setframe( PSP_Screen_GetTempBuffer_offs( 8, 8-8 ) );
PSP_Screen_Flip_FIX();
break;
case SCREEN_FULL:
md_setframe( PSP_Screen_GetTempBuffer_offs( 16, 8-8 ) );
PSP_Screen_Flip_FIX();
break;
}
ってやってみたが、ずれる方向が正反対。ええっ？って事は「８＋８」何でぇ？
（２２：２６）
うん、＋８にしたらＯＫ。でもＡ２１に比べて、
「びみょーに遅くなってる」か
「変わらない」か
「びみょーに速くなってる」
の、どれか。
えーだって、測る度に、値が変わるんだもん。ワカンナイよ。
（２２：３５）
■今何だかアメブロ混んでたんで、このページの日記をはじめっから読み直してたら、確かにオフセット
縦にずれてもいいんじゃん。
dest = bits->data + (bits->pitch * (line + 8) ); //+ 16);
だよ。
「bits->data」は先頭アドレスだから関係ない。
「bits->pitch」は１ラインの長さ。（実は定数）
「＋８」だから縦に８ドット。
つまりここの指定は、本来描く筈の位置より、下に８ドットずらして描くって事。
でも、それがどおして、ＰＳＰ＿ＭＡＩＮからは１６ドットなんだろ？
なんかＰＳＰ＿ＤＧＥＮってＶＲＡＭの下の方に一回書いてるみたい何だけど、つまり。ＰＳＰのＶＲＡＭって、
ＦＬＩＰするとして（表：0x04000000）（裏：0x04400000）でしょ？
でも表も裏も広すぎて、下の方、開きまくってるじゃない？表も裏も十分表示画面が２画面分以上取れる。
つまり、ＶＲＡＭを余らせまくっても、４画面分。十分に取れるじゃない？
この辺のないよーはどっか過去日記で書いたよお。もう１ヶ月グライ前だから、えーと。
どーでもいーけど管理人。日記増えすぎにゃん。これじゃあ技術じょーほー埋まってても、探し出せないにゃん。
にゃんどかじろー。ごろーにゃん。（注：最近映画がリメイクされたらしいにゃん。でも実は原作も見た事ないにゃん）
（文責：ねこ）
はい、ごめんなさい。もう管理人にも探し出せないですぅ。既に探し出すのが時間の無駄ですぅ。自分のブログが
りょーが多すぎて一番読めないので、最近は現実逃避で、他のブログに探検に行くのが趣味とか。趣味ってのは
もちっと、こーしょーな奴だっけ？
つー訳で、どっかにあるから、ガンガッテ探すか、潔くあきらめましょー。（注：管理人はあきらめた）
■えーと、とにかくＰＳＰ－ＤＧＥＮは４画面分も取れるから、一番始めはＶＲＡＭの下のほーの２画面に描いといて
（注：ＦＬＩＰだから、２画面分いるでしょ？）で、後でも一回見える所。つまり上のほーに転送します。
（注：これもＦＬＩＰだから、２画面分です）
■なんつーか、またまたかんけーない話なんだけど、これって元祖ＰＳと仕組みが似てたりして。こーゆー
見えないりょーいきに、ふつーはテクスチャ配置しとくんだお。そおするともうＶＲＡＭにあるけん。ＧＰＵがらくしょー
って言っててんそーがはやかつたよーな。ううんふるい記憶は当てにしたらダメぽ。何れにしろ似た仕組み。
で、元祖ＰＳって密かに「インターレースモード」あるじゃん。あれ使うと画面がきれーなのはいいんだけど、
ＶＲＡＭが圧迫されて、テクスチャー何処に置いたら良いのやら、路頭に迷う仕掛けになってんの。だから、
「インターレースモード」のゲームは少ないの。スピードよりも、メモリが大変なの。ＰＳＰはインターレースモード
なんてあるんかいな？
（２３：２６）
■http://red.ribbon.to/~pspemu/
ここは結構良いな。
ＰＳのエミュの話ってフェイクじゃなかったんだ。
最近は２．６でも道が開けてるんだ。（http://www3.ezbbs.net/04/psp-psp-psp/のちっと前の記事。）
うううなんか浦島太郎って感じ。
ＰＳＰ２ってのもなあ。どうなるやら。
■ああまた勝手に転載病が...いいやちと一部だけ。
以下無断転載：http://red.ribbon.to/~pspemu/old_news_009.html
2006/01/27 関連項目
■EBOOT Loader for 2.00, 2.01, 2.50リリース
●現時点で動作するソフト
(1)uo_Snes9x v0.02y32 Dual Tetris
(2)Lunar Lander
(3)Ghost in the Matrix
(4)Nem's Hello world
●問題点
(1)[HOME]ボタンが動作しない
＜中略＞
v2.00のPSPなので
v2.01/v2.50ではどうなるか分かりませんが、GTA:LCSを使用している限りは多分同じ
＜中略＞
[NG]
(1)RIN -GB/GBC Emulator- v1.32 NG
(2)Lua player v0.16 NG
(3)PSPSOne v0.1 alpha NG
(40)Vector Infector NG
(5)PSP-OSS 0.2b NG
(6)PSPGBA v1.0 NG
(7)Filer v0.1 NG
ええと、知らん人に解説（そんな柄じゃないが）すると。
北米版の「Ｇｒａｎｄ Ｔｈｅｆｔ Ａｕｔｏ － Ｌｉｂｅｒｔｙ Ｃｉｔｙ Ｓｔｏｒｉｅｓ」
通称「ＧＴＡ：ＬＣＳ」 とゆーＰＳＰのソフトを購入し、ｅＢＯＯＴ Ｌｏａｄｅｒと組み合わせると、
上記の記事はちと古いので２．００だが、
現状の「ｅＢＯＯＴ Ｌｏａｄｅｒ」（注：以下、えＢＯＯＴ）では２．６０でも動くらしい。
が、何処まで動くのやら、報告例がネットで切れ切れなので、良く解からん。
つまり１００％何でもかんでも動くって訳ではないらしい。で、上記の記事は２．００と、ちと古いＶＥＲの
えＢＯＯＴの記事らしい。上記、記事の場合。
ＲＩＮ１３２は動かん。って書いてあるから、管理人のエミュも動かん可能性が高い。
が、現状どおなんだろ。誰かＧＴＡ：ＬＣＳ買った人。（注：通販で買える）で、２．６０で、最新のえＢＯＯＴで
（出来れば管理人のエミュ）動くか、動かんか。試した人がもしいたらコメント入れてよ。別に管理人の奴でなくても、
ＲＩＮやＤＧＥＮ。その辺はどおなんだろ。なんかｙｏｙｏＦｒのＴＹＬは独自技術で動きそーだから参考になるか
ならんかビミョーだが、何でもいいから、（ソース公開されてる。エミュ・プログラム）で、
ある程度のＥＢＯＯＴ．ＰＢＰサイズのあるもの（つまり１ＭＢｙteｓ以上が望ましい）が、
Ａ．起動するか？
Ｂ．[HOME]は受け付けるか？
Ｃ．出来ればＲＯＭが読むかどおか？（注：合法ＲＯＭがない場合は、フリーＲＯＭ使え）
そおそお、管理人フリーＲＯＭ作ってもいいよ。エーと、作成経験があるフリーＲＯＭは、
Ａ．スーパーファミコン （アセンブラ）
Ｂ．メガドライブ （アセンブラ、Ｃ言語だが貧弱）
Ｃ．ゲームボーイ（カラー） （アセンブラ、Ｃ言語）
Ｄ．ファミコン （アセンブラ）
そんだけ。でも「ゲームボーイアドバンス」は、ＴｅａｍＫＮＯＸの開発キットあるから、
やった事ないけど、簡単に作れる。
「ＰＣエンジン」は、ちと市販ゲームと同じ状態にもってく方法が良くわからんので保留。
（でべろがあるがそんなのあっても無駄だろ。でもあれにアッセンブラ自体のＣソースがあって、
改造しまくった記憶がある。（だってあのアッセンブラ、バグだらけの上にデカイコードが吐けんじゃないか。
ちとデーターをソースにいれるだけで、ソースなんてすぐデカクなるんだから、まったく全然、もとのママだと、
実用性が全然ない。まあその辺ねらってるのかもしんないけど）
市販ゲーム形式がハッキリすれば、クロスアッセンブラに仕立て直す事は出来る）
「ワンダースワン」は、「ワンダーウィッチ」なら持ってるが、市販形式で作った事はない。
ただし、ＦｒｅｙａＯＳをまったく使わない（起動以外）プログラムなら作ったんで、ちとカイゾーすれば、
市販形式になる可能性は、あるこいつは（アセンブラ）
つーか管理人Ｆｒｅｙａは完全にＤＩＳっちゃったんだか。これライセンス事項に触れるのかな？
あれはいちおー暗号化してあるんだが、特殊な発想転換により、プログラムを一行も書かないでも
実機があれば、復号が可能なんだよ。管理人プログラム組んでちまちま吸い出した奴と、完全にバイナリ
一致したから、頭の少し回る人なら、既にずーーと前にやったんじゃないのか？
但しライセンスに触れるとまずいから、そおいう話は、何処にもなかっただけなんじゃないか？
だって、某氏のーーーと、某氏のーーーはオフィシャルのソフトに入ってたが、
とてもＦｒｅｙａ全く見ないで開発したとは思えない。特に某氏のーーーはＲＥＡＤＭＥにさりげなく
ＤＩＳったらしき記述があるよな。「ワンダーウィッチ」持ってる人しか判らんネタだが。
（速度の要求されるソフトで）みょーに、完成度が高く、みょーにサイズが小さく、ソースリストが入ってない、
あの２本だよ。それだけ言えば、完全に特定できてるよ。これでもワカンナイならにぶすぎ。
ちなみに上記バイナリ一致した後で、実機を使わない復号ソフトも、ちと書いてみたんだが、（ええとＣ言語で
画面一頁くらいのＨｅｌｌｏＷｏｒｌｄ（本物）に毛が生えた位のプログラム）２５６バイト毎のチェックサムだか、
なんだかの計算方法が良くワカンナカッタんで、それ以外は完璧に復号出来るんだがそこがワカンナカッタ
ンデなげた。（注：さじ）
だから、その手で（不完全な）復号をした奴もいたかもしれん。（つまり管理人は３種類復号は試した）
ちなみにＦｒｅｙａはメチャメチャ基本に忠実なアセンブラコードでしかも本体が小さいから、ＤＩＳ初心者でも、
簡単にＤＩＳれると思うよ。（バイナリの後半殆どはフォント）下手したらフルオートでＤＩＳれそうな勢いだ。
普通、管理人が苦労してＤＩＳるコードとは別次元で、何だかＤＩＳるだけで、さわやかな気分になれる。
貴重なバイナリだよ。みんなこんなコードにしてくれれば、フルオートで、世の中にソースリストなんて
なくても要らないのにってレベルの素直なコード。あんまり書くと却って嘘っぽいが、目から鱗。
本当なんだって。
メガドラ開発も真面目にやるならアセンブラさえなんとかすればっていうかＸ６８０００用やアミーガ用が、
そのまま流用出来そうな気がする。Ｘ６８０００時代は「リロケータブル」コードしか作成した記憶がなく、
「絶対番地」で吐けるオプションがあったかどおか、覚えてないが。もしあれば、
Ａ． ＰＣのＸ６８０００エミュで絶対番地のコードで開発。Ｃコンパイルもしくはアセンブル。
Ｂ． ツールでイメージを取り出す。（Ｘ６８０００側に仮想ドライバを入れるとＷｉｎのファイルが全て読み書き可能。
それとは正反対で、逆のＷｉｎ側でＸ６８０００のＨＤＤイメージを読み書きするツールもある。ＸＰならそのタイプかも）
Ｃ． そのままＰＳＰに持ってってエミュで実行。
つーのも簡単だな。だってチェックサムなど、自作ソフトなら端から関係ないもん。
あー、殆どの人には何の話か解からんか。よーするに、「フリーＲＯＭのクロス開発」だな。よけー解からんか。
（次の日の朝０４：０２、そろそろねよーかな）
