#8ＳＹＳ１カスタム、ダイエットにゃー（２００６－０２／１７）
■にゃー。０７：２５に、起きたにゃー。
実は昨日辺りから、やってるダイエットに関しては、ＰＳＰと関係なく、どんなターゲットでも、
それなりに応用の効く技術だったりするにゃ。
ＭＡＭＥをタイニーでコンパイルしてみたけど、（ターゲットは問わないにゃ）
「少し早くなったんだけど、まだパフォーマンスに不満なごなご」って人は、参考にしては、如何がかにゃん。
（文責：ねこ）
えーと、そろそろ偽名古屋弁は辛くなって来たので、話を元にもどすがや。
■昨日の続きやから、いっこまえを読まないと、意味わからへん。よう、出来てんねん。
ほい、昨日のあらすじ。
少し路線を、まちがえたがなあ、先にartworkとかmd5とかsha1とか簡単にはずせるもんがあるような気が...
まあ、やっちまったもんはしかたがない。
追加の要点＃４な、
＃４ ３２ビットレンダーは無条件で消して良い。（ＤＲＡＷＧＦＸ．Ｃのみの話だよ）
これはどおいう事かというとやな。元のＳＹＳ１が１６ビット色で足りるからなんや。
（例えばＦ３の場合は、３２ビットがないと駄目やで、あれはレンダーが３２ビットカスタムになってる。
超複雑なＦ３のアルファ関係をなるべく簡単に実装する為）
えーとな、今回はターゲットがＰＳＰ専用やけどな。ターゲットがＤＯＳ／Ｖで、
画面モードが３２ビット色にしか対応してない特殊なＰＣだったとしても、
それでもＳＹＳ１専用エミュの場合は３２ビット色を削除して良い。
原理はこう。
ＭＡＭＥシステム内-------
ＳＹＳ１「src/vidhrdw/namcos1.c」｛
ＳＹＳ１のドライバが、「出力用仮想ＶＲＡＭ」に、（ドライバの仮想ＶＲＡＭとは話が別）
「ＤＲＡＷＧＦＸ．Ｃ」を使って、（一般用語では、スプライト描画ルーチン。ナムコ用語ではＯＢＪ）
「ＴＩＬＥＭＡＰ．Ｃ」を使って、（一般用語では、ＢＧ描画ルーチン。ナムコ用語ではＣＨＲ）
あるいは直接。
レンダー。（ＳＹＳ１は必ず１６ビット色）
｝
-------
ＭＡＭＥのＭＥＮＵ画面は、（あるいはＦＰＳ表示や、プロファイラー等は、）
ドライバの使ってる色数にあわせて（つまりＳＹＳ１なら１６ビット色）
「ＤＲＡＷＧＦＸ．Ｃ」を使って、（一般用語では、スプライト描画ルーチン。ＭＡＭＥ用語ではＤＲＡＷＧＦＸ）
「出力用仮想ＶＲＡＭ」（ＳＹＳ１は必ず１６ビット色）に、
（ＭＥＮＵ用８ビット色（データーは１ビット色）→１６ビット色にして）
（↑これはＤＲＡＷＧＦＸ内でやるから８ビット色は単純に削除出来ない）
レンダー。
つまり合成やね。
ＭＡＭＥシステム内-------ここまではすべてシステムＲＡＭの話。
-------
ＭＡＭＥシステム機種別対応ルーチン（ＤＯＳ用とかＷＩＮ用とかＰＳＰ用とかその他とか）
「出力用仮想ＶＲＡＭ」のレンダリング色を調べ、（ＳＹＳ１の場合１６ビット色）
色数を変更し、（例えば１６ビット色→３２ビット色変換）
どっか（本物のＶＲＡＭとか）へ出力
つまり、仮想的な色数である。
ＭＥＭＵ色はＭＡＭＥが合わせてくれる。
■うぃーー。今実験で、「ＲＯＺ」と「ＺＯＯＭ」が付いてるものを単純に「ＤＲＡＷＧＦＸ．Ｃ」から削除して
ＯＢＪを生成してみた。
ＤＲＡＷＧＦＸ．Ｏサイズ：３４６ｋｂ→３１７ｋｂ（１２％減）でこれだけでは大して減ってない。
ＤＲＡＷＧＦＸ．Ｃサイズ：１５０ｋｂ→９１ｋＢこれは見て（１／３減）ってわかるでしょ？
別にソースの減り量は意味がないが。参考まで。
ここが減ると、何が嬉しいかというと、実は単純にパフォーマンスＵＰするからだ。
忘れていたが、ＤＲＡＷＧＦＸ．ＣよりもＴＩＬＥＭＡＰ．Ｃの方がパフォーマンスＵＰには効果が高い。
次に色数減でもやるか、（０８：５６）
■３２ビット色はＳＹＳ１では使わんので、削除してみた。
ＤＲＡＷＧＦＸ．Ｏサイズ：３４６ｋｂ→１９１ｋｂ（４５％減） るん♪。
ＤＲＡＷＧＦＸ．Ｃサイズ：１５０ｋｂ→８２ｋＢこれは約半分ってわかるでしょ？
うし、いい感じ〆♂∠√
次にアルファ減でもやるかと思ったけど、いい加減飽きてきた。やっぱ早くＥＢＯＯＴ．ＰＢＰに
もって行きたいから、そんな事より、ちまちまファイル削減しよ。昨日みたいにさ。そりゃ管理人だって、
単純なファイル削減作業は、つまんないからやだよ。でも早くＥＢＯＯＴ．ＰＢＰにしたいっ！（０９：４５）
■ファイル減らすのは盲目的にやってるのではなくて、戦略がいるねん。今なＭＡＭＥ直下のＯＢＪを合計して、
（soundの下とかcpuの下とかpspの下とかそおいうのは含まない）
つまりこいつらがＭＡＭＥシステムな訳やろ。
えーと、１．４９ＭＢな。これ、半分にしよ。目標半分。７５０ＫＢな。妄想やけど。（１０：００）
じゃ、
LIBEXPAT.A ＸＭＬ整形ライブラリ
PROFILER.O リアルタイム性能測定（いったん外す。便利だから後で追加する）
CDROM.O そんなものＳＹＳ１にはない
HARDDISK.O そんなものＳＹＳ１にはない
MD5.O 圧縮ファイルのチェックサム計算をＭＤ５でやる（そんなんＣＲＣだけで十分）
SHA1.O 圧縮ファイルのチェックサム計算をＳＨＡ１でやる（そんなんＣＲＣだけで十分）
をはずそ、このうちＭＤ５とＳＨＡ１は、外すとＣＨＤ．Ｃでごちゃごちゃ訳わからんエラーでる事が、
予想されんねん。あんまし訳わからん事いうてきはったら、なかった事。にしよ。な。
ＣＨＤのシステムが変わってるねん。あんまし自信がないっていうかこのＶＥＲのＭＡＭＥは、
ここ触った事、ないねん。もちっと前のＶＥＲのＭＡＭＥなら、すごく簡単に外せてオイシイ所やったんやけど。
ソース見たら、まだらに融合されてんねん。いーよ、そんな事しないで。そんな所パフォーマンス
要求されないだろ。ソース見て判りやすい（保守性が高い）方が、ここは価値が高いねん。
改悪されとるがな。（１０：２４、でも管理人早起きでちと疲れたから９Ｋ）
さて今（１１：４８）作業再開するか。
■
「x86drc.c」「x86drc.h」はいらんでしょ。
src/expatに退いてもらう。エラー待ち。ついでに「xml2info.c」「xml2info.txt」も外す。
差当たり、まずsrc/debugにも退いてもらおう。ＰＳＰキーボードも付いてないし。
こんなんあってもデバッグできる訳でもなし、現時点では、意味不明だからだ。
だたし、この辺もＭＡＭＥコアに密接に関わってるかもしれないから、（ＶＥＣＴＯＲ．Ｃと似た境遇だな）
ちゃんとはあとではずそ。
とりあえず。退いてもらったディレクトリの中から「mamedbg.h」を拾い出して、src/にコピー。
src/mame.c:146:22: error: harddisk.h: No such file or directory
src/mame.c: At top level:
src/mame.c:226: error: variable 'mame_chd_interface' has initializer but incompl
ete type
うーん、harddiskは判らんから、やっぱ元にもどそ。
現状
「harddisk.h」「harddisk.c」
「md5.c」「md5.h」
「chd.c」「chd.h」
「sha1.c」「sha1.h」
はずす
「chdcd.c」「chdcd.h」
「cdrom.c」「cdrom.h」
ここまで、調べて、「hash.c」をなんとかすれば簡単に外せるかも、しれないと気がついた。
もしかして「旧名：ＣＲＣ．Ｃ→新名：ＨＡＳＨ．Ｃ」に移行してるだけかもしれない。
とりあえず、
src/vidhrdw/vector.cをはずし、vector.hをsrc/へ移動。エラー待ち。
src/machine/の
「idectrl.c」「idectrl.h」「ticket.c」「ticket.h」を外し。エラー待ち。
「core.mak」は現状
# the core object files (without target specific objects;
# those are added in the target.mak files)
OBJS += $(OBJ)/version.o $(OBJ)/mame.o \
$(OBJ)/drawgfx.o $(OBJ)/common.o $(OBJ)/usrintrf.o $(OBJ)/ui_text.o \
$(OBJ)/cpuintrf.o $(OBJ)/cpuexec.o $(OBJ)/cpuint.o $(OBJ)/memory.o $(OBJ)/timer.o \
$(OBJ)/palette.o $(OBJ)/input.o $(OBJ)/inptport.o $(OBJ)/config.o $(OBJ)/unzip.o \
$(OBJ)/audit.o $(OBJ)/info.o $(OBJ)/png.o $(OBJ)/artwork.o \
$(OBJ)/tilemap.o $(OBJ)/fileio.o \
$(OBJ)/state.o $(OBJ)/datafile.o $(OBJ)/hiscore.o \
$(sort $(CPUOBJS)) \
$(OBJ)/sndintrf.o \
$(OBJ)/sound/streams.o $(OBJ)/sound/mixer.o $(OBJ)/sound/filter.o \
$(sort $(SOUNDOBJS)) \
$(OBJ)/vidhrdw/generic.o $(OBJ)/machine/eeprom.o $(OBJ)/machine/random.o \
$(OBJ)/profiler.o \
$(OBJ)/hash.o $(OBJ)/sha1.o $(OBJ)/chd.o $(OBJ)/md5.o \
$(OBJ)/sound/wavwrite.o
#$(OBJ)/vidhrdw/vector.o
#$(OBJ)/machine/idectrl.o
#$(OBJ)/harddisk.o
#$(OBJ)/cdrom.o
#ifdef NEW_DEBUGGER
#OBJS += $(OBJ)/debug/debugcmd.o \
#$(OBJ)/debug/debugcpu.o \
#$(OBJ)/debug/debugexp.o \
#$(OBJ)/debug/debugvw.o \
#$(OBJ)/debug/debughlp.o \
#$(OBJ)/debug/debugcon.o
#else
#OBJS += $(OBJ)/debug/mamedbg.o $(OBJ)/debug/window.o
#endif
#ifdef X86_MIPS3_DRC
#OBJS += $(OBJ)/x86drc.o
#endif
#OBJS += $(sort $(DBGOBJS))
#TOOLS = romcmp$(EXE) chdman$(EXE) xml2info$(EXE)
こんなとこ。とりあえずprofilerは保留。
あとmakefileも
# NEW_DEBUGGER = 1
#X86_MIPS3_DRC = 1
#X86_PPC_DRC = 1
# BUILD_EXPAT = 1
略
# start with an empty set of libs
LIBS =
#ifdef BUILD_EXPAT
#CFLAGS += -Isrc/expat
#OBJDIRS += $(OBJ)/expat
#EXPAT = $(OBJ)/libexpat.a
#else
###LIBS += -lexpat
EXPAT =
#endif
略
# secondary libraries
#$(OBJ)/libexpat.a: $(OBJ)/expat/xmlparse.o $(OBJ)/expat/xmlrole.o $(OBJ)/expat/xmltok.o
■さてごちゃごちゃいじったんで「make」↓（１２：２３）
src/mame.c: In function 'update_video_and_audio':
src/mame.c:1300: error: 'vector_dirty_list' undeclared (first use in this functi
on)
src/mame.c:1300: error: (Each undeclared identifier is reported only once
src/mame.c:1300: error: for each function it appears in.)
make: *** [obj/namcos1psp2/mame.o] Error 1
「mame.c」
// /* set the vector dirty list */
// if (Machine->drv->video_attributes & VIDEO_TYPE_VECTOR)
// if (!full_refresh_pending && !ui_dirty && !skipped_it)
// {
// current_display.vector_dirty_pixels = vector_dirty_list;
// current_display.changed_flags |= VECTOR_PIXELS_CHANGED;
// }
■vector.hをsrc/へ移動してたのは、方針を変えることにした。
vector.hを何故残すのかというのは、
「ＭＡＭＥはvector.hより前に必ずartwork.hをインクルードしなければいけない。」
これは「必ず」なので、エンバグ（単にコンパイルエラーが出て止まるだけだが）
の入り込む余地があるだろう。
だから、最近のＭＡＭＥのソースリストでは、従来artwork.hをインクルードしていた位置に、
vector.hをインクルードすることで、この問題を避けている。
vector.hで、さしあたり重要なのはvector.hの頭でartwork.hをインクルードしている事だけだ。
src/mame.c:144:28: error: vidhrdw/vector.h: No such file or directory
と似たエラーが出たら、
#include "vidhrdw/vector.h"
を
#include "artwork.h"
に置換しよう。
「mame.c」の場合は、その前に
#include "artwork.h"
が既にあるから、単純に削除してしまえば良い。（ＳＹＳ１で復活する可能性はないし）
■しかし、あれやな。blogじゃなくてlogになってるな。まあええねん。
src/usrintrf.c: In function 'onscrd_vector_flicker':
src/usrintrf.c:3712: warning: implicit declaration of function 'vector_get_flick
er'
src/usrintrf.c:3718: warning: implicit declaration of function 'vector_set_flick
er'
src/usrintrf.c: In function 'onscrd_vector_intensity':
src/usrintrf.c:3733: warning: implicit declaration of function 'vector_get_inten
sity'
src/usrintrf.c:3739: warning: implicit declaration of function 'vector_set_inten
sity'
make: *** [obj/namcos1psp2/usrintrf.o] Error 1
やっとＵＳＲＩＮＴＲＦ．Ｃでエラーが出たな。
このＯＮＳＣＲＤ＿なんちゃらってのは、ＯＮ＿ＳＣＲＥＥＮ＿ＤＩＳＰＬＡＹ＿ＭＥＮＵで、
（訳：画面上に表示メニュー）
要するに「ボリューム変えたいな」。とか「明るさまぶしいな」とか、
「青みがキツイけど、俺のＰＣじゃないしディスプレイ画面の設定勝手に弄ったらまずいっしょ」
とかそおいう需要にこたえた。サブメニューで、
ＰＳＰはボリューム調整できるし、色味調整なんて、要らないし、仮にやるにしたって
サブメニューでやることないし。
つまり、とっちまえ。
いらんオン、スクリーンのサブメニューなんて役にたたん。ＰＳＰでは。
（ＰＣでは、色味は要らんのでＶＯＬＵＭＥ調整だけ残した。昔は）
不便ならもっと別のメニューを追加しような。
終了機能と同じで他で出来るから、単なる容量の無駄だ。ＰＳＰでは。
削除さくじょ。（１２：５５）
「usrintrf.c」ソース１３０ｋｂ→１１５ｋｂになった。
■
src/memory.c:2524: warning: cast increases required alignment of target type
src/memory.c: In function 'io_read_qword_64le':
src/memory.c:2525: warning: cast increases required alignment of target type
src/memory.c: In function 'io_write_word_64le':
src/memory.c:2527: warning: cast increases required alignment of target type
src/memory.c: In function 'io_write_dword_64le':
src/memory.c:2528: warning: cast increases required alignment of target type
src/memory.c: In function 'io_write_qword_64le':
src/memory.c:2529: warning: cast increases required alignment of target type
src/memory.c: In function 'cpu_readop16_safe':
src/memory.c:2545: warning: cast increases required alignment of target type
src/memory.c: In function 'cpu_readop32_safe':
src/memory.c:2551: warning: cast increases required alignment of target type
src/memory.c: In function 'cpu_readop64_safe':
src/memory.c:2557: warning: cast increases required alignment of target type
src/memory.c: In function 'cpu_readop_arg16_safe':
src/memory.c:2569: warning: cast increases required alignment of target type
src/memory.c: In function 'cpu_readop_arg32_safe':
src/memory.c:2575: warning: cast increases required alignment of target type
src/memory.c: In function 'cpu_readop_arg64_safe':
src/memory.c:2581: warning: cast increases required alignment of target type
make: *** [obj/namcos1psp2/memory.o] Error 1
ぐあーっ。ついに来たか。エミュでもっとも効果が高いが、バグも入りやすい所。
出来れば１ｓｔ版が動いてから弄りたい所。
ちょっと弄ると、鬼のようにパフォーマンスが向上する所。ＥＸＥＣ関係と並んで。
そろそろお腹減ってきたんでお昼にするよ（１３：２８）ふう、作って食べた。（１４：０２）
メモリはＳ１には明らかにタコな事、解りきってるし、手をつけたくてうずうずしてるが、
１ｓｔコンパイルが動くまで封印な。だって、ＵＳＲＩＮＴＲＦとかＤＲＡＷＧＦＸとかとは、
レベルが違う。仮にエンバグするとして。ＵＳＲＩＮＴＲＦとかＤＲＡＷＧＦＸとかは、
あはっへーーんながーーめん。なーーおそーーーっ。で済むけど、
ＭＥＭＯＲＹエンバグした日にゃ。
メニュウは動くんだけどＲＯＭも読んでる臭いんだけど実行できません。
原因も判らない、どおしたらいいんだぁーーーー。と。
猪木になってしまう事、安請け合い。
嫌。それだけは、嫌。
幸い「debugcpu.h」「debugexp.h」を追加したら、先に進んだ。
触らぬメモリに祟り...あるかも知れない。
■
src/config.c:535: error: 'p' undeclared (first use in this function)
src/config.c: At top level:
src/config.c:560: warning: type defaults to 'int' in declaration of 'XML_Char'
src/config.c:560: error: parse error before '*' token
src/config.c:561: warning: function declaration isn't a prototype
src/config.c: In function 'config_data':
src/config.c:563: error: 'len' undeclared (first use in this function)
src/config.c:565: error: 's' undeclared (first use in this function)
src/config.c: In function 'config_load_xml':
src/config.c:581: error: 'XML_Parser' undeclared (first use in this function)
src/config.c:581: error: parse error before 'parser'
src/config.c:599: error: 'parser' undeclared (first use in this function)
src/config.c:599: warning: implicit declaration of function 'XML_ParserCreate'
src/config.c:604: warning: implicit declaration of function 'XML_SetElementHandl
er'
src/config.c:605: warning: implicit declaration of function 'XML_SetCharacterDat
aHandler'
src/config.c:622: warning: implicit declaration of function 'XML_Parse'
src/config.c:622: error: 'XML_STATUS_ERROR' undeclared (first use in this functi
on)
src/config.c:642: warning: implicit declaration of function 'XML_ParserFree'
make: *** [obj/namcos1psp2/config.o] Error 1
出るべくして出したエラー達。
だってＸＭＬなんざ要らん。って開発方針。
ＸＭＬなんて使ってるとママに怒られるもん。知らないデーターとお話したら、いけないんだもん。
はい、そうですか。
じゃ、削除開始。（１４：１４）
struct config_file
{
mame_file * file; /* handle to the file */
int filetype; /* what type of config file is this? */
struct config_data data; /* the accumulated data */
// struct config_parse parse; /* parsing info */
};
ここの構造体が少し短くなったけど、まあ多分大丈夫じゃろ。
ＸＭＬのコンフィグは読み書き出来なくした。
■
src/artwork.c:1635: error: 'vector_pixel_t' undeclared (first use in this functi
on)
src/artwork.c:1635: error: parse error before 'offset'
src/artwork.c:1636: error: 'list' undeclared (first use in this function)
src/artwork.c:1641: error: 'VECTOR_PIXEL_END' undeclared (first use in this func
tion)
src/artwork.c:1643: error: parse error before 'coords'
src/artwork.c:1644: error: 'coords' undeclared (first use in this function)
src/artwork.c:1646: error: 'offset' undeclared (first use in this function)
src/artwork.c:1656: error: parse error before 'coords'
src/artwork.c: In function 'render_game_bitmap_underlay_overlay':
src/artwork.c:1776: error: 'vector_pixel_t' undeclared (first use in this functi
on)
src/artwork.c:1776: error: parse error before 'offset'
src/artwork.c:1777: error: 'list' undeclared (first use in this function)
src/artwork.c:1782: error: 'VECTOR_PIXEL_END' undeclared (first use in this func
tion)
src/artwork.c:1784: error: parse error before 'coords'
src/artwork.c:1785: error: 'coords' undeclared (first use in this function)
src/artwork.c:1787: error: 'offset' undeclared (first use in this function)
src/artwork.c:1797: error: parse error before 'coords'
make: *** [obj/namcos1psp2/artwork.o] Error 1
ふふ。遂に来ましたね。アートワークです。
アートワークでやってくれる事。
１．ゲーム画面が寂しいなと思ったときに背景が付けられる。
２．ゲーム画面を見にくくして難しくする為に前景が付けられる。（一部嘘）
ＭＡＭＥ本家にいくと、たくさんアートワークの画像がＤＬできます。
が、
遅いＰＣではより遅くなる。
遅いＰＳＰも、もっと遅くなる。
うーん、いいことづくめ。
取って、お仕舞い！
(14:32)
■
ううん、ＡＲＴＷＯＲＫに関しては全域弄ったからな。書くのがめんどい。
基本的にこんな感じ。
/* get the effective screen size, including artwork */
// artwork_get_screensize(&w, &h);
w = Machine->drv->screen_width;
h = Machine->drv->screen_height;
でも２３個所「artwork_get_screensize」で検索すれば、出てくる。
ここをなんで
void artwork_get_screensize(int *width, int *height)
{
*width = Machine->drv->screen_width;
*height = Machine->drv->screen_height;
}
としないのか、こんなとこ、大してパフォーマンスに影響しないよってのは、理由があって、
後の最適化に繋がるからなんである。つまり動いたらMachine->drvは弄るって事。
それの複線ね。（検索、置換を有効活用するため、まあマクロしといてもいいんだけどさ）
で、「mame.c」では
/* enable artwork now */
//artwork_enable(1);
とか、
/* initialize the display through the artwork (and eventually the OSD) layer */
if (osd_create_display(¶ms, direct_rgb_components /*,artcallbacks*/))
goto cant_create_display;
あとは忘れたが、
いろいろやった。
あとベクター関係も殺した。
で、「make clean」↓「make」↓
ふうここまでは問題ないみたい。先にすすもう。でも、ちっと休憩（っていうかゲームタイム。
別に遊んでたっていいだろ１６：０１）
■で、しばらくゲームで遊んで、疲れたから寝た。んで起きた。（１８：００）
人間寝て起きると、アイデアが浮かぶものである。
「Makefileは本当に悪くないんだろうか？」
管理人の疑問である。プログラムＯＫで、ＤＧＥＮみたいにＭａｋｅｆｉｌｅ難ありで（-lc）
うまく動かないのは、やりきれない。
今のうちにその芽を潰しておこう。
専門的な事が、判らなくったって、いいアイデアが浮かんだんである。
もちろん普通の（正統的な）方法ではないし、専門家がみたら、笑っちゃうだろう。
でもいいの出来れば。
で、その方法とは、
■事実その１．お魚さんのMakefileは正常に動いていて、コンパイルもとうるし、ゲームも遊べるんだから。
これはＯＫ．の筈。
■事実その２．ＭＡＭＥのMakefileはコンパイルはとうるが、ＥＢＯＯＴ．ＰＢＰまで生成できんし、ＯＫかどうか判らない。
■事実その３．しかしながら、ＭＡＭＥのMakefileはmapファイルを生成し中身を見た（もちろん意味はわからん）
けど、お魚さんの生成するＭＡＰファイルと似てる。
■事実その４．ＭＡＭＥのMakefileを実行するとＯＢＪファイルはすべて生成する。
■事実その５．ＭＡＭＥのMakefileが生成したＭＡＰファイルにはリンクしようとしたＯＢＪファイルが、
フルパスでコメントされている。
そうか、判ったぞ。
「ＭＡＭＥのMakefileを実行してＯＢＪファイルをすべて生成させた状態」で、
「ＭＡＭＥのMakefileが生成したＭＡＰファイル」とまったく同じ順序でリンクするように
お魚さんのMakefileをコピーしたものを改造し、Ｍakeすれば、
上手くいけばＥＢＯＯＴ．ＰＢＰが生成される。
うーん。やってみたけど駄目でした。
でも、「改造版お魚さんMakefileが生成したＭＡＰファイル」が出来た。
瓢箪から駒というか、棚から牡丹餅というか、
こんなものが出来たら。
「ＭＡＭＥのMakefileが生成したＭＡＰファイル」と比較しない訳には、いくまい。
で、比較したら、アドレスが違う。
#8900000 osakana
#8810000 psp mame04
では、再改造してアドレスもあわせて比較。
結果。ほぼ同じものです。
■つまり、Makefileは悪くないんじゃないかな。だってお魚さんのだって遊べる（ＰＳＰで動く）んだもん。
ってのが結論。徒労だけど、やっぱソース、ダイエットしよ。
今ＯＢＪ合計が２．２ＭＢ程度。お魚さんのＥＢＯＯＴが１．４ＭＢ程度だから、その辺まで
ダイエットすれば、ひょっとすると、ひょっとする。
昔は４ＭＢとかあったからな。過去日記確認しないと正確な数字は忘れたけどね。
もう夕食だって。（１８：２８）
■過去日記、確認したじぇ。３日前の奴だ。ＯＢＪ３．３４ＭＢって書いてある。
今、ＴＩＬＥＭＡＰを３２ＫＢにした（ＲＯＺと３２ビットを削除した）から、でもやっぱ２．２０ＭＢ。
こいつをもっと減らせばいいんだな。じゃ次はＩＮＰＵＴＰＯＲＴだな。あそこは減るからな。
使わない設定が山ほどある。光線銃だのハンドルだの１Ｐから８Ｐぐらいまで全部そろってるからな。
ＰＳＰなら多くても２Ｐまででいいだろ。１Ｐのみだって何の問題もない。いまＯＢＪが１３３ＫＢ。
さてどこまで減るかな。（１９：４８）
■うし、ＯＢＪが５０ｋｂになった。もっと削れるけど、程々にしておく。（２０：０２）
今、ＯＢＪが計２．１２ＭＢ。
「cheat.o」が１３５ＫＢあるぞ。これいらなくないか？管理人これ使った事ないんだけど。
どおしても「ズル」したかったら別の方法で実装するとか。っていうか。ＳＹＳ１の「ズル」って、どっかで
解析されてんのかな？ＷＥＢ探せばきっとあるだろな。その場合。ＣＨＥＡＴファイルがあれば、
エミュレーター本体にハードコーティングして実装してもいいよ。ＲＡＩＮのＶＥＲチェンジと同じやり方でさ。
メニュー出して。人数とか、面とか、無敵とか、おもむろに出てくるって仕掛け。こんなの実装するのは、
簡単だろＲＡＭ書き換えるだけなんだから。つう訳で、ＣＨＥＡＴ．Ｃは要らんな。
とっちまえ。（汎用品はでかいの、専用なら小さくなる）
（２０：１０）
■今、ＯＢＪが計１．９９ＭＢ。
いい加減リンカ通れよ。もしかしたら順序が悪いのか？順序変えたら、なんとかなる可能性って、
あるんじゃないのか？（２０：２６）
（今０２／１８－０１：０９ぐらい）
■アメブロの混んでる時間とうりすぎたみたい。やっぱ本来夜型だから、無理はいけないんだけど、
ああでも寝ないとな。それはともかく、さすがに夜は頭が働く。やっぱＷＥＢ更新しないで進めると
はええ。しまった。このページの存在意義がなくなってしまう。ＷＥＢ更新のペースで１日分グライ
先に進んでしまったので、既にlogの意味もなくなってしまった。うーん、残念。
今ねえＯＢＪは１．９１ＭＢそんなに変わってないが、ソースは既に別物に。多分リンカのエラー
確認してないから、現状昨日よりバグだらけかもしんない。でもそれは構造的バグではなくて、
要らん関数がないとか、少なくとも管理人が見ればすぐ外せる類の物。
■リンカで標準関数系のエラーばっかり出るから、ちょうどＯＢＪの半分くらいの位置に、（どっちからでも
届くでしょ？）試験的に「_clib」を配置してみた。こいつの中身は、リンカでエラーが出たもの以外入ってない。
なのにこんなエラー。
In file included from src/psp/_clib.c:5:
src/psp/_clib.h:17: warning: conflicting types for built-in function 'memset'
src/psp/_clib.h:19: warning: conflicting types for built-in function 'memcpy'
src/psp/_clib.h:28: warning: function declaration isn't a prototype
src/psp/_clib.c:16:1: warning: "PI" redefined
:1:1: warning: this is the location of the previous definition
src/psp/_clib.c:99: warning: function declaration isn't a prototype
src/psp/_clib.c:112: warning: conflicting types for built-in function 'strcpy'
src/psp/_clib.c: In function 'memset':
make: *** [obj/namcos1psp2/psp/_clib.o] Interrupt
訳：「注意、内蔵のライブラリと競合してるちゅー。」
おまえな、さっきは、みえねー。とか言っておきながら、見えるところに設置してやれば、ＷＡＲＩＮＧ。
どないせいちゅーんや。でもまあ、さっきはエラー今度はワーニング。このままＳＣＥのライブラリ使って、
いい加減なCLIB作成して、なんとかなるんだろうか？やっぱ’‐ｌｃ’を付ければ、一発解決なんだろか。
ちとやってみよ。（０１：２３）
■-lcをただつけるだけでは、駄目みたい。不思議な事にオプションをつける位置によってまるっきり動作が
違う。
$(LD) -lc -O0 $^ $(LIBS) -M -Ttext 8810000 -q -o out > main.map
これだと、全然だめ。効いてないみたい。
$(LD) -O0 $^ $(LIBS) -lc -M -Ttext 8810000 -q -o out > main.map
これだと、標準ライブラリ系の（strcpyとかsprintfとかmemcpyとか、あの辺）エラーは一つも出ない。
が、フロートライブラリ系のエラーがバリバリでる。上の状態でも、それは出てたんだけど。
こんな感じ。
■
../../../../../newlib/libc/stdlib/dtoa.c:511: undefined reference to `__muldf3'
../../../../../newlib/libc/stdlib/dtoa.c:513: undefined reference to `__fixdfsi'
../../../../../newlib/libc/stdlib/dtoa.c:514: undefined reference to `__floatsidf'
../../../../../newlib/libc/stdlib/dtoa.c:514: undefined reference to `__subdf3'
../../../../../newlib/libc/stdlib/dtoa.c:518: undefined reference to `__adddf3'
../../../../../newlib/libc/stdlib/dtoa.c:518: undefined reference to `__ltdf2'
../../../../../newlib/libc/stdlib/dtoa.c:520: undefined reference to `__subdf3'
../../../../../newlib/libc/stdlib/dtoa.c:520: undefined reference to `__gtdf2'
../../../../../newlib/libc/stdlib/dtoa.c:343: undefined reference to `__adddf3'
../../../../../newlib/libc/stdlib/dtoa.c:442: undefined reference to `__divdf3'
/usr/local/pspdev/psp/bin/../psp/lib/libc.a(mprec.o): In function `_ratio':
../../../../../newlib/libc/stdlib/mprec.c:943: undefined reference to `__divdf3'
../../../../../newlib/libc/stdlib/mprec.c:943: undefined reference to `__divdf3'
/usr/local/pspdev/psp/bin/../psp/lib/libc.a(mprec.o): In function `_mprec_log10':
../../../../../newlib/libc/stdlib/mprec.c:983: undefined reference to `__muldf3'
make: *** [EBOOT.PBP] Error 1
やっぱ'-lc'は想像したとおり、「Ｃのライブラリを使う（ってリンク）」と言う意味としか考えられない。
/usr/local/pspdev/psplib/gcc/psp/4.0.0/libgcc.a を使って欲しいんだけどな。
いっその事。これコピーして、直リンクさせるか。設定わかんないから。ちょっとやってみよ。
その場合は-lcいらんじゃろ。（０２／１８－０１：４６）
■
$(LD) -O0 $^ $(LIBS) ./libgcc.a ./libgcov.a -lc -M -Ttext 8810000 -q -o out > main.map
既にやりたい放題だな。LIBSの最後にはZIPLIB.A UNZIPLIB.Aも入ってる。
obj/namcos1psp2/psp/pspmain.o: In function `Draw_All':
pspmain.c:(.text+0x23c): undefined reference to `drivers'
obj/namcos1psp2/psp/pspmain.o:pspmain.c:(.text+0x240): more undefined references to `drivers' follow
/usr/local/pspdev/psp/bin/../psp/lib/libc.a(strtod.o): In function `_strtod_r':
../../../../../newlib/libc/stdlib/strtod.c:563: undefined reference to `__ledf2'
../../../../../newlib/libc/stdlib/strtod.c:556: undefined reference to `__nedf2'
../../../../../newlib/libc/stdlib/strtod.c:389: undefined reference to `__nedf2'
../../../../../newlib/libc/stdlib/strtod.c:393: undefined reference to `__nedf2'
/usr/local/pspdev/psp/bin/../psp/lib/libc.a(vfprintf.o): In function `_vfprintf_r':
../../../../../newlib/libc/stdio/vfprintf.c:1186: undefined reference to `__nedf2'
../../../../../newlib/libc/stdio/vfprintf.c:1304: undefined reference to `__nedf2'
/usr/local/pspdev/psp/bin/../psp/lib/libc.a(dtoa.o):../../../../../newlib/libc/s
tdlib/dtoa.c:282: more undefined references to `__nedf2' follow
make: *** [EBOOT.PBP] Error 1
どおしてもＭＡＭＥのdriversが見えないのも謎だし。うちにはＰＳＰ用のlibcなんてないよ。多分。
strtodとvfprintfなら（Ｃ言語の標準ＬＩＢだから）判るけど、他のは何？'_r'が付いてると「レジスタ使え」って事？
`__ledf2'とか`__nedf2'って、アンダースコアが２つだから、アッセンブラ？のラベル？vfprintf.cならともかく、
strtod.cってそんなに複雑な事してんの？要らないよそんな複雑なＶＥＲ．こうなったら、どっかから、
ライブラリのソース持ってきて自前で全部やるか。libc手に入れれば、何とかなりそうでしょ？
とにかく良く判らん。特にリンカがわからん。今日はもう、寝よ。おやすみなさい。（０２：０２）
