.pac files help

Discussion in 'NDS - ROM Hacking and Translations' started by Leeg, Jul 11, 2011.

Jul 11, 2011

.pac files help by Leeg at 3:23 PM (9,396 Views / 0 Likes) 61 replies

  1. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009

    I was interested in translating this:
    (The wizard of Oz: Beyond the yellow brick road)

    but it happens that all files are .pac compressed and I have no idea on how to uncompress them. I've tried using crystal tile 2 and reading its tutorial from this site but I can't manage to extract anything at all [​IMG]

    Any help?


  2. Naxito

    Newcomer Naxito Advanced Member

    May 14, 2008
    Can you upload any file?
  3. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009
  4. Naxito

    Newcomer Naxito Advanced Member

    May 14, 2008
    It's easy. Title.pac containe a ncgr and nclr file (maybe more, i dunno). This compressed LZ77.


  5. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009

    How do you open that? I have that program too but I can't manage to get that image
  6. FAST6191

    Reporter FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    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.
    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

    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)
    00000000 0102 0300 0000 0000 4080 0000 2802 0000 ........@...(...
    00000010 2408 0000 0000 0000 0000 0000 0000 0000 $...............
    00000020 0000 0000 0000 0000ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ........
    That does little so a bit of tweaking and a byte flip gives

    00000000 0003 0201 ....
    00000004 0000 0000 ....
    00000008 0000 8040 ...@
    0000000C 0000 0228 ...(
    00000010 0000 0824 ...$
    00000014 0000 0000 ....
    00000018 0000 0000 ....
    0000001C 0000 0000 ....
    00000020 0000 0000 ....
    00000024 0000 0000 ....

    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

    8040 (the length of the NCGR file)

    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
  7. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009
    Wow FAST6191 !

    Thanks a lot, it was quite well explained, I appreciate it, seriously, thanks thanks !!
  8. Naxito

    Newcomer Naxito Advanced Member

    May 14, 2008
    As always, great explanation
  9. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009
    I'd like to ask question about fonts and translating!

    I've added some new characters as " á é í ó ú ¿ ¡ ñ Á É Í Ó Ú ". To do so, I replaced japanese ones. everything went Ok. The problem is that when I want to use them in the text file, I have to place their HEX and they occupy 4 digits. I mean...

    for instance:

    ñ is 829f

    And if I want to add it to the editor...


    I have to waste 4 digits... which means that I'll probably run out of room every time :S

    Am I doing something wrong? Are there any other ways of doing this?

    And also I'd like to know how can I solve "out of room" problems, I mean, not having enough space to add words... :S

  10. shadowmanwkp

    Member shadowmanwkp Your roms are on another rom site

    Apr 17, 2008
    Vleuten, The Netherlands
    There are two ways to translate a game:
    1. You fit the text into the space given by the original game. In other words, you try to use the same amounts of characters the original text used
    2. You fully alter it so the script fits into the rom, thus it is only limited by the rom size, and the blank bits left.

    What you're doing is a prime example of the first way. You fit the translation into the space of the original. If you analyze the file a bit further and after doing a bit of trial and error, you will find some values that repeat themselves. A prime example is the line end value, which denotes a next line. Do note though that in some cases the value is different depending on the way the game is structured (if I'm not mistaken, one of the zelda nes games did this). If you experiment a bit, you will certainly figure it out. But it may take a long time to do so.

    Another thing to do is practicing on easier games first. A nes game is a lot less complicated than a ds game, but you do get more experienced by translating one. Nes games are also a lot better documented, so you will dig up a lot more info on the games than a ds game, thus you will get stuck less often.

    If you're interested in all this, I'd really recommend looking at this site: Romhacking.net
    It has a lot of tools that come in handy while hacking, but it also has a lot of tutorials on the basics of rom hacking. And to be frank, you can get a lot more support on the forum over there regarding rom hacking than over here.
  11. FAST6191

    Reporter FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    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.
  12. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009
    Thanks again FAST6191!

    I don't know if I understood everything but it was useful for sure [​IMG]

    I wanted to ask anybody to check another two files, since I can't open any of the files located inside the rom (except the title from the first post).

    For instance, this:


    It's bkE01.ntf, there are a lot of bkXXX.ntf in the rom, I've discovered that these are images displayed in the top screen (they're called from event.dat so I tried changing one of them and it worked). But I can't open any of these files in any editor.


    This is ui_Tutorial01.pac, I assume is an image displayed in the top screen in the tutorial part of the game, it's .pac, so I've tried using the same method as title.pac, but it didn't work...

    Any idea on this?

    Thanks [​IMG]
  13. FAST6191

    Reporter FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    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.

    00000008 0000 1840 ...@
    0000000C 0000 0228 ...(
    00000010 0000 0824 ...$
    To make life easier though the output of a crude spreadsheet I knocked together.

    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).
  14. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009
    Thanks thanks thanks [​IMG]

    Now I've understood the process completely [​IMG] I can open them all thanks seriously !!

    You've made my day ^^
  15. Naxito

    Newcomer Naxito Advanced Member

    May 14, 2008
    FAST, .ntf palette start at 0x4
  16. FAST6191

    Reporter FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    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.
  17. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009
    Any good method to edit them in photoshop and then import them again? I've tried something but the palette spoils the file when it is added to the rom.
  18. FAST6191

    Reporter FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    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
  19. Leeg

    Newcomer Leeg Advanced Member

    May 29, 2009
    Oh god, in the end I could do it perfectly with photoshop omg:

    I extracted the palette with CT2.
    Then I edited the file, and indexed it with photoshop, when indexing I used Custom settings and imported the palette... then in CT2 I imported the image to the file, double click it and voila...


    Thanks again ^^
  20. FAST6191

    Reporter FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    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

    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-space:Pre;overflow:auto'>0161
    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
    (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???>

    Order is often

    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.

Share This Page