This thread (which I guess is the first one I made around here) is mainly to share something interesting I found when pulling apart the US version of the rom "The Wizard of Oz: Beyond the Yellow Brick Road" (gameplay video http://www.youtube.com/watch?v=rnOf4S31ZyU ). It started with a simple reversing of a file format but the engine then got involved in the text as well which got this. Thread on the matter here http://gbatemp.net/index.php?showtopic=300953&hl= (it is something of a notebook so it might not read so well).
First was the .pac file which appeared to be an archive format (standard "type 10" GBA/DS LZ across the whole .pac file) using lengths rather than standard pointers (I later looked at some other files that contained fewer files and those initial bytes looked to be ordinals of a sort). Note this does make it different to the previously documented .pac file ( http://www.romhacking.net/docs/541/ ) although I am going to call a generic extension affair (think .bin) as it does not look like a mod of the format or the initial reversing engineering efforts did not have all the options (see history of the NARC reverse engineering efforts).
Inside those are your standard SDK formats ( http://www.romhacking.net/docs/%5B469%5Dnds_formats.htm ) with 3d (NSBMD and co), nftr fonts and a minor tweak on the NTF? graphics format (treated as a large tile@256x192 with palette, tiles and map all packed into a single file with the odd bit of padding) all swimming around in there..... stuff you usually end up seeing if you move in DS circles for any length of time.
default_data.dat has a bunch of fixed length sections (although said fixed length could vary between them) which is interesting I guess as you rarely see them that long and outside of various menus followed by some standard offset pointers.
Then a handful of other files that might be of passing interest (some nice xml type stuff/developer left extra) but event.dat is where it got interesting as the game then appears to switch to a sort of binary scripting language (anything but turing complete as far as I can see) that controls graphics, text and some aspects of game logic, loses all pointers in favour of length values contained within the commands/sections themselves (and although binary has values in the left most byte) and does have a slightly odd character parsing method (ascii and shiftJIS but the shiftJIS does not have to be 16 bit aligned with some shiftJIS used in the English sections for various things (mainly punctuation))
A more complete workup on the initial link but commands seem to range from 00(00) (although that might be a NOP of sorts) to the mid 10(00) range (counting in hex) at least.
Format is
??00 YY00 [payload] where ?? is the command and has a value between between 00 and about 15 hex (0300 is the command for text for instance although that has some padding in the size value by the looks of things even if I have not seen the size break out of the 00-FF range), YY is the length in bytes of the section (command and size included) and [payload] is just as it says (obviously varies with command). Everything is end to end.

It is rare enough I see something other than fixed, standard or relative pointers let alone something like this. Now simple markup and basic scripting (see some of the stuff done for Furigana in the first DS Zelda) is nothing major but proper scripting is usually something we tend to only see on big consoles ( http://blog.delroth.net/2011/06/reverse-engineering-a-wii-game-script-interpreter-part-1/ ) so I thought I would share (if for no other reason than to see others that have fought against pointers over the years have to shake their heads). It might also make a half decent candidate for a total conversion hack (although there are several others I would place ahead of it/that have some similar characteristics) although I should note the binary houses a few files and strings as well by the looks of things which you might have to tangle with if you do head down that path.