Originally posted by 2Tie
Yes dan, those would be just text strings in INCLUDE.bin.
Edit: Looking over these strings... These files mention Timber, which seeing as he isn't mentioned in the .bin's in retail SFA, makes me think the include.bin is either a pretty old one, or that those BITs were never updated...
Also, the stuff in the pastebin helps verify and fill in gaps on the stuff Rareminion has shown.
Yeah, it seems that INCLUDE.bin is actually older than DLLS.bin by maybe more than a year. The number of bytes the "out" log says for INCLUDE.bin is the same as the number of bytes the file has now. But the DLLS.bin file mentioned in the log is significantly smaller than the file that's included here. So that means that the "out" log file was generated a long time a go before this build was put together. Although some things have changed, some things haven't like TEX.BIN. I'm curious when exactly development stopped for the N64 version before it shifted to the Gamecube. I think it was present for E3 2000 wasn't it? And Starfox Adventures was there for the first time at Spaceworld the following year?
Originally posted by Rena
I'd expect it to be Gamecube code, but it could be compressed or obfuscated in some way. It could also possibly be script bytecode. Maybe post some samples?
Samples of what IDA Pro's giving me? You can check out a subroutine it thinks it managed to disassembled here. Again though, it's probably incorrect because this is assuming the base address is 00000000, which is probably unlikely.
In fact, most of the code generated seems to be incorrect. Like for example, this is what it thinks the beginning of the file is doing:
ROM:0000006C loc_6C: # DATA XREF: ROM:0006A12Co
ROM:0000006C # ROM:0006ADA8o ...
ROM:0000006C dsll $t6, $zero, 8
ROM:00000070 loc_70: # DATA XREF: ROM:001554B0o
ROM:00000070 # ROM:001C455Co ...
ROM:00000070 sll $t6, $zero, 14
ROM:00000074 loc_74: # DATA XREF: ROM:0001B1F0o
ROM:00000074 # ROM:000A7C44o ...
ROM:00000074 and $t6, $zero, $zero
ROM:00000078 loc_78: # DATA XREF: ROM:00038DB0o
ROM:00000078 # ROM:000970E4o ...
ROM:00000078 move $t6, $zero
ROM:0000007C loc_7C: # DATA XREF: ROM:00052E40o
ROM:0000007C # ROM:000A9694o ...
ROM:0000007C mfhi $t6
ROM:00000080 loc_80: # DATA XREF: ROM:00015450o
ROM:00000080 # ROM:000174D8o ...
ROM:00000084 loc_84: # DATA XREF: ROM:off_0o
ROM:00000084 # ROM:0005A544o ...
ROM:00000084 lui $gp, 0
ROM:00000088 ori $gp, 0 # DATA XREF: ROM:00038DCCo
ROM:00000088 # ROM:0003FEDCo ...
I don't know any MIPS assembly, so someone else will have to look at DLLS.bin. I doubt the code is obfuscated though.
Anyway, DLLSIMPORTTAB.bin seems to have a list of addresses. But I'm not sure if they're for DLLS.bin. They would've been generated at the same time DLLS.bin was so they should go together. The debug executable loads up DLLSIMPO.bin but it's zero'd out (and just a bit smaller than DLLSIMPORTTAB.bin). I still have no idea what the .tab files are supposed to be.
Forgot to mention this before, but the game has a stray .bat file for removing .changed files and copying over .BIN files. Probably a leftover from something old:
cp ANIMCURVES.bin ANIMCURV.bin
cp ANIMCURVES.tab ANIMCURV.tab
cp CAMACTIONS.bin CAMACTIO.bin
cp DLLSIMPORTTAB.bin DLLSIMPO.bin
cp ENVFXACTIONS.bin ENVFXACT.bin
cp MUSICACTIONS.bin MUSICACT.bin
cp OBJEVENTS.bin OBJEVENT.bin
cp OBJSEQ2CURVE.tab OBJSEQ2C.tab
cp SAVEGAMES.bin SAVEGAME.bin
cp SAVEGAMES.tab SAVEGAME.tab
cp WEAPONDATA.bin WEAPONDA.bin
STORYBOARD.bin intrigues me. DLLS.bin has a string that tells the debugger to refer to this after a string that refers to angles and camera control. This was probably used for cutscenes. "out" log refers to this file as one of the ones from 1999 and haven't been changed since then by comparing the bytes of the file that's included and the file listed in the log. But the file seems to be compressed with something perhaps, since I can't get any strings from it.
Also, I'm gonna see if I can get some of the maps loaded that seem interesting like "linklevel" and that copy of swaphol. gcr should help since I can rebuild gcm files that way.