ROM Hack .pac files help

Naxito pretty much covered it all already but I felt like pulling something apart. I believe some work in pac has come before but I started from scratch. I am only working with your linked file at this stage.

Unless otherwise stated all numbers in hexadecimal.

LZ compressed- various clues but if the first byte of the file is 10, 11 or 40 then do consider compression (there are other clues as well like names and the actual data). 10 is the most common and many tools can handle it. It looks like the file is one straight compression as opposed to an archive of compressed files which is nice.
The DS SDK has several image formats which can be used.
http://llref.emutalk.net/docs/?file=xml/ncgr.xml#xml-doc
You can see RGCN and a broken up RAHC (the 08 is likely a compression artefact) which points at images.

Decompressing it then (crystaltile2, http://code.google.com/p/dsdecmp/ and http://gbatemp.net/t274472-codec-lzss-ds-released all have abilities here) gives a new file to play with and one that I will probably be using from here on out.

At 4264 you have RLCN followed by TTLP
http://llref.emutalk.net/docs/?file=xml/nclr.xml#xml-doc

At 8290 hex I see RCSN otherwise known as NSCR http://llref.emutalk.net/docs/?file=xml/nscr.xml#xml-doc

Before the palette file I also saw SOPC which consists entirely of
534F 5043 1000 0000 0000 0000 2000 1000 but looking at the NCGR file (using the internal size) it falls in that. It does not feature in most of the NCGR specs that I have seen and even those with it are pretty hazy.

Loading the decompressed file in a tile editor under GBA 8bpp and fiddling with tile size and starting location gives me


Of course that is the brute force method, as mentioned we are dealing with SDK formats so we probably need to extract them.

The header of the file before the RGCN (once decompressed)

That does little so a bit of tweaking and a byte flip gives



The whole file is 8AB4 long.
Locations of the file
0028 (the NCGR file)
8068 (the NCLR file)
8290 (the NSCR file)

No direct link but the header is 28 long so taking 28 hex from each of those

0000
8040 (the length of the NCGR file)
8268

8268-8040= 0228 aka the length of the NCLR

I then pulled the NSCR file and it was 0824 long

Going back
00000004 0000 0000 ....
00000008 0000 8040 ...@
0000000C 0000 0228 ...(
00000010 0000 0824 ...$

No padding and it seems to be a length value using the ones that came before it. A crude format (no addresses, no names, straight compression necessitating decompression happen all at once, not much/anything for the archive, no padding- all things that make life far easier when dealing with archive formats) but I guess I would rather go that than some of the nasty ones I have seen over the years.

The 0003 0201 part has me curious and until I pull apart other files (or the game) I am not likely to know. No fear guess has it as number of files contained within and what else I have no idea.

So I have reverse engineered part of a format at least, I extracted (simple hex editor copy and paste) the files from the decompressed file and made 3 files named corresponding to their type (you might see it below), stuffed the files into a container rom (easier to trick crystaltile2 into loading it that way) and a few clicks in the File system window (right click, load palette, Map address load, retrieve tile address) gives me

So you have a game with almost true unicode you say- 16 bits where necessary and 8 bits otherwise. You wanted characters/glyphs not in the original character set by replacing Japanese characters which originally used 16 bits and stuck yourself with 16 bit characters when you need to use them.

As shadowmanwkp said the problem is twofold although not necessarily in the manner spoken of (although it is for the most part correct)
1) screen real estate. European languages take more characters and trying to cram them into the screen (and on occasion memory) can get troublesome but that does not seem to be a problem you face at this point.

2) rom space. As shadowmanwkp said you can try to butcher your translation to fit (possibly even down to sentence length) but that is a horrible thing to have to do and should not be done unless you are truly limited so at this point you get to learn about pointers.
I like to try and explain them like a contents section in a book but rather than page numbers you have addresses of some form. They usually come before the text starts but they can found in other files (usually named very similarly or found in the same archive), in the binary, not be necessary (see some of the later methods), after the text, nestled among the text or pretty much anywhere else.

There are several methods but the big three are
Standard- from the start of the file to the location you want pointed at.
Relative- from this point/address add the number contained within and you will get to the place you need to be. Think "move on 10 pages" in a choose your own adventure book.
Offset- standard with a twist of not counting the pointers themselves, part of the file, the header or some value to make them correct as far as differences go (one pointer take the previous will do a pretty good line in getting the length of a section- remember things can be padded to make them fit into 16 bit boundaries) but always "off" by a little bit if you count from the start. Kind of how a book might start with page numbers in Roman numerals so despite there being 40 physical pages by this point the numbers only read 32.

A quick example of some of these three can be seen http://gbatemp.net/index.php?showtopic=122534&hl= . It is for audio hacking but the idea is the same.


If playing in the binary or overlays you can be pointed to actual memory (the GBA does it all the time- indeed searching for "08" (that start of the most commonly used address to the first 16 megs of a GBA rom) and seeing a sea of them close together usually signals something good) but for the most part the DS limits itself to the files you find them in or their kin (like those image formats you can occasionally find files of similar name with pointers for the files contained within them).

On top of this you also have fixed length, sized and dynamically generated.
Fixed length is usually seen in menus where an entry will be ? characters and only ? characters. Here you probably even have to pad the entry out or your next entry will start after this finishes. Working around this is usually an ASM hack but if you like you can do as you did for the font but cram several characters in there but unless you have a nasty old Japanese game you can usually make do, especially for a menu (if you have ever played a game in French it might read app sur start instead of appuyez sur start- same idea. It is also why some RPGs have odd spellings for spells or name changes as time wore on- fire1,fire2,fire3 instead of fire, fira and firaga in Final Fantasy and similar things in Phantasy Star).

sized is exactly the same as the pac files we just pulled apart. It is a long list of sizes of each line to come which the game can add on to the last. I am struggling to think of any game text that does this (or at least not without more conventional pointers). Indeed even for an archive format that shocked me.

dynamically generated is rarely used on handhelds (indeed at present it is only the zombie daisuki game on the DS that I can think of right now that uses it) but on the home consoles and PC is it possibly the most common. Here the game figures out where the paragraph ends usually by scanning through the text and figuring it out which is expensive to do on a limited power system.

Do remember the GBA and DS use Little-Endian which means so do most pointers (no sense in swapping them only to swap them back again) so you may have to flip the bytes accordingly (like I did for that size list in the pac file). 1234 5678 would be read as 7856 3412


Various hybrid methods have been cooked up over the years and among pointers you can also find formatting- one entry might be a pointer where the other makes it bold, blinking, underlined, coloured a certain way not to mention pointers themselves can be used to indicate end of paragraphs and do a measure of screen formatting (new lines and what have you). It is worth knowing about languages for these occasions- Japanese has little in the way of paragraphs compared to the European languages and developers might not afford such abilities in a Japanese language game.

Re rom size- that has not been quite so true since the days of the SNES- the GBA allowed up to 32 megabytes once you used the upper memory ranges and the DS is 512 megabytes or more likely the limits of your current file format (for most formats pointers are not more than 4 bytes) or if you have text buried in binaries/overlays then you have to start making tough choices.

Pointer fixing is probably the most tedious part of translation hacking (and a lot of other hacking considering all the archive formats used these days) as you can probably guess changing something early breaks everything that follows meaning you get to change the lot or work around it . Various programs have been made to try and tackle it but as pointers can come in any format they are either useless for all but the simplest format or the game they were built for or they might as well be programming languages in their own right. Even if they have pointers though the end of a line will usually be signified in some manner which you can find/generate a list of the use when building you new pointers. To this end if it is not simple enough to work around or I am just editing a few things I will usually do it in a spreadsheet or try to cobble together a program.

I pulled apart the tutorial .pac using the same method as before- worked fine.
Open file in crystaltile2
Hex editor window- tools pulldown menu "LZ77/HUFFMAN Extract (U)". Save as appropriate.

Open new file in hex editor, slice off "header" into new file. Shift length to 4 bytes. Flip it.


To make life easier though the output of a crude spreadsheet I knocked together.
1868
1A90
22B4

Sliced off all the files and saved them according to their type. Bundled them into a rom purely to make it easier to use with crystaltile2
In the DS filesystem menu right click on each of the files to load tile address, palette and map
Gives me


It looks like the map had something big to do this time (many repeated tiles as you will see if you try editing it in crystaltile2's editor) but nothing different.

The ntf is a different matter, there is a format that has ntf as part of the name ( http://www.romhacking.net/docs/%5B469%5Dnd...ts.htm#Graphics ). Fortunately it does not appear to be compressed (no real indicators and compressing it again more than halves the space it takes up). I am guessing it is similar the times formats leave off part of an extension (see arc and narc). I managed to cobble together


But I am not entirely sure how I got there. By the looks of things it is treating it as a massive tile. I did some basic fiddling with the file (it is too big for an image alone and the first 200h could be interesting (not to mention the exact length of a raw palette) but did not get far. (bonus though it got me to stumble across a site containing some of the "lost" tahaxan data once I did a bit of fiddling- got to love sites that still let in crawler bots even when everything else is blocked for the most part).

I think it is approaching time that I see this game run and maybe pull some stuff from it (or at least snatch the palettes from so I can do a search of the rom).

Thanks Naxito. How I miss the palette fiddling options of tileed 2002 (it did not like large images like this)

Full image for the curious


In that case I guess the somewhat redundant in this case NTFS files follow the image.

Using lossless image formats should go without saying but I will say it anyway.

I do not quite follow- I assume you are aware of the limits of the palette driven images- you have to edit the palette (do pay attention to games that reuse palettes or images- images are usually only a trouble with sprites though) or use the colours available in the palette*.
For straight export crystaltile2 does have some stuff (also works for hex editor and disassembly windows although more useful for their respective abilities) that you can seemingly also import. If you are so inclined there is also an expression style exporter or you can always kick it to tile level.
If you are still fighting with the image maps that might also get tricky if you have to export and import although you might be able to take it down to tile level.

Granted it is only a crystaltile2 demo (for a proper one I should have at least stuck it back in the rom and ran it through an emulator) but it is imported and changes are reflected in the hex. I moved the text on the exported image seen in the GIMP window after I had first exported it from GIMP to use in crystaltile2 as a kind of demo.


*three options here to my mind
1) Export the palette from crystaltile2 (most tile editors worth anything will have this option although beware of format incompatibilities if using one of the older ones- crystaltile2 can also import bitmaps by the looks of things which is nice).

2) Printscreen the palette and use the colour dropper. Crude but effective.

3) Find the colour on the exported file and colour grab it.

Most of these will do nasty things to any images you plan to do any proper colour editing, play with gradients or graded shadows...... so know this and respect this when editing (if you have a friend that is a proper pixel artist have a conversation with them).

Likewise if you are off the ntf stuff then there are a precious few programs with support for the SDK format by way of susie plugins- http://gbatemp.net/t162863-susie-plugins-f...tro-rom-file-sy

An example of when good maps go bad




That took all of about 7 clicks to mess it up like that

Fans of developer left extras there is a file with some XML markup called BtlFld.isd which appeared to be connected to the 3d files in some way (my bet is on it is a file that should have been lost when the makefile ran but ended up sticking around rather than something the game uses). I have not looked to see what went with the 3d SDK but it is there for those that want to look at it. I doubt it will be as nice as that princess maker largely complete source code, the SDAT stuff from zoids (and since several other roms) or the inazuma 11 makefile but hey.

Going to be some thumbnails for this one as there are already enough large images in this thread (largely thanks to my PNG happiness) and now I jumping to silly high resolution for various things. Back on decimal numbers unless otherwise noted.

Following our conversation on IRC I looked at the rom some more
You said the following have text in them
event.dat
global_data.dat
default_data.dat

Also endroll and op.dat for credits so I am ignoring them for now (not to mention they appear to be another file format). global_data.dat mainly seemed to be a file name list and numbers counting up (for the most part) next to them once you remove the first couple of bytes.

Lots of ASCII text which is nice.
At a glance it looks like a mixture of things-

Default_data.dat for now.
Some fixed length entries (ideally I would have had every entry on a single line but my hex editor did not stretch that far)

<a href="http://pix.gbatemp.net/32303/8wizardozndsdemohack15jul2011.jpg" target="_blank"><img src="http://pix.gbatemp.net/32303/8wizardozndsdemohack15jul2011.jpg.tn.jpg" border="0" class="linked-image" /></a>
<a href="http://pix.gbatemp.net/32303/9wizardozndsdemohack15jul2011.jpg" target="_blank"><img src="http://pix.gbatemp.net/32303/9wizardozndsdemohack15jul2011.jpg.tn.jpg" border="0" class="linked-image" /></a>
And it goes on with various different lengths. Some databases for want of a better word are really small*

I am not shocked but I usually only see that sort of thing in packing formats and for very small entries in menus. I have seen combined fixed length and pointers/size values before and even if it is not I would not go crazy with extra lengths not to mention I have not figured out what the "second" lines mean (I am guessing some Japanese although it might be something to help the game (there are fair few control codes dotted around) too, what would be really awesome is if those were actual stats) but best case scenario (which is quite likely) you have some space to play with and no worries with having to adjust pointers. If it really bothers you (Spanish is not all that verbose compared to English as far as I know) there could be ways to change it but make life easy on yourself and try to cut your text down instead if it comes to it.
It does not look to be the case here but when doing this on other roms watch out you are not changing the names of variables or something (here there are proper names- most programmers will not bother to change the case and use of spaces in variable names is often not even possible in many languages).

* compare the first four sections (names of the player characters I know)

<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->00000000 446F 726F 7468 7900 0000 0000 0000 0000 1E00 0700 0600 0800 0A00 Dorothy...................
0000001A 0A00 0600 0600 1000 0101 0E2A 6452 4253 6464 7474 97F6 0000 0AFF ...........*dRBSddtt......
00000034 5374 7261 776D 616E 0000 0000 0000 0000 2700 0600 0A00 0B00 0E00 Strawman........'.........
0000004E 0E00 0C00 0C00 1B00 0102 1531 7431 4252 6363 7575 A80F 0FD3 0FFF ...........1t1BRccuu......
00000068 4C69 6F6E 0000 0000 0000 0000 0000 0000 3400 0900 1500 1200 1400 Lion............4.........
00000082 0E00 0F00 0F00 1C00 0203 1C38 8541 5363 5352 6464 860A 0000 F6FF ...........8.AScSRdd......
0000009C 5469 6E20 4D61 6E00 0000 0000 0000 0000 5000 0A00 2A00 1E00 1200 Tin Man.........P...*.....
000000B6 1800 1600 1600 2400 0405 233F 9742 7564 5253 6363 750F D30F 0FFF ......$...#?.BudRSccu.....
000000D0 0100 0000 0500 0000 4775 6D6D 7920 4768 6F73 7400 0000 0000 3030 ........Gummy Ghost.....00
000000EA 3100 0000 0000 0000 0000 0000 0000 1E00 1E00 0000 0000 0000 0000 1.........................
00000104 0504 0014 0000 0000 0600 0001 0000 0000 8203 0914 0A00 0000 0005 ..........................
0000011E 0000 0000 0000 0005 0000 0000 0000 0005 0000 0000 0000 0000 0000 ..........................
00000138 0000 0000 0000 0000 0000 0000 CDCC 8C3F 00E0 0E00 0A00 1300 0100 ...............?..........
00000152 1600 1600 1A00 1A00 1000 0100 0100 0001 0100 004B 644B 6400 4B4B ...................KdKd.KK
0000016C 6400 0006 0A0A 4600 5375 6D6D 6572 2047 686F 7374 0000 0000 3030 d.....F.Summer Ghost....00
00000186 3200 0000 0000 0000 0000 0000 0000 1E00 1E00 0000 0000 0000 0000 2.........................
000001A0 0504 0014 0000 0000 4905 020A 0000 0000 0600 0001 0000 0000 8203 ........I.................
000001BA 091E 0A00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ..........................
000001D4 0000 0000 0000 0000 0000 0000 0000 803F 00E0 2800 5000 4D00 2D00 ...............?..(.P.M.-.
000001EE 5900 5900 8C00 8C00 8800 1B00 0100 0010 0100 004B 644B 6400 4B4B Y.Y................KdKd.KK
00000208 3202 0006 0A0A 4600 436F 6F6C 2047 686F 7374 0000 0000 0000 3030 2.....F.Cool Ghost......00
00000222 3300 0000 0000 0000 0000 0000 0000 1E00 1E00 0000 0000 0000 0000 3.........................
0000023C 0504 0014 0000 0000 7805 030A 1900 0000 0600 0001 0000 0000 8203 ........x.................
00000256 091E 0A00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ..........................
00000270 0000 0000 0000 0000 0000 0000 9A99 993E 00E0 3600 7800 6D00 4200 ...............>..6.x.m.B.
0000028A 7C00 7C00 C900 C900 C000 4100 0100 0017 0100 0000 644B 6400 4B4B |.|.......A.........dKd.KK
000002A4 4B07 0006 0A0A 4600 5370 6F6F 6B79 2042 6F6F 0000 0000 0000 3030 K.....F.Spooky Boo......00<!--c2--></div><!--ec2-->

I have seen that between each of the sections there are a lot of unknown sections.

This of course does nothing for the main issue here

After the bestiary, item lists and locations come a few names by the looks of things and status effects.

The names look like 12 byte lists again but the ???e entries ( d01e and such) do not have anything in the 8th and 9th bytes which could indicate something- most of the entries elsewhere in that list have the same or some common value which could mean it is a flag.
Likewise some of the entries appear to jump very high in the numbers range (with an 8 but the lower part appears to follow on from the stuff before it. Kick it to the binary rather than hex and you will see that the first bit is high- such things are used all the time to signify things (NARC files I believe do it to signify directories and such)
Also possibly notable- I did not have to flip those bytes.

<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->00000000 6430 3000 0000 0000 1400 0051 d00........Q
0000000C 6430 3100 0000 0000 1400 0155 d01........U
00000018 6430 3200 0000 0000 1900 0157 d02........W
00000024 6430 3300 0000 0000 1400 0158 d03........X
00000030 6430 3400 0000 0000 0A00 015A d04........Z
0000003C 6430 3500 0000 0000 1E00 015C d05........\
00000048 6430 3600 0000 0000 1900 815E d06........^
00000054 6430 3700 0000 0000 1400 0160 d07........`
00000060 6430 3800 0000 0000 6400 8162 d08.....d..b
0000006C 6B61 3030 0000 0000 1400 0052 ka00.......R
00000078 6B61 3031 0000 0000 1900 0163 ka01.......c
00000084 6B61 3032 0000 0000 1400 0064 ka02.......d
00000090 6B61 3033 0000 0000 1900 0165 ka03.......e
0000009C 6B61 3034 0000 0000 1400 0166 ka04.......f
000000A8 6B61 3035 0000 0000 1400 0167 ka05.......g
000000B4 6B61 3036 0000 0000 1400 0068 ka06.......h
000000C0 6B61 3037 0000 0000 1900 8169 ka07.......i
000000CC 6B61 3038 0000 0000 1400 816A ka08.......j
000000D8 6C30 3000 0000 0000 1400 0053 l00........S
000000E4 6C30 3100 0000 0000 1400 016D l01........m
000000F0 6C30 3200 0000 0000 1400 016E l02........n
000000FC 6C30 3300 0000 0000 1900 8170 l03........p
00000108 6C30 3400 0000 0000 1900 8172 l04........r
00000114 6C30 3500 0000 0000 1400 0173 l05........s
00000120 6C30 3600 0000 0000 1E00 0174 l06........t
0000012C 6C30 3700 0000 0000 1400 8076 l07........v
00000138 6C30 3800 0000 0000 1400 8178 l08........x
00000144 6B69 3030 0000 0000 1400 0054 ki00.......T
00000150 6B69 3031 0000 0000 1400 017A ki01.......z
0000015C 6B69 3032 0000 0000 1E00 007B ki02.......{
00000168 6B69 3033 0000 0000 1E00 817C ki03.......|
00000174 6B69 3034 0000 0000 1600 007D ki04.......}
00000180 6B69 3035 0000 0000 1400 007E ki05.......~
0000018C 6B69 3036 0000 0000 1400 007F ki06........
00000198 6B69 3037 0000 0000 1400 0080 ki07........
000001A4 6B69 3038 0000 0000 1400 8181 ki08........
000001B0 6430 3165 0000 0000 0000 0056 d01e.......V
000001BC 6430 3365 0000 0000 0000 0059 d03e.......Y
000001C8 6430 3465 0000 0000 0000 005B d04e.......[
000001D4 6430 3565 0000 0000 0000 005D d05e.......]
000001E0 6430 3665 0000 0000 0000 005F d06e......._
000001EC 6430 3765 0000 0000 0000 0261 d07e.......a
000001F8 6C30 3265 0000 0000 0000 006F l02e.......o
00000204 6C30 3365 0000 0000 0000 0071 l03e.......q
00000210 6C30 3665 0000 0000 0000 0075 l06e.......u
0000021C 6C30 3765 0000 0000 0000 0077 l07e.......w
00000228 6C30 3865 0000 0000 0000 0079 l08e.......y
00000234 6930 3100 0000 0000 0800 01A6 i01.........
00000240 6930 3200 0000 0000 0800 01A7 i02.........
0000024C 6930 3300 0000 0000 0500 01A8 i03.........
00000258 6930 3400 0000 0000 0800 01A9 i04.........
00000264 6930 3500 0000 0000 0500 81AA i05.........
00000270 6930 3600 0000 0000 0500 01AB i06.........
0000027C 6930 3700 0000 0000 0500 81AC i07.........
00000288 6930 3800 0000 0000 0500 01AD i08.........
00000294 6930 3900 0000 0000 0500 01AE i09.........
000002A0 6931 3000 0000 0000 0500 81AF i10.........
000002AC 6931 3100 0000 0000 1E00 81B0 i11.........
000002B8 6931 3200 0000 0000 1600 81B1 i12.........
000002C4 6931 3300 0000 0000 0500 81B2 i13.........
000002D0 6B61 3039 0000 0000 6900 816C ka09....i..l
000002DC 0000 0000 0000 0000 0000 0000 ............
000002E8 0A00 0000 0100 0000 1E00 0000 ............
000002F4 0100 0000 0900 0000 0A00 0000 ............
00000300 0B00 0000 0C00 0000 0D00 0000 ............
0000030C 0E00 0000ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ....<!--c2--></div><!--ec2-->

On the flip side the differences between several of those entries are far too small to be straight pointers and I do not think we are dealing with sector based stuff here (such things are usually reserved for consoles with large media not to mention I see no padding that is all but mandatory with sector addressing). Really not sure what goes here but if you are lucky you will not have to deal with it.

I copied everything after the ka09 entry to a new file.
First section could well be pointers although it varies after a little bit from what could be 4 byte entries to 2 byte entries
With just the 2byte entries there some 350 odd in total and possibly up to 370 (the pointer format breaks down in the mid 350's into what could be shiftJIS). Messages appear to be of the short status messages (nice control codes by the way), shop messages (although I am prepared for that to be another part), save/load type messages and other getting stuff done rather than story messages which appear to be left for event.dat so amount of potential pointers vs the amount of potential entries looks good so I push forward.

Slicing off the 4 byte section leaving just the 2 byte pointers and the text
The new file ends at 1e9a hex. None of the values exceed that (at all in this case but as long as it is not too much/around that of the length of the pointer section things are usually looking good).

Interestingly the first entry appears to be 2c6 hex which is where the pointer format appeared to break down. 2cb hex (the next entry) is just after a 00.
Searching for 00 hex yields 357 results which includes some parts of the pointers (something I can put down to chance and so can ignore for now). Copying those results and lining them up against the pointers... well I will let the results speak for themselves
(the following codebox is in hex if it was not already obvious)
<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-spacere;overflow:auto'>0161
0000
02C6
02CB 0x000002CA
02DA 0x000002D9
02E7 0x000002E6
02F2 0x000002F1
0317 0x00000316
031B 0x0000031A
0320 0x0000031F
0325 0x00000324
032A 0x00000329
032F 0x0000032E
033F 0x0000033E
0364 0x00000363
0370 0x0000036F
0388 0x00000387
03B8 0x000003B7
03D2 0x000003D1
03E5 0x000003E4
0402 0x00000401
0412 0x00000411
0425 0x00000424
0434 0x00000433
0439 0x00000438
0447 0x00000446
0450 0x0000044F
0464 0x00000463
047A 0x00000479
0480 0x0000047F
0495 0x00000494
04A8 0x000004A7
04B7 0x000004B6
04C9 0x000004C8
04E5 0x000004E4
0500 0x000004FF
0516 0x00000515
053D 0x0000053C
0549 0x00000548
0569 0x00000568
0590 0x0000058F
05AA 0x000005A9
05BB 0x000005BA
05D4 0x000005D3
05EB 0x000005EA
05F9 0x000005F8
060F 0x0000060E
0613 0x00000612
0617 0x00000616
061B 0x0000061A
061F 0x0000061E
0623 0x00000622
0627 0x00000626
062B 0x0000062A
063E 0x0000063D
0651 0x00000650
0661 0x00000660
067C 0x0000067B
068D 0x0000068C
06A0 0x0000069F
06B0 0x000006AF
06C7 0x000006C6
06E9 0x000006E8
06F7 0x000006F6
0710 0x0000070F
0722 0x00000721
0746 0x00000745
0756 0x00000755
0762 0x00000761
07A3 0x000007A2
07AC 0x000007AB
07C8 0x000007C7
07D3 0x000007D2
07DF 0x000007DE
07EB 0x000007EA
07F7 0x000007F6
0804 0x00000803
0811 0x00000810
081B 0x0000081A
082E 0x0000082D
083C 0x0000083B
084A 0x00000849
0856 0x00000855
0861 0x00000860
086D 0x0000086C
0880 0x0000087F
0892 0x00000891
0899 0x00000898
08A2 0x000008A1
08B8 0x000008B7
08C9 0x000008C8
08D9 0x000008D8
08DE 0x000008DD
08F9 0x000008F8
0900 0x000008FF
0907 0x00000906
090E 0x0000090D
0914 0x00000913
091D 0x0000091C
0924 0x00000923
092B 0x0000092A
0938 0x00000937
0942 0x00000941
0949 0x00000948
0951 0x00000950
0966 0x00000965
0986 0x00000985
0998 0x00000997
09A9 0x000009A8
09B1 0x000009B0
09C2 0x000009C1
09DA 0x000009D9
09F0 0x000009EF
0A02 0x00000A01
0A26 0x00000A25
0A45 0x00000A44
0A57 0x00000A56
0A68 0x00000A67
0A81 0x00000A80
0AA0 0x00000A9F
0AAE 0x00000AAD
0AC2 0x00000AC1
0AD7 0x00000AD6
0AE4 0x00000AE3
0AF2 0x00000AF1
0B19 0x00000B18
0B28 0x00000B27
0B44 0x00000B43
0B68 0x00000B67
0B83 0x00000B82
0B97 0x00000B96
0BB1 0x00000BB0
0BC5 0x00000BC4
0BF1 0x00000BF0
0C05 0x00000C04
0C24 0x00000C23
0C35 0x00000C34
0C4B 0x00000C4A
0C53 0x00000C52
0C63 0x00000C62
0C6A 0x00000C69
0C6F 0x00000C6E
0C78 0x00000C77
0C7F 0x00000C7E
0C88 0x00000C87
0CA9 0x00000CA8
0CAE 0x00000CAD
0CB1 0x00000CB0
0CBA 0x00000CB9
0CBF 0x00000CBE
0CCA 0x00000CC9
0CD9 0x00000CD8
0CDE 0x00000CDD
0CE5 0x00000CE4
0CEC 0x00000CEB
0CF5 0x00000CF4
0CFE 0x00000CFD
0D07 0x00000D06
0D0A 0x00000D09
0D10 0x00000D0F
0D23 0x00000D22
0D2E 0x00000D2D
0D35 0x00000D34
0D3A 0x00000D39
0D3F 0x00000D3E
0D43 0x00000D42
0D50 0x00000D4F
0D59 0x00000D58
0D66 0x00000D65
0D77 0x00000D76
0D84 0x00000D83
0D8F 0x00000D8E
0DA2 0x00000DA1
0DB5 0x00000DB4
0DC8 0x00000DC7
0DD1 0x00000DD0
0DDA 0x00000DD9
0DED 0x00000DEC
0DFA 0x00000DF9
0E07 0x00000E06
0E18 0x00000E17
0E29 0x00000E28
0E38 0x00000E37
0E45 0x00000E44
0E5E 0x00000E5D
0E68 0x00000E67
0E79 0x00000E78
0E92 0x00000E91
0EBA 0x00000EB9
0EE2 0x00000EE1
0F01 0x00000F00
0F12 0x00000F11
0F18 0x00000F17
0F21 0x00000F20
0F2A 0x00000F29
0F41 0x00000F40
0F54 0x00000F53
0F67 0x00000F66
0F7D 0x00000F7C
0F83 0x00000F82
0F94 0x00000F93
0F9B 0x00000F9A
0FA0 0x00000F9F
0FAA 0x00000FA9
0FB0 0x00000FAF
0FBA 0x00000FB9
0FBC 0x00000FBB
0FC1 0x00000FC0
0FD5 0x00000FD4
0FE4 0x00000FE3
0FED 0x00000FEC
0FF2 0x00000FF1
0FFF 0x00000FFE
1005 0x00001004
1014 0x00001013
101B 0x0000101A
1028 0x00001027
1038 0x00001037
1047 0x00001046
105A 0x00001059
106D 0x0000106C
1078 0x00001077
1085 0x00001084
1092 0x00001091
109D 0x0000109C
10B2 0x000010B1
10C4 0x000010C3
10C9 0x000010C8
10CD 0x000010CC
10D6 0x000010D5
10DC 0x000010DB
10F8 0x000010F7
10FC 0x000010FB
1105 0x00001104
110B 0x0000110A
1115 0x00001114
1121 0x00001120
1127 0x00001126
1130 0x0000112F
1137 0x00001136
113C 0x0000113B
1145 0x00001144
114B 0x0000114A
1155 0x00001154
1160 0x0000115F
1168 0x00001167
1175 0x00001174
1193 0x00001192
11D8 0x000011D7
1208 0x00001207
123D 0x0000123C
125D 0x0000125C
1298 0x00001297
12BE 0x000012BD
12C6 0x000012C5
1301 0x00001300
132B 0x0000132A
136C 0x0000136B
137F 0x0000137E
1398 0x00001397
13BE 0x000013BD
13D3 0x000013D2
13E8 0x000013E7
1401 0x00001400
1427 0x00001426
143A 0x00001439
144F 0x0000144E
1479 0x00001478
14A3 0x000014A2
14CD 0x000014CC
14E4 0x000014E3
151F 0x0000151E
1569 0x00001568
159D 0x0000159C
15B9 0x000015B8
15D9 0x000015D8
15FA 0x000015F9
1604 0x00001603
1624 0x00001623
1646 0x00001645
1670 0x0000166F
1685 0x00001684
169E 0x0000169D
16BC 0x000016BB
16D5 0x000016D4
16F0 0x000016EF
170D 0x0000170C
172D 0x0000172C
1748 0x00001747
175E 0x0000175D
1780 0x0000177F
17A2 0x000017A1
17C4 0x000017C3
17D2 0x000017D1
17E0 0x000017DF
17E3 0x000017E2
17EA 0x000017E9
17F3 0x000017F2
17FD 0x000017FC
181A 0x00001819
183A 0x00001839
184B 0x0000184A
1852 0x00001851
1859 0x00001858
1860 0x0000185F
1867 0x00001866
187B 0x0000187A
1892 0x00001891
18BB 0x000018BA
18D4 0x000018D3
192D 0x0000192C
1985 0x00001984
19BE 0x000019BD
19DA 0x000019D9
1A21 0x00001A20
1A48 0x00001A47
1A61 0x00001A60
1A76 0x00001A75
1A8C 0x00001A8B
1AA9 0x00001AA8
1AB6 0x00001AB5
1AC6 0x00001AC5
1AD0 0x00001ACF
1ADB 0x00001ADA
1AFC 0x00001AFB
1B16 0x00001B15
1B1D 0x00001B1C
1B23 0x00001B22
1B29 0x00001B28
1B49 0x00001B48
1B7E 0x00001B7D
1BBE 0x00001BBD
1BE9 0x00001BE8
1C05 0x00001C04
1C2C 0x00001C2B
1C60 0x00001C5F
1C9B 0x00001C9A
1CAA 0x00001CA9
1CCC 0x00001CCB
1CD6 0x00001CD5
1D09 0x00001D08
1D1B 0x00001D1A
1D37 0x00001D36
1D54 0x00001D53
1D76 0x00001D75
1D9A 0x00001D99
1DBD 0x00001DBC
1DE0 0x00001DDF
1E05 0x00001E04
1E29 0x00001E28
1E2E 0x00001E2D
1E4E 0x00001E4D
1E6F 0x00001E6E
1E78 0x00001E77
1E88 0x00001E87
0x00001E9B
</div>
(I checked and they are spot on all the way through)

You already know the text is ascii (I have not checked to see if the rest is in fact shiftJIS but I rarely see that many 8 characters unless I am playing GBA hacker), the control codes are not too hard to figure out and here at least I am not seeing many new line commands (the odd 0a hex buried within the text seems to do it- it is a common enough new line (technically it means line feed) command as unix type operating systems tend to favour it although windows typically uses 0d0a hex and macs historically at least favoured just 0d hex so be careful if using a simple text editor at some point).
It should be noted I have not touched upon the overall .dat format (that character name hex dump up above had some stuff before it) but you should be good as all the fixed length stuff appears before the pointer style text so at worst you just need to find how it stores the file length).

event.dat now. I am looking at the file as a whole until otherwise stated.
Starts with a name list although entries appear to be 16 bytes a piece and not all that organised at the start. Looking at the ASCII that is either a lot of control codes or some form of compression but I will ignore that for now.
Looking around there are lot of b??? characters seemingly at the starts of sections so a search for b0 in ascii nets some 80 odd results.
Likewise with msn there are 150 odd although they sometimes repeat, have minor tweaks (msn??a msn??b and so forth) or at not surrounding sections- 115 is the highest number I see at a glance and it skips a few here and there not to mention does not always count up).
Both way too numerous for the 16 byte entries at the start.
The whole file is 018b3c hex long (just before that there is scnend - scene end perhaps?) which makes simple pointers like before still more than possible but more than 16 bits (probably all the way up to 32 bit).


There seem to be large sections and smaller sections.
The larger ones have some section breaks of some form along the lines of bk??? along the lines of bkA01, bkA02, bkB01, bkB02, bkK01 (these are from the first three large msn sections- next is M, then L, then C

Large and small often end with 0c00 or occasionally 2c00 , the 0c part might be coincidence though (still 375 of them).

Notable strings (?= "random" numbers and >= "random" letters)
msn??? and msn???>
m???
b???
bk>??
G???


Order is often
msn???
G???

I also see a dsn which may be battle messages of some form.

0A makes a return presumably as a new line. ShiftJIS (if indeed it is that) might be back.

I am not admitting defeat just yet but I am admitting 1am. No fear guess has it as sections pointed at, plain text written from then on with possibly some values in a header somewhere as to their length although it might be a simple dump it in ram, maybe parse it (the bk stuff) and run it affair which would be nice. It might also be a proper script interpreter ( <a href="http://gbatemp.net/index.php?showtopic=296759&hl=" target="_blank">http://gbatemp.net/index.php?showtopic=296759&hl=</a> ) which I truly hope it is not for your sake but if it is my intellectual curiosity gets a new toy.