ROM Hack .pac files help

Leeg · Jul 16, 2011

Well... regarding control codes I found:

10000C006E + "random number" displays an animation of a 3d model in the top screen

0D0014 This is always placed before a character name (that is displayed in the top of the text box)

02000C00 This controls BK images (book-style images displayed in the top screen, the ones we edited in ntf format)

0A And this is a jump line.

I know it's not a lot, ... but that was what I found.

Leeg · Jul 20, 2011

http://crackerscrap.com/docs/dsromstructure.html

According to that...

QUOTE said:
0x70-0x73 4 bytes ARM9 pointer table

And our file says...

AC 0A 00 02

So ARM9 pointer table starts there, or maybe

02 00 0A AC

But I've tried both and none of them gives result... so I thought that maybe I'm not dealing with that hex the right way.

I think that if I manage to understand that I'll get the location of other pointer tables.

Any idea?

rastsan · Jul 20, 2011

try looking at that address in memory. I had to do that with zoids battle colosuem all the pointers are memory pointers (but then all the stuff pointed to is in the overlay bins).

which I think fast6191 can explain better than I can as they explained it to me.

FAST6191 · Jul 20, 2011

The ARM pointers are less to do with the text and more likely something to do with the game proper. I am not ruling out there being pointers or some related concept in some of the binaries at this point (I have not even looked) but if it is as complex as it is looking to be it might even be there are not any pointers in the story text section even to the point where it is a true text parser/scripting engine (homebrew aside I can not think of another example on the DS). Nice catch though on the bk stuff being related to file names and the control codes you have already managed to figure out.

General idea for pointers (ARM9 and otherwise) though. For this I am probably going to have to refer to the GBA and going into some ideas in programming but I will try to keep it a bit light on the DS hardware front though.

The GBA had cartridges you could see in the ram- 08000000 to 09FFFFFF (and a few upper regions that had the same data but different wait states) and to this end if a game needed something from the cart it could call for it directly by various methods (this nicety gave rise to tracing- http://www.romhacking.net/docs/361/ ) but the DS does not have a cart in memory so it copies thing to ram by various methods (you can try to hook into them and watch dma transfers and cart reads but it is not quite as nice/developed as GBA stuff).

With most things being all in memory the data can then be (or indeed is) pointed at once it is in memory (this is especially common with files always intended to be in memory like the binaries and overlays) especially if it is able to be predicted/calculated to be in a given location in memory.

This prediction is hard though not to mention if you can edit a file (or have it build a new one) that is one thing but having to edit code (and probably recompile) it is considerably more troublesome even if you are only in a one man team (multiple people and especially if they are not all programmers) hence us getting simpler pointers that work on file level rather than memory locations for just about everything on the DS). It also ties into "pointer arithmetic" which is where pointers are fiddled with to get to required section (in that fixed length part you might know where it starts- get the start location, if you want the 97th entry take the length value, multiply it by 97 in this case and then add the result to the start location to get you the location you need or if you prefer think back to the pac files where we added up the length values to get the locations in the files).
Most pointers are some variation on this (languages like C have a good chunk of the language built around pointers which causes endless debate about how to teach such languages and what needs to be taught on the flip side nearly all high level languages seek to do away with actual memory locations for various reasons some of which were already mentioned) but we do not tend to consider this step as it is usually easier to figure out the simple pointers and fix them when we break them- kind of like how you do not recode the game to read JPEG images and play avi files but figure out the formats and work with them instead). Memory pointers are a kind of special case for this in that they need no calculations (at first anyway) as they point where the things are in as far as the game is concerned.
http://nocash.emubase.de/gbatek.htm#dsmemorymaps has a map of the DS memory so yeah that value could well be pointing at the "Main Memory" although if it can trigger files and such as well all bets are off until more info appears (that is a really low value in the ram so chances are it is directly in the binary, I will have to check the rom (NDSTS and most other tools of that nature will tell you easily enough not to mention that link to cracker's site).

The other reason we usually have premade pointers is that about the only way to figure out when something has finished is to read a section, check it and then carry on reading or indeed stop when it is finished which is hugely time/resource consuming which you really do not want to do on a handheld (consoles it is not so bad)- there are variations like checking from the end/maximum values or actually parsing the text like the game in this case (sometimes pointers are used for it though) does not know where every new line command is found but probably only starts a new line when it detects the 0a character).

Back on topic it looks like you get to figure out the scripting engine- you can come at it from an assembly coder's perspective but that will require you to know a bit about assembly (although it might not be that bad) so I would instead consider testing and corruption. Expand sections to see what happens- does stuff get cut off, does it work fine or does the game crash even?

Edit- for the sake of it http://gbatemp.net/index.php?showtopic=185...p;#entry2326367 could be worth a quick read or not.

Leeg · Jul 21, 2011

Thanks again, I really appreciate your help since the rom is already in english and you could just skip my messages ,

I found that if you add 0A (jump-line) for instance here:

ORIGINAL:

TEXTBOX1--------------
Every story needs /0a
a charming character.
--------------------------

EDITED:

TEXTBOX1--------------
Every story needs /0a
/0a
/0a
--------------------------

TEXTBOX2--------------
a charming character.
-------------------------

Next textbox (TEXTBOX3) follows as should be, no changes. So textboxes are autogenerated depending on needed, so I think that only the first one per character is pointed.

Also, another thing that confirms my theory is that there is a HEX repeated before every first textbox:

03 00 XX 00 00 00 00 00 (only XX changes, and it is repeated so no idea how it works)

Which I think acts as pointer or it is pointed itself, I don't know...

PS:
G014 (hex: 00 08 00 10 00 47 30 31 34) calls Naming character window.
bXXX is background image, for instance: 62 30 33 32 is b032
6DXXXXXX displays a 3dmodel (which is controled with the 10000C006E hex I posted previously), for instance: 6d 30 38 34 (m084) is the Witch 3D model.

FAST6191 · Jul 22, 2011

Well this seems to be a half decent scripting engine. As for coming back I mainly frequent this section in the hopes of finding something interesting to pull apart, if others wish to do something useful with that then great.

To this end some reverse engineering of the format/attempting to pull together the data we have on it so far and maybe work it up a bit more. I know most of this is a repeat of conversations we have already had but if this carries on much longer it is going to get annoying to try to piece together everything. I am considering all the formats done for now so this is just event.dat

It will be covered later but it seems several parts of the file call other files by name rather than by some other method which is nice I guess and probably to be expected at some level (I would have generated a list of sorts similar to SDAT myself but that is a different matter for a different day)
Knowing this a list of all the files in data directory (ndstool/dslazy/dsbuff users this is another game that has all the files in a directory called data so it will be data\data\[somefile] if you pull it apart)..

This is just a straight name list, the game appears to arrange the files unix style (where case matters) where bZ would come before B0.
<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space

re;overflow:auto'>ArrangePanelBG.pac
ArrangePanelOBJ.pac
b001.pac
b004.pac
b005.pac
b006.pac
b007.pac
b008.pac
b009.pac
b012.pac
b013.pac
b014.pac
b015.pac
b018.pac
b021.pac
b022.pac
b023.pac
b024.pac
b027.pac
b030.pac
b031.pac
b032.pac
b033.pac
b035.pac
b036.pac
b050.pac
b051.pac
bkA01.ntf
bkA02.ntf
bkA03.ntf
bkB01.ntf
bkB02.ntf
bkBLK.ntf
bkC01.ntf
bkD01.ntf
bkD02.ntf
bkDmy.ntf
bkE01.ntf
bkF01.ntf
bkF02.ntf
bkF03.ntf
bkG01.ntf
bkH01.ntf
bkH02.ntf
bkI01.ntf
bkJ01.ntf
bkJ02.ntf
bkJ03.ntf
bkJ04.ntf
bkJ05.ntf
bkJ06.ntf
bkJ07.ntf
bkJ08.ntf
bkK01.ntf
bkK02.ntf
bkK03.ntf
bkL01.ntf
bkL02.ntf
bkM01.ntf
bkM02.ntf
bkN01.ntf
bkN02.ntf
bkO01.ntf
bkO02.ntf
bkO03.ntf
bkP01.ntf
bkQ01.ntf
bkQ02.ntf
bkQ03.ntf
bkQ04.ntf
bkR01.ntf
bkS01.ntf
bkT01.ntf
bkU01.ntf
bkU02.ntf
bkU03.ntf
bkU04.ntf
bkU05.ntf
Book.nsbmd
Book.pac
book01.nsbmd
book01.pac
book02.nsbmd
book02.pac
BookLowerOBJ.pac
BtlFld.isd
ButtleAllyTargetOBJ.pac
ButtleLowerBG1-0.pac
ButtleLowerBG1.pac
ButtleLowerBG1Black.pac
ButtleLowerBG2-0.pac
ButtleLowerBG2-1.pac
ButtleLowerBG3-0.pac
ButtleLowerBG3.pac
ButtleLowerBG5-0.pac
ButtleLowerBG8-0.pac
ButtleLowerBG8-1.pac
ButtleLowerBG9-0.pac
ButtleLowerOBJ2.pac
ButtleLowerOBJ3.pac
ButtleLowerOBJ4.pac
ButtleResultBG.pac
ButtleResultOBJ.pac
ButtleUpperBG1.pac
ButtleUpperBG2.pac
ButtleUpperBG3.pac
ButtleUpperBG4.pac
ButtleUpperOBJ2.pac
ChatUpperObj.pac
croud.nsbmd
croud.pac
d00.pac
d01.pac
d01e.pac
d02.pac
d03.pac
d03e.pac
d04.pac
d04e.pac
d05.pac
d05e.pac
d06.pac
d06e.pac
d07.pac
d07e.pac
d08.pac
d3p.pac
default_data.dat
Element.pac
endcut.nsbmd
endcut.pac
EndCutMainOBJ.pac
endroll.dat
event.dat
F001.pac
F002.pac
F003.pac
F004.pac
F005.pac
F006.pac
F007.pac
F008.pac
F009.pac
F010.pac
F011.pac
F012.pac
F013.pac
F014.pac
F015.pac
F016.pac
F017.pac
F018.pac
F019.pac
F020.pac
F021.pac
F022.pac
F023.pac
F024.pac
F025.pac
F026.pac
F027.pac
F028.pac
F029.pac
F030.pac
F031.pac
F032.pac
F033.pac
F034.pac
F035.pac
F036.pac
F037.pac
F038.pac
F039.pac
F040.pac
F041.pac
F042.pac
F043.pac
F044.pac
F045.pac
F046.pac
F047.pac
F048.pac
F049.pac
F051.pac
F080.pac
F081.pac
F082.pac
F083.pac
F090.pac
F091.pac
F092.pac
F093.pac
F094.pac
F095.pac
F096.pac
F097.pac
F098.pac
F099.pac
F100.pac
F101.pac
F102.pac
fieldObj.pac
fin00.pac
fin01.pac
gameoverLow.pac
gameoverUp.pac
global_data.dat
heal.nsbmd
heal.pac
i01.pac
i02.pac
i03.pac
i04.pac
i05.pac
i06.pac
i07.pac
i08.pac
i09.pac
i10.pac
i11.pac
i12.pac
i13.pac
j001.nsbmd
j001_01.nsbca
j001_02.nsbca
j001_03.nsbca
j001_04.nsbca
j002.nsbmd
j002_02.nsbca
j002_03.nsbca
j002_04.nsbca
j002_05.nsbca
j003.nsbmd
j003_02.nsbca
j003_03.nsbca
j003_04.nsbca
j004.nsbmd
j004B.nsbmd
j004_02.nsbca
j004_03.nsbca
j004_04.nsbca
j005.nsbmd
j005_01.nsbca
j005_02.nsbca
j005_03.nsbca
ka00.pac
ka01.pac
ka02.pac
ka03.pac
ka04.pac
ka05.pac
ka06.pac
ka07.pac
ka08.pac
ka09.pac
ka10.pac
ka11.pac
ki00.pac
ki01.pac
ki02.pac
ki03.pac
ki04.pac
ki05.pac
ki06.pac
ki07.pac
ki08.pac
kira.ntf
kirablue.ntf
kiragreen.ntf
kirared.ntf
kirayellow.ntf
l00.pac
l01.pac
l02.pac
l02e.pac
l03.pac
l03e.pac
l04.pac
l05.pac
l06.pac
l06e.pac
l07.pac
l07e.pac
l08.pac
l08e.pac
l09.pac
Lc10.NFTR
Lc12.NFTR
Lc12N.NFTR
Lc8.NFTR
LcDbg.NFTR
legalLower.pac
legalUpper.pac
m001.pac
m002.pac
m003.pac
m004.pac
m005.pac
m006.pac
m007.pac
m008.pac
m009.pac
m010.pac
m011.pac
m012.pac
m013.pac
m014.pac
m015.pac
m016.pac
m017.pac
m018.pac
m019.pac
m020.pac
m021.pac
m022.pac
m023.pac
m024.pac
m025.pac
m026.pac
m027.pac
m028.pac
m029.pac
m030.pac
m031.pac
m032.pac
m033.pac
m034.pac
m035.pac
m036.pac
m037.pac
m038.pac
m039.pac
m040.pac
m041.pac
m042.pac
m043.pac
m044.pac
m045.pac
m046.pac
m047.pac
m048.pac
m049.pac
m050.pac
m051.pac
m052.pac
m053.pac
m054.pac
m055.pac
m056.pac
m057.pac
m058.pac
m059.pac
m060.pac
m061.pac
m062.pac
m065.pac
m066.pac
m067.pac
m068.pac
m069.pac
m070.pac
m071.pac
m072.pac
m073.pac
m074.pac
m075.pac
m076.pac
m077.pac
m078.pac
m079.pac
m080.pac
m081.pac
m082.pac
m083.pac
m084.pac
m085.pac
m086.pac
m088.pac
m089.pac
m094.pac
m095.pac
m096.pac
m097.pac
m100.pac
m101.pac
m102.pac
m103.pac
m104.pac
m105.pac
m106.pac
m107.pac
m108.pac
m109.pac
m110.pac
m111.pac
m112.pac
m113.pac
m114.pac
m115.pac
m116.pac
m117.pac
MainMenuEquip.pac
mapObj.pac
map_ozCastle.nsbmd
map_ozCastle.pac
MenuLowerBG.pac
MenuLowerBG2.pac
MenuLowerOBJ.pac
MenuLowerOBJ2.pac
MenuLowerStatusBG1.pac
MenuLowerStatusBG2.pac
MenuLowerStatusBG3.pac
MenuLowerStatusOBJ.pac
MenuNewEquipment.pac
MenuUpperBG.pac
MenuUpperBG1.pac
MenuUpperBG2.pac
MenuUpperOBJ.pac
moya.nsbmd
moya.pac
moyan.ntf
mve.pac
n001.pac
n002.pac
n003.pac
n004.pac
n005.pac
n006.pac
n007.pac
n008.pac
n009.pac
n010.pac
n011.pac
n012.pac
n013.pac
n014.pac
n015.pac
n016.pac
n017.pac
n018.pac
n019.pac
n020.pac
n021.pac
n022.pac
n023.pac
n024.pac
n025.pac
n026.pac
n027.pac
n028.pac
n029.pac
n030.pac
n031.pac
n032.pac
n033.pac
n034.pac
n035.pac
n036.pac
n037.pac
n038.pac
n039.pac
n040.pac
n041.pac
n042.pac
n043.pac
n044.pac
n045.pac
n046.pac
n047.pac
n048.pac
n049.pac
n050.pac
n051.pac
n052.pac
n053.pac
n054.pac
n055.pac
n056.pac
n057.pac
n058.pac
n059.pac
n060.pac
n061.pac
n062.pac
n065.pac
n066.pac
n067.pac
n068.pac
n069.pac
n070.pac
n071.pac
n072.pac
n073.pac
n074.pac
n075.pac
n076.pac
n077.pac
n078.pac
n079.pac
n080.pac
n081.pac
n082.pac
n083.pac
n084.pac
n085.pac
n086.pac
n087.pac
n090.pac
n091.pac
n092.pac
n093.pac
n094.pac
n095.pac
n096.pac
n097.pac
n100.pac
n101.pac
n102.pac
n106.pac
n107.pac
n108.pac
n113.pac
n114.pac
n115.pac
n116.pac
n117.pac
n118.pac
n119.pac
n120.pac
n121.pac
ninten.pac
o001.pac
o002.pac
o003.pac
o004.pac
o005.pac
o006.pac
o007.pac
o008.pac
o009.pac
o010.pac
o011.pac
o013.pac
o015.pac
o016.pac
o018.pac
o020.pac
o021.pac
o023.pac
o024.pac
o027.pac
o028.pac
o029.pac
o030.pac
o031.pac
o032.pac
o033.pac
o034.pac
o035.pac
o036.pac
o037.pac
o038.pac
o039.pac
o040.pac
op.dat
opCam01.nsbmd
opCam01.pac
opCam02.nsbmd
opCam02.pac
opCam03.nsbmd
opCam03.pac
opCam04.nsbmd
opCam04.pac
opCamera.nsbmd
opCamera.pac
opDoro.pac
ops01.pac
ops02.pac
ops03.pac
ops04.pac
ops05.pac
ops06.pac
ops07.pac
ops08.pac
ops09.pac
ops10.pac
ops11.pac
ops12.pac
ops13.pac
OP_EFE.nsbmd
OP_EFE.pac
OZCastle.nsbmd
OZCastleOBJ.pac
OZShopOBJ.pac
pa01.pac
pa02.pac
pa03.pac
pa04.pac
pa05.pac
pa06.pac
pigeon.nsbmd
pigeon.pac
popup.nsbmd
popup.pac
r02.nsbmd
room.nsbmd
shadow.nsbmd
shadow2.nsbmd
SkyL.pac
SkyR.pac
sound_data.sdat
spot.nsbmd
spot.pac
Title.pac
TitleBack.nsbmd
TitleLogo.nsbmd
titleLowerBG.pac
trackBallBG1.pac
trackBallBG2.pac
trackBallObj1.pac
ui_Black.pac
ui_buy_up01.pac
ui_ehon01.pac
ui_gameover.pac
ui_gameoverW.pac
ui_kaiwa01.pac
ui_kaiwa02.pac
ui_kbdBG.pac
ui_koro02.pac
ui_koro03.pac
ui_koro03_1.pac
ui_koro04_1.pac
ui_koro04_2.pac
ui_m05_3.pac
ui_m05_4.pac
ui_mst_01.pac
ui_mst_02.pac
ui_mst_03.pac
ui_mst_04.pac
ui_ne00_01.pac
ui_ne00_02.pac
ui_ne00_03.pac
ui_ne00_04.pac
ui_ne00_05.pac
ui_op01_logo.pac
ui_op02.pac
ui_op02_1.pac
ui_ozBG.pac
ui_ozbuy_01.pac
ui_ozbuy_02.pac
ui_ozbuy_04.pac
ui_ozbuy_OBJ.pac
ui_ozMenuBG.pac
ui_SL01l.pac
ui_SL01lW.pac
ui_SL01s.pac
ui_SL01sW.pac
ui_SL02.pac
ui_SL02OBJ.pac
ui_stageclear_1.pac
ui_stageclear_2.pac
ui_suspend.pac
ui_title.pac
ui_Tutorial01.pac
ui_Tutorial02.pac
ui_Tutorial03.pac
ui_wp.pac
ui_YN01.pac
ui_YN02.pac
WBLogo.pac
xseed.pac
</div>

The text seems to be a mixture of ASCII and shiftJIS but the odd thing is the shiftJIS can be seen immediately following ASCII without so much as a break to a 16bit boundary (this will tend to break most shiftJIS parsers- certainly the simple ones like we have in crystaltile2 co). Moreover I imagine this to be quite costly in resources which on top of a scripting engine is not good but this is not a code review at this point so enough of that for the moment.
Example can be found right at the start of the text section. (020c hex)

0D00 1400 5769 7463 6881 6981 4881 6A00 0000 0000
Ascii output ....Witch.i.H.j.....
Proper output
....Witch（？）
(for those without good text parsing in their browser that is the shiftJIS version of a bracketed question mark- "(?)" although without quotes).

<b>Markup.</b>
0d00 1400 is character naming box.
0A even when buried in text triggers a new line.
You say bXXX calls a background image which makes sense and seems to line with file names.

1000 0C00 6E?? you say calls a NSMBD (others reading remember NSBMD is the 3d model format from the DS SDK). The values ?? takes are rather limited though.
194 instances
Values I see (hex naturally)
31
32
33
34
35
36
37
38
39
61
62
63
64
66
(I think I got them all but I am not 100%). That would be 14 possibilities.
Fairly even spread through the text for most of them, some were more common than others, I probably should have done a frequency analysis or something along those lines trying to match it but I will leave that for now.
There are some 30 nsbmd files in the rom (along with a few animations) assuming nothing in the pac files. A bunch of those NSBMD files are named j00? which you do see at the start of the event.dat before the text.
Some (going by names alone) appear to be for other parts of the game but when all the
book0
j00
and
opCam
are added up you get 13 possibilities but that is pure speculation right now.

0200 0C00 calls bk files, seemingly by name although it is ASCII by this point. 02000C00626B53303100 for example (it would be bkS01)

I see some 0400 1000 frequently before j00 but occasionally other ASCII as well. "j0??????" (sometimes it has a trailing en and others it has skl- enemy and skill perhaps?), "F0?????", "Wmap??", "newcstl" (no file named for this though- the obvious expansion being newcastle of which there are a couple of NSMBD files with castle in the name), "spirit" a few times, "shop" another time or two and "opfingt" once.

I also see a handful of 0500 1000 followed by dra?? (?? being 01, 02 or 03) or skills in ASCII.

0300 ???? also features as you say (in fact it seems to be 8 bytes long but I doubt it ever has need of that much text). This is about as close to pointers as I have seen although might be a kind of "no parsing the following amount of bytes" as they are not necessarily to the next 0300 ???? section (or something else notable) but creating a new file the ???? section seems to correspond to the end of the text at least (0000 if no text which could indicate a higher order/parsing method- load file, load name box, figure text length, load text, parse any additional data and load according imagery sort of thing) with the data not covered by the length section following usually (I have not checked them all) being one of the other call values. However some of the files have a 00?? after them still within the length value specified by the 0300 section. Unlike the text decode the these do seem to be using 16 bit boundaries.

<img src="http://pix.gbatemp.net/32303/10wizardozndsdemohack22jul2011.jpg" border="0" class="linked-image" />

Another example
<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space

re;overflow:auto'>00000000 0300 <span style="color:#FF0000">9C00</span> 0000 0000 5769 7468 2074 6869 ........With thi
00000010 732C 2049 2065 6E64 206D 7920 6175 6469 s, I end my audi
00000020 656E 6365 2121 0A0A 4672 6F6D 2074 6869 ence!!..From thi
00000030 7320 6461 7920 666F 7274 682C 2049 2066 s day forth, I f
00000040 6F72 6269 6420 616E 796F 6E65 0A74 6F20 orbid anyone.to
00000050 656E 7465 7220 6D79 2063 6173 746C 6520 enter my castle
00000060 7769 7468 6F75 7420 7065 726D 6973 7369 without permissi
00000070 6F6E 210A 456E 7465 7220 616E 6420 796F on!.Enter and yo
00000080 7520 7368 616C 6C20 6469 6521 210A 0A4E u shall die!!..N
00000090 6F77 206C 6561 7665 2121 21<span style="color:#FF0000">00 04</span>00 1000 ow leave!!!<span style="color:#FF0000">..</span>...
000000A0 676F 6373 746C gocstl
</div>

00 0400 1000 gocstl already being mentioned earlier.

This leaves the likes of the MSN and if there are any proper pointers in the file.

I also got bored and took a look at the binary (it is uncompressed- at least as a whole file)- a lot of interesting files and names in there (you can seem some images in it too- they look to be SDK formats for the keyboard backing images).
Quite a good hit to miss ratio as well for such a search (the following code box is the result of a very minor cleanup)- some stuff is to be expected but I usually only see the odd wifi related message.
Lc10 is one of the main fonts. I did not have much luck pulling what appeared to be a font out of the binary but I did not try anything beyond a basic copy and paste.

<div class='codetop'>CODE</div><div class='codemain'>0x00000BBFÂÂÂÂ0x00000016ÂÂÂÂ![SDK+NINTENDO:BACKUP]
0x0007CF24ÂÂÂÂ0x00000006ÂÂÂÂHPXERF
0x0007D3FCÂÂÂÂ0x00000007ÂÂÂÂ[email protected]
0x0007D84CÂÂÂÂ0x00000004ÂÂÂÂKNBA
0x0007D9FCÂÂÂÂ0x00000004ÂÂÂÂRAHC
0x0007DA30ÂÂÂÂ0x00000004ÂÂÂÂSOPC
0x0007DA7CÂÂÂÂ0x00000007ÂÂÂÂ[email protected]
0x0007DAB8ÂÂÂÂ0x00000004ÂÂÂÂPMCP
0x0007DC24ÂÂÂÂ0x00000004ÂÂÂÂRTFN
0x0007DC2CÂÂÂÂ0x00000007ÂÂÂÂ[email protected]
0x0007DCFCÂÂÂÂ0x00000010ÂÂÂÂFNIFHDWCPAMCPLGC
0x0007DD74ÂÂÂÂ0x00000004ÂÂÂÂKBEC
0x0007DE6CÂÂÂÂ0x00000004ÂÂÂÂNRCS
0x0008D220ÂÂÂÂ0x00000004ÂÂÂÂBTX0
0x00090448ÂÂÂÂ0x0000000EÂÂÂÂBVA0BTP0BMD0XÂÂÂÂ
0x00090598ÂÂÂÂ0x0000000EÂÂÂÂBVA0BTP0BMD0dÂÂÂÂ
0x00093825ÂÂÂÂ0x00000079ÂÂÂÂÂÂ !!"""##$$$%%&&'''(())**++,,--..//0112233455667889::;<<=>[email protected][]^_`abcdeghijkmnoqrsuvwyz{}~
0x0009389FÂÂÂÂ0x000000F0ÂÂÂÂ !!!""###$$%%&&&''(())**++,,--..//00112334456677899:;;<=>>[email protected]@ABCCDEFGGHIJKLMMNOPQRSTUVWXYZ[\]^_`bcdefgijklmopqstuwxy{|[email protected]
0x00093A00ÂÂÂÂ0x0000005FÂÂÂÂ !"#$%&'()*+,-./0123456789:;<=>[email protected][\]^_`ABCDEFGHIJKLMNOPQRSTUVWXYZ{|}~
0x00093B68ÂÂÂÂ0x00000004ÂÂÂÂNAN(
0x00093B6DÂÂÂÂ0x00000008ÂÂÂÂINFINITY
0x00093F40ÂÂÂÂ0x00000009ÂÂÂÂo004_root
0x00094348ÂÂÂÂ0x00000005ÂÂÂÂLc12N
0x000947C3ÂÂÂÂ0x00000009ÂÂÂÂADH~OqW/`
0x000947D4ÂÂÂÂ0x00000006ÂÂÂÂcamera
0x000947E8ÂÂÂÂ0x00000006ÂÂÂÂtarget
0x00098AFCÂÂÂÂ0x00000014ÂÂÂÂdata/sound_data.sdat
0x00098B14ÂÂÂÂ0x00000014ÂÂÂÂdata/global_data.dat
0x0009A505ÂÂÂÂ0x00000004ÂÂÂÂSFOT
0x0009A522ÂÂÂÂ0x00000004ÂÂÂÂ9NXS
0x0009AD37ÂÂÂÂ0x00000005ÂÂÂÂTe\Ng
0x0009E5C4ÂÂÂÂ0x000000BEÂÂÂÂ !"#$%&'()*+,-./0123456789:;<=>[email protected][\]^_`abcdefghijklmnopqrstuvwxyz{|}~
0x000AB54CÂÂÂÂ0x00000005ÂÂÂÂAM|PM
0x000AB58CÂÂÂÂ0x00000008ÂÂÂÂ%m/%d/%y
0x000AB5A4ÂÂÂÂ0x0000000BÂÂÂÂ%I:%M:%S %p
0x000AB5B0ÂÂÂÂ0x0000000EÂÂÂÂ%a %b %e %T %Y
0x000AB5C0ÂÂÂÂ0x00000054ÂÂÂÂSun|Sunday|Mon|Monday|Tue|Tuesday|Wed|Wednesday|Thu|Thursday|Fri|Friday|Sat
|Saturday
0x000AB618ÂÂÂÂ0x00000085ÂÂÂÂJan|January|Feb|February|Mar|March|Apr|April|May|May|Jun|June|Jul|July|Aug|
August|Sep|September|Oct|October|Nov|November|Dec|Dec
0x000AB6C0ÂÂÂÂ0x00000014ÂÂÂÂ!"#$%&'()*
0x000AB6E2ÂÂÂÂ0x00000034ÂÂÂÂ+-/13579;=?ACEGIKMOQSUWY[]
0x000AB722ÂÂÂÂ0x00000034ÂÂÂÂ,.02468:<>@BDFHJLNPRTVXZ\^
0x000AB760ÂÂÂÂ0x00000005ÂÂÂÂ0x0p0
0x000AB768ÂÂÂÂ0x00000004ÂÂÂÂ-INF
0x000AB770ÂÂÂÂ0x00000004ÂÂÂÂ-inf
0x000AB780ÂÂÂÂ0x00000004ÂÂÂÂ-NAN
0x000AB788ÂÂÂÂ0x00000004ÂÂÂÂ-nan
0x000AB9E0ÂÂÂÂ0x00000004ÂÂÂÂ.pac
0x000ABA48ÂÂÂÂ0x00000005ÂÂÂÂ.NSCR
0x000ABA50ÂÂÂÂ0x00000005ÂÂÂÂ.NCLR
0x000ABA58ÂÂÂÂ0x00000005ÂÂÂÂ.NCGR
0x000ABA60ÂÂÂÂ0x00000005ÂÂÂÂ.NFTR
0x000ABA68ÂÂÂÂ0x00000005ÂÂÂÂ.NCER
0x000ABA70ÂÂÂÂ0x00000005ÂÂÂÂ.NANR
0x000ABA7CÂÂÂÂ0x00000004ÂÂÂÂ.isd
0x000ABC5CÂÂÂÂ0x00000008ÂÂÂÂF036D000
0x000ABCF4ÂÂÂÂ0x00000004ÂÂÂÂdata
0x000ABCFCÂÂÂÂ0x00000008ÂÂÂÂfieldObj
0x000ABD08ÂÂÂÂ0x00000007ÂÂÂÂsignpnl
0x000ABD10ÂÂÂÂ0x00000007ÂÂÂÂsprtpnl
0x000ABD18ÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ABD20ÂÂÂÂ0x00000007ÂÂÂÂynpanel
0x000ABD28ÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ABD30ÂÂÂÂ0x00000009ÂÂÂÂui_koro02
0x000ABD3CÂÂÂÂ0x00000007ÂÂÂÂopfingt
0x000ABD44ÂÂÂÂ0x00000007ÂÂÂÂopfingt
0x000ABE60ÂÂÂÂ0x00000004ÂÂÂÂbody
0x000ABE68ÂÂÂÂ0x00000006ÂÂÂÂcamera
0x000ABE70ÂÂÂÂ0x00000004ÂÂÂÂnear
0x000ABE7CÂÂÂÂ0x00000010ÂÂÂÂperspective_fovy
0x000ABE90ÂÂÂÂ0x00000012ÂÂÂÂperspective_aspect
0x000ABEA4ÂÂÂÂ0x00000007ÂÂÂÂscale_w
0x000ABEB0ÂÂÂÂ0x00000005ÂÂÂÂcolor
0x000ABEB8ÂÂÂÂ0x00000005ÂÂÂÂalpha
0x000ABEC0ÂÂÂÂ0x00000006ÂÂÂÂoffset
0x000ABEC8ÂÂÂÂ0x00000005ÂÂÂÂshift
0x000ABED0ÂÂÂÂ0x00000004ÂÂÂÂmode
0x000ABED8ÂÂÂÂ0x00000005ÂÂÂÂcolor
0x000ABEE0ÂÂÂÂ0x00000009ÂÂÂÂfog_table
0x000ABEECÂÂÂÂ0x00000004ÂÂÂÂ.ntf
0x000ABEF4ÂÂÂÂ0x00000006ÂÂÂÂ.nsbmd
0x000ABEFCÂÂÂÂ0x00000004ÂÂÂÂ.pac
0x000ABF04ÂÂÂÂ0x00000006ÂÂÂÂ.nsbca
0x000ABF0CÂÂÂÂ0x00000006ÂÂÂÂ.nsbta
0x000ABF14ÂÂÂÂ0x00000006ÂÂÂÂ.nsbtp
0x000ABF1CÂÂÂÂ0x00000006ÂÂÂÂ.nsbva
0x000ABF24ÂÂÂÂ0x00000006ÂÂÂÂ.nsbma
0x000ABF2CÂÂÂÂ0x00000004ÂÂÂÂ.pac
0x000ABF38ÂÂÂÂ0x00000004ÂÂÂÂ.pac
0x000ABF40ÂÂÂÂ0x00000004ÂÂÂÂ.pac
0x000ABF48ÂÂÂÂ0x00000004ÂÂÂÂ.pac
0x000ABF9CÂÂÂÂ0x0000000BÂÂÂÂ@@@@@@@@@@@
0x000ACB9CÂÂÂÂ0x0000000CÂÂÂÂtrackBallBG1
0x000ACBACÂÂÂÂ0x0000000CÂÂÂÂtrackBallBG2
0x000ACBBCÂÂÂÂ0x0000000DÂÂÂÂtrackBallObj1
0x000ACBCCÂÂÂÂ0x0000000BÂÂÂÂui_koro04_1
0x000ACBD8ÂÂÂÂ0x00000007ÂÂÂÂElement
0x000ACBE0ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACBE8ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACBF0ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACBF8ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC00ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC08ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC10ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC18ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC20ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC28ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC30ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC38ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC40ÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ACC48ÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ACC50ÂÂÂÂ0x0000000BÂÂÂÂui_koro03_1
0x000ACC5CÂÂÂÂ0x00000007ÂÂÂÂElement
0x000ACC64ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC6CÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC74ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC7CÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC84ÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC8CÂÂÂÂ0x00000004ÂÂÂÂLc10
0x000ACC94ÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ACC9CÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ACCA4ÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ACCACÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ACCB4ÂÂÂÂ0x00000007ÂÂÂÂtrcball
0x000ACCE0ÂÂÂÂ0x00000004ÂÂÂÂ</div>

There is but one msn in all that (msn060) which I find curious. Do also have a little search against <a href="http://www.romhacking.net/docs/%5B469%5Dnds_formats.htm" target="_blank">http://www.romhacking.net/docs/%5B469%5Dnds_formats.htm</a> - many format magic stamps.

I will also note the "boj_body"- typo perhaps (always nice to bugfix a game you are hacking, alternatively it might be a simple break for the game to stop it loading a file for whatever reason- kind of like how you might rename a virus fixing program to dodge some checks).

Hmm it seems I turned this into another investigation post rather than a formats and markup post I intended to make. Oh well hopefully it is still useful, more pulling things apart and checking them against the game look to be in order. Possibly even seeing if you can expand the files a bit- get them to display images where there were none. Wonder if I we will see a total conversion of this at some point.

Edit Another two values to look at
0100 1C00 - always seem to preceed msn values and other choice things.
0600 1C00 - always seem to preceed "Btl??" and one case of "skip" and another single case of "Label_1"
Together aside from a few length values a search for 1C00 is also pretty useful.

FAST6191 · Jul 22, 2011

event.dat decoding method for The Wizard of Oz: Beyond the Yellow Brick Road
A game scripting language after a fashion.
Seems to be broken up into sections. Mostly titled "msn" but several others.
No overall pointer section in the event.dat itself and nothing obvious in the binary (I checked for lengths, locations, rom offsets and other similar features) but I did not head down the disassembly path.

Relative pointers stacked on top of/following pointers similar to the pac files that kicked this whole thread off.
In some ways it appears to be derived from a C type language or one that revolves around lengths as opposed to a true parser (that or it is a binary markup language).

I also looked at it from the perspective of the text as well, there appear to be some branching paths however minor (seemingly for no responses). This, assuming nothing buried in the binary somewhere, is great as it means you can change lengths and only have to worry about the one file.

Commands
I posit the 0c 1c and other things before the msn and co are in fact section lengths as they quite often correspond to lengths of stuff before something else. C appears a lot as it is a multiple of 4.
Calls/choose your own adventure stylings- one section does appear to be able to call the other.
It is probably best if the whole file is considered part of the scripting language.
To then end you can be considered to have text objects that are fed to the text parser somewhere else. This text parser uses 0a for a new line, supports ASCII and shiftJIS with the shiftJIS appearing to be an immediate detection rather than needing to be in a 16 bit length. ShiftJIS is important (I refer back to the (?) part) and there appears to be some untranslated text buried within the file. On occasion the text section appears to end with some random data but I have yet to figure what this does.

006E = dog name.
0073 7472 (.str) at BE4
7570 at the ghost meeting (first battle in the game on that video- http://www.youtube.com/watch?v=rnOf4S31ZyU ).
0064 0A79 at scarecrow naming.

The script engine looks to parse the whole file.
It starts with newscn, ends with scnend, has dbgscn at the start and one other mention in the file. This is getting slightly ahead of things though

Commands appear to be up to three fold (all hexadecimal unless otherwise noted)

First seems to be a command type, in order of their appearances in the event.dat file
0100 new scene, new message (msn) some times. dsn as well.
0400 Wmap stuff, j000 (3d models?) at 1c30 "0400 1000 4630 3031 4930 3030 0100 0000" ....F001I000....
0700 new message (msn) on occasion.
0800 U000, w000 and such. No idea what this means for the rom as a whole. Also G014 F001
1000 n? ?=number. This would appear to correspond to the 6E?? thing of another 3d model command.
0D00 character name
0300 some normal text. Padded to 8 bytes for type and name.
0E00 not sure. At 348 "0E00 0800 0700 0000" at 428 "0E00 0800 0700 0000" at 4dc "0E00 0800 3300 0000" at 07bc 0E00 0800 2A00 0000
0F00 (first seen at 4e4) data there "0F00 0800 C900 0100"
0200 (first seen at 4ec) data there "0200 0C00 626B 4130 3100 0000" at 7CC "0200 0C00 626B 4130 3200 0000" . This would be the bk files.
0600 First appear at CCB8 (if you do a search the first one is part of another file). This looks to be a kind of warp.

Code:

0000CCB8 0600 1C00 736B 6970 5F31 0000 0100 0000 ....skip_1......
0000CCC8 7275 6E30 3539 0000 0100 0000ÂÂÂÂÂÂÂÂÂÂ run059......

FC80 has some good 0600 stuff.

Code:

0001074C 0600 1C00 4274 6C5F 3100 0000 0100 0000 6472 6130 3100 0000 0000 0000 ....Btl_1.......dra01.......
00010768 0600 1C00 4274 6C5F 3200 0000 0100 0000 6472 6130 3100 0000 0100 0000 ....Btl_2.......dra01.......
00010784 0600 1C00 4274 6C5F 3300 0000 0100 0000 6472 6130 3100 0000 0200 0000 ....Btl_3.......dra01.......
000107A0 0600 1C00 4274 6C5F 3400 0000 0100 0000 6472 6130 3100 0000 0300 0000 ....Btl_4.......dra01.......
000107BC 0600 1C00 4274 6C5F 3500 0000 0100 0000 6472 6130 3100 0000 0400 0000 ....Btl_5.......dra01.......
000107D8 0600 1C00 4274 6C5F 3600 0000 0000 0000 0000 0000 0000 0000 0000 0000 ....Btl_6...................
000107F4 0A00 0C00 4274 6C5F 3100 0000ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ....Btl_1...

Shortly after that is
0A00 Another warp perhaps (it appears around the dsn stuff and just before the text for "Father Dragon"

0900 shortly after. Another possible warp (looks to be a yes/no challenge type battle).

Sometimes it runs 07 then 01 for the same name msn

I was far too lazy to parse the lot by hand so I skipped around checking every so often after a while and it always held up.
The highest number there is 1000 where the lowest is 0100 with hex in there so the obvious thing to do is look for the missing values.

By my reckoning there should be commands
0100
0200
0300
0400
0500
0600
0700
0800
0900
0A00
0B00
0C00
0D00
0E00
0F00
1000
1100
1200
1300
and possibly up to 1F00

Ignoring the above that leaves
0000 Troublesome to search for but I may have found one, albeit it appeared to be a NOP (short for No OPeration- a way of stalling for a cycle) of a sort (0000 0400 - 4 a command and one that is 4 long means this does nothing) at 011c48.
0500 searching after a few false positives leaves some "dra??" and "skills"
0B00 Nothing at all in the entire file.
0C00 A common length value it seems. 011c40 has 0C00 0800 FE01 1200 and a search for 0c00 0800 nets some results that appear valid at a glance.
1100 Possible at 1Bc4 with 1100 0800 FFFF FFFF
1200 No commands used here.
1300 1 possible at DDD4

Aside from 0500 most of those will have to be determined experimentally or if you do fancy figuring out if any commands were not used (some debug commands or something) it is time for ASM.

Not sure where I should record this but when names appear it appears as though the default name is picked for the file-
After you name the scarecrow the next time Airy Scarecrow changes to plain "Strawman". Player names appear to follow the same pattern. I guess this also means you have to account for this if you are going to go the total conversion route.

Going for speculation I am guessing there is a kind of counter kept for save data (and actual running) as opposed to a proper pointer. Not sure how it works- you are going to want full screens on restoration of saves so it might keep a counter at the last msn or something. I guess the game could also do a search of sorts although that could be tricky.

Second seems to be a length value for the command type in hex, no byte flipping necessary. Padding on occasion (will have to be determined for the file types- mainly padded for 0300). The 0300 stuff seems to do a kind of roman language style length value and has the entire thing left most- B000 0000 0000 0000 rather than 0000 0000 0000 00B0 (give or take endianess)

that I can recall I have not seen a length value greater than 8 bits with most text sections being broken up before they get that far (even within the msn).

The third part of the command is the actual command data/payload.
Should further input be needed as it is for a several commands that comes third. This can include loadings for screens (several of the text free msn files do this), text still needs to be properly decoded but I am guessing the random end values can be formatting of a sort.

This can be text or other micro commands by the looks of things- some of the msn stuff presumably has some probably 2d image data calls.

Ultra short good news- assuming no file level pointers you can edit as much as you like and you only have to change the length values for the section you are editing. Scripting engine stuff is a pain but believe me when I say just about every rom hacker that has ever had to tangle with "proper" pointers would trade places with you for this in a heart beat.

Leeg · Jun 19, 2012

Well... er.... Hello again, I am sorry for not posting anything in a whole year ... I have been really busy with college and had to drop the translation of this game... So I do not really think anyone will answer my following question because I do not really deserve it...

but here it goes:

I've reached a part of the script in "event.dat" which doesn't obbey the rules of the other texts.

To remind how it worked:
There were 03 00 XX 00 placed just before every piece of text, the XX were the value of its length. So for instance:

Here, the text has a length of 18, so the hex is 03 00 18 00.

Now I will explain the problem I found...

When I reached this part of the script:

I found that if I tried to change the hex value which defines the lengh of that text the rom would not work. And if I gave a wrong value, the rom would run fine, but when reaching that part, the whole game would not display more text at all.

I don not know why is this happening... it is as if the length rules previously stated are not working here... I have tried skipping that part and going on, but it is all the same, editing the length will not work in all further text.

So yeah, I am totally lost here. I have tried differents things but I have not reached a solution yet.

Thanks. And sorry again for not being here.

FAST6191 · Jun 19, 2012

Looks like you made a minor mistake (I have done similar things after staring at pointers for a long time when going manual there on many occasions and I do not even want to think about the times I tried manually decompressing a few hundred bytes of LZ) and counted from the text rather than the start of the command that we eventually sussed the format out as, fortunately I was playing with the method again the other day as part of the docs.
What I decoded it as

Sorry about the poor choice of colours there but it should still be OK.

Leeg · Jun 20, 2012

Hi, FAST6191. Thanks for your reply, you are really kind

From what I have understood in your post, if I got this:

Length: 18

And just for the sake of testing I add 4 bytes (taking for granted that I need them). Then 18 + 4 = 1C.

The result will be:

Length: 1C

I think that this follows the rules I have been using in all the previous script... but it will not work here (the rom will not run). Well, in fact, the length method will not work since the previous chunk of text "You have come a long way, and I welcome you!!!" forwards.

Thanks again,

FAST6191 · Jun 20, 2012

That would be the change I would make but I would be hesitant to pad it out with 00 - try 20 (space) or some other valid character instead (00 in text assuming it is not just space tends to do odd things).

After this I have to think memory issues (you are presently 04E0 ahead of the original script by my count) or screen alignment issues (too much text in a box/buffer). To test for the former see what happens if you edit the next text box after this section and make it longer (although it is pretty long by the looks of things which might speak to the buffer idea).

Leeg · Jun 20, 2012

Ok, so I have tried filling the empty bytes with 20, but the result is the same.

The kind of text I am currently editing appears in screen like this:

"I have been awaiting your arrival.
Welcome to my castle, brave warriors!!"

In the example shown in this screen I did not have any problems at all to enlarge its length, the problem begins with the part "You have come a long way, and I welcome you!!!"

The next chunk of text (the big one) is a bkscene, so it appears book-like, as in the beginning of the game. It seems I cannot change its length (although I could do it in previous bkscenes), the rom will not open, and the same with the rest of the script.. :S I am starting to think that I will not be able to conclude this.

I know it will be really hard to find a solution, and of course I am not asking anyone to do it for me. I think it would be enough to have some testing ideas to try new things. What really bothers me is that the rom does not open when I give it the right length for that text, but it will when a random length is given, although it will not display the text.

Leeg · Jun 20, 2012

Damn!

I have tested something... and I did not like its result.

I have tried deleting 4 bytes of previous text and adding them to the part that gives me problems... the result is... that it worked...so... what does it mean? which conclusion can I draw from this? Have I filled all the space in the rom so I cannot edit anything more? I hope not... :'(

rastsan · Jun 20, 2012

time to take this to a debugger. Insert a breakpoint just before the text in question and see exactly what is happening. If possible video that and post here for others to take a look at.

Leeg · Jun 20, 2012

A breakpoint? I am quite ignorant... and do not know exactly what is that... sorry :S

rastsan · Jun 21, 2012

Its what Fast was talking about with the buffer thing. So play the game in a debugging emulator (desmume, nogba....)
Take a clean unedited version of your rom and dump the memory with haste or emuhaste. Do the same with your edited version. Then find the text that isn't edited in the first memory dump. Find in memory in the second dump the the edited text. Please note if they are not at the same offset then that is a big flag of trouble. (well plus the additional 4e0 fast was talking about. )
If they are in relatively the same spot as in the original clean memory - see what you are overwriting with your new text. If you are lucky It won't be anything. If you are unlucky something is being written to an area you are using for your edited text. You won't know until you compare both memory dumps.
this will also be your chance to do a couple things. one to look for space to send you edited text. two to see if the pointers in file are being changed to memory pointers and to check if in the clean memory dump if stuff is being over written and pointed to - to. If it goes well you may just have a memory based pointer some where that needs to get moved or another file that needs to be shifted to another spot or you have now found space to write your new text (which is why you were looking for "empty" space).

I know there are better guides then me trying to explain to you how to insert breakpoints so I will let google be your friend for searching for that. Breakpoints are good for seeing just exactly where the error happens. Also for seeing what you can do to fix them. Sorry i couldn't be of more help.

Leeg · Jun 21, 2012

rastsan,

All help is appreciated, thanks ^^. I know that what I am doing is not an easy task, and that I should have more knowledge on the topic...
However, I am afraid I will not be able to accomplish your task since the rom does not run when editing that part. ARM9 disassembler gives this:

Anyway... I also found this:
http://vgcoding.blogspot.com.es/2011/01/how-to-debug-your-nds-rom-using-visual.html Could you take a quick look at this and tell me if this is what you request? I could try to do it.

Thanks again.

FAST6191 · Jun 21, 2012

Desmume has some stuff but I would instead look at iDeaS for this type of debugging (primarily as it has a run to selection breakpoint option, it is not as nice to play roms on but that is not why we are here)- http://ciacin.site90.com/ideas.php
The idea is you get to just before the scene and then go to the debugging window and find a location before pressing run to selection and then analysing the differences memory (it could be the classic buffer overflow).
I will have to have a look at the blog link though as debugging grade tools aside from no$gba dev version (not sure if we can get it again), maybe IDA* and possibly datel cheat making gear aside there is nothing much compared to the likes of VBA-SDL-h on the GBA. Debugging can still be done it is just not as nice and Ratsan's technique is quite valid but it is something of a workaround for a lack of true debugging abilities as seen on the likes of the GBA.

*compared to the x86 debugging abilities what I have seen of ARM debugging in IDA is not that close.

If it is a lack of memory/too small buffer although you can start doing memory handling it would not be the first game to have two parts to the hack (play up to ? and save it, run the second rom patch and load the save there). I suspect it is more of an immediate buffer issue though for as you say right after that there are a couple of huge sections and if it tries to fit them all in memory that is where issues might appear.

That reducing the size still works (ish) only strengthens that case which means again you could head down the full memory shuffling hack path or instead comes the ancient art of fudging the translation for space reasons. For instance "I have been awaiting your arrival. Welcome to my castle, brave warriors!!" is a nice line but "Brave warriors I have been expecting you" means almost exactly the same thing and probably does not lose anything (it does not look like something that will be referenced later or a notable speech pattern). You could go further than that even ("Brave warriors, welcome" or "Welcome brave warriors") but I do recall the wizard in the original story being somewhat grandiose for these scenes so that might not be ideal.

Leeg · Jun 21, 2012

Hi FAST6191,

Thanks for your reply. Excuse my ignorance but... how am I supposed to get to that part of the game if the rom does not open? I can play my edited rom to that point without editing that part, but I do not see the point on doing so :S

If it is a lack of memory problem, then I am f*cked, because I have hardly reached the beginning of the game,... if I had to split this, maybe the result would be more than 30 patches to complete the translation. I hope it is not that kind of problem, since giving another hex value to the length of that part makes the rom run perfectly, but without displaying further text from that point onwards. The problem comes when I give it the right value.

Thanks again.

FAST6191 · Jun 21, 2012

My apologies I should have elaborated
I was thinking more along the lines or see how the original game handles it and see how the original game with regards to what has changed in memory and what happens when your working edit gets to that point.

It might be that despite the scripting language no three sections should have more than so many bytes or the decode/graphics making command will overwrite something (it looks like the game itself can go backwards if you want at the end of a given sequence). To that end the lack of memory might not be for the entire file just a few sections.

Also it might be time to try something like using the scripting engine properly as right now you are just changing command lengths which is fine but instead consider adding a command/splitting an existing command across a couple of them. My first instinct there would be to see if 0000 0400 is in fact a NOP (no operation) command as there are a few things it could be but NOP is still my main guess).

Edit
I did just dump the ram and it might be the bad scenario after all as it seems the whole event.dat is in memory from the start and after it there is some stuff which looks like pointers to memory (these would be generated at runtime it looks like, there are about 130 of them and they are pointing at choice locations of text like the start of it) and then 600 hex of 00 (this might be what you are running out of but I am not prepared to call that as it looks like there is a lot of stuff happening at runtime- this game gets odder and odder compared to standard games).
At this stage there does appear to be a tiny bit of space elsewhere in the ram but I dumped it quite literally as the witch first appeared on screen so that might not hold if we do end up having to try something clever but I do not want to think about that yet.
Edit2- checked a bit later and the ram is fairly full.

Looks like some more testing as to what might be happening needs to be done. I had hoped with a scripting engine like this it would be easier but apparently not.

Edit3.... thinking about it this might be a prime candidate for a hack to use the GBA memory section (32 megs of low latency, high speed memory visible directly on the memory bus that is not really used for anything outside of homebrew and the browser).

ROM Hack .pac files help

Well-Known Member

Well-Known Member

8 baller, Death Wizard,

Techromancer

Well-Known Member

Techromancer

Techromancer

Well-Known Member

Techromancer

Well-Known Member

Techromancer

Well-Known Member

Well-Known Member

8 baller, Death Wizard,

Well-Known Member

8 baller, Death Wizard,

Well-Known Member

Techromancer

Well-Known Member

Techromancer

Similar threads