■朝起きたら管理画面が変わってた。ふう、アメブロ、ガンガッタんだな。良かった、よかった。
psp/machine/6821pia.o obj/namcos1psp/machine/8255ppi.o obj/namcos1psp/machine/74
74.o obj/namcos1psp/machine/74123.o obj/namcos1psp/machine/74153.o obj/namcos1ps
p/machine/74148.o obj/namcos1psp/vidhrdw/generic.o obj/namcos1psp/vidhrdw/vector
.o obj/namcos1psp/vidhrdw/avgdvg.o obj/namcos1psp/machine/mathbox.o obj/namcos1p
sp/vidhrdw/poly.o obj/namcos1psp/vidhrdw/matrix3d.o obj/namcos1psp/vidhrdw/tlc34
076.o obj/namcos1psp/machine/ticket.o obj/namcos1psp/machine/eeprom.o obj/namcos
1psp/machine/6522via.o obj/namcos1psp/machine/mb87078.o obj/namcos1psp/profiler.
o obj/namcos1psp/hash.o obj/namcos1psp/sha1.o obj/namcos1psp/chd.o obj/namcos1ps
p/harddisk.o obj/namcos1psp/md5.o obj/namcos1psp/machine/idectrl.o obj/namcos1ps
p/cdrom.o obj/namcos1psp/sound/wavwrite.o obj/namcos1psp/debug/debugcmd.o obj/na
mcos1psp/debug/debugcpu.o obj/namcos1psp/debug/debugexp.o obj/namcos1psp/debug/d
ebugvw.o obj/namcos1psp/debug/debughlp.o obj/namcos1psp/debug/debugcon.o obj/nam
cos1psp/cheat.o obj/namcos1psp/psp/psp.o obj/namcos1psp/psp/video.o obj/namcos1p
sp/psp/blit.o obj/namcos1psp/psp/sound.o obj/namcos1psp/psp/input.o obj/namcos1p
sp/psp/rc.o obj/namcos1psp/psp/misc.o obj/namcos1psp/psp/ticker.o obj/namcos1psp
/psp/config.o obj/namcos1psp/psp/fronthlp.o obj/namcos1psp/psp/fileio.o obj/namc
os1psp/psp/debugwin.o obj/namcos1psp/psp/syscalls.o obj/namcos1psp/psp/pg.o obj/
namcos1psp/psp/pspmain.o obj/namcos1psp/psp/menu.o obj/namcos1psp/psp/y_malloc.o
obj/namcos1psp/psp/v_malloc.o obj/namcos1psp/libexpat.a obj/namcos1psp/libz.a
-Wl,-Ttext=0x08810000 -M -o EBOOT.PBP
psp-gcc-4.0.0: obj/namcos1psp/psp/startup.o: linker input file unused because linking not done
psp-gcc-4.0.0: obj/namcos1psp/machine/namcos1.o: linker input file unused because linking not done
以下略
もう書くの面倒になってきちゃったんだけど。えーと、
とにかくＭＡＭＥ１０２の事は忘れて、サウンド関係はＭＡＭＥ０．８２準拠とした。
単純に構造体を弄っても駄目だぞ。マクロも弄らないと数の辻褄が合わなくなる。
めんどいし、管理人の直感が「そんなやり方では絶対にエンバグする。」と言うので、
サウンド関係は弄るの止めた。コンパイルが優先。
■問題となっている「sndintrf.c」については、さしあたりＭＡＭＥ０．８２のものと入れ替え、
一応この辺は危なそうなんで、殺したがもっと殺さないと危ないかもしれん。（が、コンパイルはとうる）
#if 000
streams_sh_update();
mixer_sh_update();
#endif
このＭＡＭＥのストリーム更新。とＭＡＭＥのＭＩＸＥＲは、タコ（本格的すぎる）だから、
（パフォーマンスを上げたい人は）誰でも弄る所だ。
当然ＰＳＰ＿ＭＡＭＥ０４Ｓも弄っているので、
ここは後で、ＰＳＰ＿ＭＡＭＥ０４Ｓの「sndintrf.c」から移植せねば、話にならん。
■ＭａｋｅＦｉｌｅも少し変えた。
# $(LD) -O0 $^ $(LIBS) -M -Ttext 8810000 -q -o out > main.map
→
$(LD) $^ $(LIBS) -Wl,-Ttext=0x08810000 -M -o $@
# $(AR) cr $@ $^
→
$(AR) rcs $@ $^
#LIBS = -lc -lm /usr/local/lib/gcc/mipsel-elf/3.4.2/libgcc.a
→
LIBS =
まずアーカイバはコンパイラドライバ経由じゃ何故かやってくれなかったので、
AR = psp-ar
CC = psp-gcc-4.0.0
LD = psp-gcc-4.0.0
ASM = xxxx_mipsel-elf-as
STRIP =psp-strip
にした。あれぇ、アセンブラにダミー書いといたのがまずいのかな
■それは、全然関係がなかったんだが、アセンブルオプション見直したら。エラーが出た。
$ make
Assembling src/psp/startup.S...
psp-gcc-4.0.0 -o obj/namcos1psp/psp/startup.o -mgp32 -mlong32 -msingle-float -ma
bi=eabi src/psp/startup.S
/cygdrive/c/WINDOWS/TEMP/ccKk01dq.o: In function `_start':
src/psp/startup.S:(.text+0x2c): undefined reference to `xmain'
src/psp/startup.S:(.text+0x30): undefined reference to `xmain'
collect2: ld returned 1 exit status
make: *** [obj/namcos1psp/psp/startup.o] Error 1
エラー大好き♪。バグが減って嬉しい。（本当だな！）
さて、startup.Sか、ＰＳＰ開発はstartup.Sは避けてはとうれんなぁ。
取り敢えず、"Hello World"→"USERPROG"はやっても変わらん。（まあ当たり前か）
■
# startup functions
$(OBJ)/psp/startup.o: src/psp/startup.S
@echo Assembling $<...
# $(CC) -o $@ $(ASMFLAGS) $(subst -D,-d,$(ASMDEFS)) $<
→
$(CC) $(ASMFLAGS) -c $< -o $@
で、直った。
が、相変わらず、コンパイルがとおって、リンカでこける状態。
そもそもこのメッセージ、意味が良く判らんのですが、
■
略
psp-gcc-4.0.0: obj/namcos1psp/psp/syscalls.o: linker input file unused because linking not done
psp-gcc-4.0.0: obj/namcos1psp/psp/pg.o: linker input file unused because linking not done
psp-gcc-4.0.0: obj/namcos1psp/psp/pspmain.o: linker input file unused because linking not done
psp-gcc-4.0.0: obj/namcos1psp/psp/menu.o: linker input file unused because linking not done
psp-gcc-4.0.0: obj/namcos1psp/psp/y_malloc.o: linker input file unused because linking not done
psp-gcc-4.0.0: obj/namcos1psp/psp/v_malloc.o: linker input file unused because linking not done
psp-gcc-4.0.0: obj/namcos1psp/libexpat.a: linker input file unused because linking not done
psp-gcc-4.0.0: obj/namcos1psp/libz.a: linker input file unused because linking not done
psp-gcc-4.0.0: -Ttext=0x08810000: linker input file unused because linking not done
outpatch
make: outpatch: Command not found
make: *** [EBOOT.PBP] Error 127
outpathで止まってるのはダミーだ。先に進んで欲しくないので、わざと入れてない。
直訳すると：リンカは入力ファイルを使わなかった。何故ならリンクが終わってないからだ。
英語は判るが、文章の意味が良く解からん。
「linking not done」ってどおいう事？
あ、おひるーぅ♪（１２：１４）
■
obj/namcos1psp/psp/v_malloc.o obj/namcos1psp/libexpat.a obj/namcos1psp/libz.a -
nostartfiles -Wl,-Ttext=0x08810000 -o EBOOT.PBP
/usr/local/pspdev/psp/bin/psp-ld: obj/namcos1psp/machine/namcos1.o: linking mips
:4000 module with previous mips:allegrex modules
/usr/local/pspdev/psp/bin/psp-ld: failed to merge target specific data of file o
bj/namcos1psp/machine/namcos1.o
/usr/local/pspdev/psp/bin/psp-ld: obj/namcos1psp/vidhrdw/namcos1.o: linking mips
:4000 module with previous mips:allegrex modules
/usr/local/pspdev/psp/bin/psp-ld: failed to merge target specific data of file o
bj/namcos1psp/vidhrdw/namcos1.o
/usr/local/pspdev/psp/bin/psp-ld: obj/namcos1psp/drivers/namcos1.o: linking mips
:4000 module with previous mips:allegrex modules
/usr/local/pspdev/psp/bin/psp-ld: failed to merge target specific data of file o
bj/namcos1psp/drivers/namcos1.o
/usr/local/pspdev/psp/bin/psp-ld: obj/namcos1psp/drivers/namcoic.o: linking mips
:4000 module with previous mips:allegrex modules
/usr/local/pspdev/psp/bin/psp-ld: failed to merge target specific data of file o
bj/namcos1psp/drivers/namcoic.o
/usr/local/pspdev/psp/bin/psp-ld: obj/namcos1psp/machine/random.o: linking mips:
4000 module with previous mips:allegrex modules
/usr/localmake: *** [EBOOT.PBP] Interrupt
リンカのオプションはこんな感じに変更した。
#LINK_OPT = -Wl,-Ttext=0x08810000 -M
↓
LINK_OPT = -nostartfiles -Wl,-Ttext=0x08810000
略
$(LD) $^ $(LIBS) $(LINK_OPT) -o $@
今度はコンパイルオプションを見直さなくちゃ。
コンパイルしたけど（この形式じゃ）リンクできねーっ。って事らしい。
コンパイル時に変なオプションついてたけど、はづしたら動かないかもしれないし、触んなかった。
ＥＥ－ＧＣＣじゃなくてこいつは、mipsel-elf-gccか、とにかくその辺、ＧＣＣ４．０．０と違うんじゃろ。
ううん、なんだか少し風邪がぶり返して調子が悪いんで少し休憩ね（１４：０３）
■
また実験再開したんだけど、-march=r4000は取らないと駄目っぽい。（まだコンパイル中）
「sndintrf.c」「sndintrf.h」の「sound_update()」は「sound_frame_update()」に変更。
deflate.c:(.text+0x41c): undefined reference to `memset'
obj/namcos1psp/libz.a(deflate.o): In function `deflateCopy':
deflate.c:(.text+0x968): undefined reference to `memcpy'
deflate.c:(.text+0x97c): undefined reference to `memcpy'
deflate.c:(.text+0x990): undefined reference to `memcpy'
deflate.c:(.text+0x9a0): undefined reference to `memcpy'
obj/namcos1psp/libz.a(deflate.o): In function `fill_window':
deflate.c:(.text+0xc84): undefined reference to `memcpy'
obj/namcos1psp/libz.a(deflate.o):deflate.c:(.text+0xd74): more undefined referen
ces to `memcpy' follow
obj/namcos1psp/libz.a(deflate.o): In function `deflate':
deflate.c:(.text+0x2818): undefined reference to `memset'
deflate.c:(.text+0x2880): undefined reference to `memcpy'
obj/namcos1psp/libz.a(inflate.o): In function `updatewindow':
inflate.c:(.text+0xc8): undefined reference to `memcpy'
inflate.c:(.text+0x150): undefined reference to `memcpy'
inflate.c:(.text+0x190): undefined reference to `memcpy'
inflate.c:(.text+0x1ac): undefined reference to `memcpy'
obj/namcos1psp/libz.a(inflate.o):inflate.c:(.text+0x760): more undefined referen
ces to `memcpy' follow
collect2: ld returned 1 exit status
make: *** [EBOOT.PBP] Error 1
■うし、やっとリンカがとうったよ。やっとＣ言語らしくなって来た。ここまでくれば、ビニールのぷちつぶすみたいに、ぷちぷち、ぷちぷち、つぶすだけだ。
現在リンカエラーが何千もあるが（数えた訳ではない）同じ物が多いので、大した量ではない。
上のエラーを見れば判るが`memcpy'一っこ付けるだけで３００個とか減るだろうからな。
あと２日ってとこかな。
ここまでくれば勝ったようなもんだな。多分。致命的ななんかは、ないだろ？ＰＳＰで動かしてる人が
いるんだからさ。あくまで、管理人は時代に乗り遅れてのこのこ後からついてってるだけ、フロンティアは
大変だろな。なった事ないからわからんけれどな。
今日は疲れたから（なんだか頭がぼーっとしてさ）別館いじってあそぼ。
ここはたぶん店じまい。（０２／１５－１６：０７）
■
...と思ったのは頭がぼけてたからや！
絶対におかしい。
obj/namcos1psp/mame.o: In function `machine_remove_cpu':
mame.c:(.text+0x904): undefined reference to `strcmp'
mame.c:(.text+0x96c): undefined reference to `memmove'
mame.c:(.text+0x97c): undefined reference to `memset'
obj/namcos1psp/mame.o: In function `machine_find_sound':
mame.c:(.text+0xa64): undefined reference to `strcmp'
obj/namcos1psp/mame.o: In function `machine_remove_sound':
mame.c:(.text+0xb14): undefined reference to `strcmp'
mame.c:(.text+0xb80): undefined reference to `memmove'
obj/namcos1psp/mame.o: In function `mame_chd_open':
mame.c:(.text+0xc00): undefined reference to `strchr'
obj/namcos1psp/mame.o: In function `mame_validitychecks':
mame.c:(.text+0xe2c): undefined reference to `drivers'
mame.c:(.text+0xe30): undefined reference to `drivers'
mame.c:(.text+0xe90): undefined reference to `memset'
mame.c:(.text+0xf38): undefined reference to `drivers'
mame.c:(.text+0xf40): undefined reference to `drivers'
mame.c:(.text+0xf60): undefined reference to `strcmp'
mame.c:(.text+0xfac): undefined reference to `strcmp'
mame.c:(.text+0xff0): undefined remake: *** Deleting file `EBOOT.PBP'
make: *** [EBOOT.PBP] Interrupt
ＵＮＺＩＰＬＩＢ．Ａでも、お魚さんの奴参考にしてリンクしよ。とおもったら。
何でこんな基本的なエラーが出るの！
Makefile全部書き直すか、あちこちインクルードして訳が判らない設定になってるに違いない。
例えば、LIB = XXXの後でLIB= をインクルードすると消えちゃうんだよ。そういう時は普通。LIB+=に
しとくんだけどさ普通。
とにかく矛盾が何処かにある筈。でなけりゃこんな基本的な所でコケン。
Makefile全部見直し。作り直し。
（ちなみにＧＣＣ４００の場合はpsp.makよりpsp2.makを参考にした方が近いみたいです）
（２００６－０２／１５、２１：２８）
■アメブロ、フォント選べるようにしてよぉ。あと、混みすぎ、どおせうちのページは関係ないんだから、
なんとか（トラックバックは、時間あたりの登録量が大量の場合は登録しにくくするとか）してくれえ。
# include the various .mak files
include src/core.mak「白」
# e.g. namcos1.mak
include src/$(TARGET).mak「白」
# cpu , sound valiables
include src/rules.mak「白」
# psp.mak
include src/$(MAMEOS)/$(MAMEOS2).mak「黒」
はい、白黒はっきりしましたね。「白」は「白」なんですから、絶対に弄る必要なんてない。
「黒」は訳わからんからメインのMakefileに本当に文字通りインクルード（合成）してしまいます。
あまりに不便なら後で分離します。
現状、両方で似たような事やってて、分離がうまくいってないから、分けてある事自体が意味不明。
となっとります。ＰＳＰ関係べったりの処理が両方に分散して入ってるだけという状態です。
他にもsrc/psp/floatonly.hはともかくsrc/psp/stdout.hとか臭そうなファイルがぁ。読んどかなきゃ。
（２１：４７）
■わからん。
さんざーーーーーん迷走して、結局元に戻した。これはつまり、単純に考えて、
ＯＢＪがとどかねえ
って事ではないのか？
エラーメッセージの意味を考えるから悪いのか？
少しＯＢＪをダイエットしてみるか。
うし、ダイエット実験。
まず、ＯＢＪディレクトリ。３．３４ＭＢあるな。そんなにでかいＥＢＢＯＴ．ＰＢＰにしたらこのオプションでは、
届かないのかな。
えーと、
￥ＣＰＵ ３３０ｋＢ いる。
￥ＤＥＢＵＧ １３５ＫＢ いらん。
￥ＤＲＩＶＥＲＳ １３５ＫＢ いる。
￥ＥＸＰＡＴ ２６１ＫＢ いらん。
￥ＭＡＣＨＩＮＥ １７１ＫＢ いる。
￥ＰＳＰ ４１４ＫＢ いる。
￥ＳＮＤＨＲＤＷ ０ＫＢ なし？
￥ＳＯＵＮＤ ９１ＫＢ いる。
￥ＶＩＤＨＲＤＷ ８２ＫＢ いる。
￥ＺＬＩＢ ９３ＫＢ いるな。
それから直下は１．６４ＭＢあって、でかい順に
ＤＲＡＷＧＦＸ．Ｏ ３４６ＫＢ いる、がダイエット可能。
ＬＩＢＥＸＰＡＴ．Ａ ２４６ＫＢ いらん。
ＣＨＥＡＴ．Ｏ １３５ＫＢ いらん。
ＩＮＰＴＰＯＲＴ １３３ＫＢ いる、がダイエット可能。
ＺＬＩＢ．Ａ ９６ＫＢ あれ？いるのかな？
ＭＡＭＯＲＹ．Ｏ ８６ＫＢ いる、がダイエット可能。
ＵＳＲＩＮＴＲＦ．Ｏ ７８ＫＢ いる、がダイエット可能。
その他が ５４４ＫＢこのうち、
ＡＲＴＷＯＲＫ．Ｏ ４５ＫＢ いらん。
ＩＮＦＯ．Ｏ ２５ＫＢ いらん。
ＣＨＤ．Ｏ ２８ＫＢ いらん。
とにかく本質的にほぼ要らないと思われる量を除くと大体その他が４０７ＫＢ。
さしあたり、要るもんまとめると２．２１ＭＢうーんまだ多いな。
■そもそもこの説が正しいかどうかさえ解からんし、でもＭａｋｅｆｉｌｅ見直したけど、
おかしな所は、見つからないんだよなあ。
もし、本質的に容量が問題ならば、システムⅠ専用エミュにせねばならない。
変な欲出してないで取り敢えず、本当に専用で作ってみるか。要らんもん外して。
じゃあバックアップね。と思ったけど、残り容量１５３ＭＢなんだよな。厳しい。
と思ったらＯＵＴファイルが出来てるぞ。
１９５７ＫＢだ。中身のぞいたら、殆ど０だったから、作成中のゴミだな。
■ＭＡＰ出力も明らかに途中で途切れてる。不審だ。オプションのコマンドライン引数が、
多すぎるのか？
opcode_base@@@@@@@@@0x4@@@@@@@@@@@@@@@obj/namcos1psp2/memory.o
VotraxChannel@@@@@@@0x4@@@@@@@@@@@@@@@obj/namcos1psp2/sound/votrax.o
spriteram_3_size@@@@0x4@@@@@@@@@@@@@@@obj/namcos1psp2/vidhrdw/generic.o
opcode_memory_max@@@0x4@@@@@@@@@@@@@@@obj/namcos1psp2/memory.o
lang@@@@@@@@@@@@@@@@0x30c@@@@@@@@@@@@@obj/namcos1psp2/ui_text.o
record@@@@@@@@
「スペース」は目に見えないので、＠に置換した。
いかにも途中で出力を中断されたＭＡＰファイル。
OUTの中身が０が多すぎるなのもありえない話だし、ＭＡＰファイルが途中で中断されるのもありえない話だ。
正常に出来ているのならば。
ＨＤＤの容量が足りなくて仮想メモリが取れないのが原因かもしれないと思うと、ますます訳が解からん。
そおいえば、前にｙｏｙｏｆｒのＣＰＵがインクルード多すぎてコンパイル出来なくて嵌まった件もあったしな。
■ＭＡＰファイルと中間ファイルの件は解かった。どんなにアホくさくても、エラーメッセージの途中で中断しては、
いけないんだ。このノートよりずーーーーと速いＰＣばかり長年使って来たから。全然判らなかった。
エラーメッセージがゆっくりで嬉しいんだけど、そおいうこともある訳か。さっきのマップファイルは１３ｋｂ
だったから。多分Ｗｉｎのいい加減な容量表示のせいで、本当は１２ｋｂ（４０９６ｘ３）だったんだろうな。
バイト単位で表示してくれないと、プログラミングの時には不便で仕方がない。未だにＷｉｎはなじめんなあ。
も一度、再現してみた。
■１３ｋｂってのは、１２ｋｂ＋＄４００バイトだった。（４ｋｂ＝＝＄１０００バイト）
＄３４００バイト＄４００はヘッダだろ。関係ないがＥＸＥのヘッダも＄４００だしな。＄４０００以上で
（＄４４００の時に）フラッシュバックして、＄３０００の分＋＄４００までファイルに吐いたんじゃろ。
それなら辻褄があう。
やっぱりＯＵＴは１９５７ＫＢだから、これが万一ＥＢＯＯＴ．ＰＢＰになった場合。２ＭＢ程度だな。
これは（このＭａｋｅｆｉｌｅのオプションでリンカがとどくためには）多いのか少ないのか。その辺がわからん。
-lcとかはつける気がおきないし。
■さらに、もう一度違う位置で中断してみた。遅いマシンでないと、こういうくだらない遊びはできん。
今度はＯＵＴが２６６９ＫＢ（＄２９ｂ１ｆ０）多分＄２９Ｃ０００境界の時のフラッシュバックでファイルに吐いたもの。
やはり、ＥＢＯＯＴ．ＰＢＰになった場合に２ＭＢ程度と思ったのは、甘い見込みだった。ＯＢＪが３．３４ＭＢあるんだから、
同程度＋ＵＮＺＩＰＬＩＢ．Ａだろ。足すとＥＢＯＯＴ．ＰＢＰが丁度３．５ＭＢ程度だ。
■これはリンカが、とどく／とどかないで、考えた場合。
やはり、届かないんだろうな。だから、strcmpとかmemsetとか言い出すんだろな。今回のＭａｋｅはお魚さんに
近いものだから、お魚さんで暗黙的に使ってリンクし、しかもＰＳＰで実際に動いているstrcmpで落ちる訳が
ない訳。（お魚さんの奴は標準のstrcmpと身内の_strcmpと何故か両方使っている。ソース見る限り、両方とも
正常に動作しない限り、ＲＯＭカートリッジが読める訳がない。ファイル名で使用してるんだから。つまり両方
正常動作している）それでも駄目なんだから、とどかない。と判断している。なんせどどかないんだから、
関数のある／なしは関係ないし。
■Ｃ言語上の問題は、コンパイル全部とおってるんだし、もう関数の名前が違うだのくだらない問題だけで。
何一つ無いのに。
リンカでこんなに苦しむとは。
■よくたかがＭａｋｅだろ、所詮バッチじゃん。とか言う人がいるが、バッチは手順どおりにやってくれるけど。
Ｍａｋｅは一見手順どおりにやってくれそうで、暗黙の了解というものがあり、一部手順どうりにやってくれない
んだぞ。例えばコンパイラドライバ一行も書いてないＭａｋｅでコンパイルできるのは、暗黙の了解のおかげ。
バッチだと思って考えたら、そこで止まらなきゃ筋がとうらんじゃないか。
という訳で、たかがリンカ。というわけではない。
■この先どっちに進もうか。
「このままコンパイル工夫してなんとかＥＢＯＯＴ．ＰＢＰファイル生成する方向で苦しむ」か、
「素直にソース弄ってダイエットして専用ソースにしちまう」か。
管理人としては、もう後者で良いような気がしてきたぞ。つまりリンカから尻尾巻いて逃げるってこった。
ＰＣの上にも３日ぐらいは、苦しんだ気がするしなぁ。
どおしよ。
（２００６－０２／１６、０７：３０）
