To save this getting buried in PMs I will post it here. Apologies for my "thought process" type pulling apart of the file rather than a straight up format assessment.
If you have the rom evet.pkb and mcht.pkb seem to be the files of choice.
10 at the start of the file usually indicates type 10 compression (one of the traditional DS compression schemes), I fired it through
http://code.google.com/p/dsdecmp/ and it spat out the header sections of each file in something resembling a traditional DS header
It started out with the true length of the header in the case of mcht it had 78 which was the end of the last name in the small sub entry.
Decoding from the next 10 marking did little (I think it might have been a coincidence) other than stall the program.
Decoding from the one after that netted a more complete file map (the first value is 6801 or read as the DS would 0168 which is the end of the section again.
Decoding from the one after that gained me a small text 13 kb dump (largely in ASCII- no unicode which is odd for a game like this unless it uses proper unicode and not the U16 (forced 16 bit) most of us see) and it ends with something similar to that old header.
J04.SAD gmdn_v00 and the like. The text itself seems to be a flawless dump (only the new line marker and what appear to be variable (you have X money and the like) the text might be using prevent it from being a standard text file- not traces of a bad decompression (if you force it most LZ decompressors will decode any other LZ but it will not be a nice result). No text pointers though and it starts with 2430 (3024 as the DS might read it) which is the end of the whole decompressed section (including the odd header thing). I sense I am not here to pull apart a text format and as the table is simple enough so that is left for others to ponder.
Some of the things at the end of the initial mcht.pkb file are seemingly not compressed as well.
Looking at some of the headers more closely, between the names exists other data. Looking my second successful decompression
0000 5401 0200 1400 0000 comes before J04.SAD and
0000 5701 0200 1400 0000 comes before gmdn_v00
Traditionally it seems lengths and the like come before names. There are also some 0000's before and after each of those, you can usually ignore them but occasionally if you are dealing with big files they are important to keep proper locations and file sizes* and some things use them for other useful bits of data (a flag to say whether a file is compressed for instance).
0154 and 0157 are fairly obvious guesses for things although what there are is up in the air at this point (sizes maybe)
*kind of like how I reversed 6801 when just starting to pull things apart. A minute ago- a bigger file might have actually used a later byte or two and thus I would have got it wrong and if something like 6801 1000 was written I would have mistakenly decoded it as 0168 0010 when I needed to write 0010 0168
The 0200 1400 part appears to be repeated throughout the header part although as they are all the same sort of filename (and presumably format) that is not surprising. They might be compression flags or flags to tell the decompressor or game where to look for choice bits of data on the file- the only part in which they change is for the Kicker= %d and "GK " (four spaces maybe used as padding- a 6 character limit/fixed length string perhaps?) part in which they are 0100 1400. This is less important for translation though if you are making a game enhancement or using the engine to build another game you will almost certainly need to figure it out.
In order from the start the "size" values list as
EE00
F000
5701
5901
6201
6501
6d01
7001
8001
8301
8E01
9101
9901
9C01
A701
AA01
B101
B401
The "counting up in 3" parts some of that list seems to enjoy I can not ignore- it makes it considerably less likely to be a size value (file sizes neatly going up in values of 3- not likely unless it is a simple padded/restricted affair) and it only going up 3 at a time makes it less likely to be a direct pointer value (file sizes of 3- equally unlikely if not pointless- you would make a whole file and 3 is not a nice length to feed a processor) so it is more likely a reference value (games do not need nice ASCII names- short numbers will do just as well if not better) or a pointer to a pointer (there might be some other table somewhere with. and the other thing I do not like about calling it size is that
J04.SAD is repeated a few times and then J05.SAD is used. Not sure what this means although each instance of J04.SAD has its own "reference" value.
Now this 13K dump makes life a bit more difficult as I can no longer just scroll down and pick out the next file and just searching for 10 again is not likely to be that effective. Compressing the file (using codec LZSS-
http://gbatemp.net/index.php?showtopic=274472&hl= ) compresses the file down to about 6KB (not bad for an ASCII file) or more importantly 17CB long.
17CB in the mcht has nothing much but on the screen at about 1500 is fluff.y (obviously a compressed version of fluffy), scrolling through the script and keeping an eye on the new compressed script that is right near the end though.
Sure enough at 188B there is a g.mdn part (remember the odd header like thing at the end of the text dump)
At 18B0 is another 10 flag, deleting all that came before it and firing the new file through the dsdecmp again
A nice 7KB file results. ASCII like before, starts with 8419, ends at 1988 and the 1984 part is the tail end of the %d (it is another repeat of the header part at the end by the way).
On the header repeats though this file has header like data interspersed through the file (more towards the end though but it starts with a file name like thing)- these extractions have subfiles as well - the initial pkb files are archives, these contain files which are also archives?
Far from unheard of in the DS world (NARC files do it all the time, SDAT or more accurately the sample files are built for it) and there are entire roms that layer custom file systems on top of the nitrofs (the thing all known roms use and we use stuff like nstool/ndsts/nitro explorer/crystaltile2 to pull apart). Speaking of crystaltile2 I should really fire these files through the compression search of that program.
Also our old friend 0200 1400 returns.
10D0 marks what I want to call the second subfile (or more accurately the start of the "J04.SAD" string. 114C the next. 11EC the one after that. 1418 the one after that. I would not place too much stock in their actual values/locations (if nothing else because we still do not know if they are indeed true file starts - they do however appear at fixed points relative to others- how many times do you latch onto 00 as the end of a line where in fact the line ends a fixed distance away) but the differences between the numbers (or indeed simple rough order of magnitude between points) have cracked more that a few obtuse pointer systems for people over the years. I am way too lazy to make a spreadsheet right now. 114C- 10D0 = 7C , EC-4C= A0 and 1418 take 11EC is 22C
You would also want to look at amount of files and try to find a location with a similar amount of pointers (no point trying to find 2000 pointers in a 10 byte file for instance).
Feeding it back into the compression tool I get the file back as E13 in length.
Sure enough at E20 (it seems this game opts of for a bit of padding/alignment) is another 10 and the start of some more compression (it gets partway readable again and deteriorates). There are far too many instances of 10 to try a simple search. The section of what appear to be uncompressed files (or at least files small enough to render compression ineffective- there still appears to be a few hallmarks of compression in them) starts at 0003 BB90 (hex obviously, from my editor so no need to flip).
It should also be noted when DSdecmp errors out it provides a point at which it errors out. Given I have fed it sliced up files it is not immediately useful but
INPOS = 83c (this made the intial header)
INPOS = 50 (this might be the
In between this is where I got the stall.
INPOS = 90 (this made the slightly bigger header)
INPOS = 17d0 (this made the text dump)- this matches exactly with the next compressed file.
Obviously all this has ignored the evet.pkb file- it appears to be the same format for the most part. However it is now 3:30am so I am going to pass on pulling it apart more for now. Likewise I have other commitments (I probably could have done some hacks I have had hanging over me in the time I just spent on this- no worries though as pulling something apart is far more fun that repointing/tweaking yet another SDAT file) so I am not sure if I will be able to return to this any time soon. Hopefully this is enough to dump the text and start work on reversing the file format so as to put it back in. Your first real challenge is to figure out pointers for the format- exception handling is not really done in programs like this (self contained programs with no user input so to speak- pressing A a few times is nothing compared to user entered data like a database or something) so it will probably be done with pointers. That is far from 100% though and there may be a simple "trick" of compression or end of file flag (or padding abused as a flag) I am overlooking- this might mean digging around in ASM but as long as you are following what goes and not needing to make a entirely new routine or alter an existing one beyond sticking a new pointer in there somewhere it should not be that bad.