Well...there's one other option.

VBA-SDL-H.

You'll need some familiarity with the use of the command line, so what you want to do is unzip VBA-SDL-H to its own directory and, for simplicity's sake, copy the ROM into the same folder.

Go to Start/Programs/Accessories and select Command Prompt (or alternately hit Start/Run, type "command" in the box and hit "OK"). Type "cd" followed by the path you unzipped VBA-SDL-H to: for example, if you unzipped it to "c:\\projects\\vba", you'd type "cd c:\\projects\\vba" and hit enter.

Now type "vba-sdl-h name-of-rom-here.gba" (in this case, it would be "vba-sdl-h nob-chan.gba") and press enter. The emulator should start up. Wait until the last screen before the title screen appears, then press F11 to bring up the command prompt. Type "bpw 06000000 1" in the command prompt, then press enter again. (You've just set a write breakpoint - "breakpoint write", get it? - on the start of VRAM, where the title screen data is loaded to.) Type "c" and then press enter to continue emulation. The emulator should pause and bring up the command prompt again before the title screen appears. The command prompt will display a list of registers, numbered "r0" to "r15": most of the information won't be of any help, but one of the registers from r0 to r7 should be "06000000", and another should be "08XXXXXX" (in other words, an eight-digit hex number beginning with "08"). Ignore r14 and r15, though: those are just the return register and program counter. Make note of everything after the "08" and check the corresponding address in Tile Molester: if one of the registers is "08615B70", for instance, you scroll to 615B70 in the ROM. If multiple registers match the "08XXXXXX" pattern, check them all (except r14 and r15!) until you find the graphics data.

I know that's a pretty long-winded exposition, but hopefully it should help.

Should've mentioned this before: in THUMB mode (16-bit instructions, which most GBA programming is done in), only r0-r7 are used. On a side note, if you hit c to continue, does it break a second time, or does it display the title screen? (You should test this before you continue.)

The addresses in r5, r6 and r7 are memory addresses, a foreboding portent. Since it's not being copied directly from the ROM, it's possible that it could be compressed (though by no means guaranteed). Try "bt 801dcbc"""; this will set an execution breakpoint for the command above the "strh r2, [r3, #0x0]". This will hopefully catch the instruction that loads the byte stored to VRAM and tell us which register is being used as the source address.

ASM lesson: "strh" is "store halfword", a halfword being two bytes: this particular one stores the value in r2 to the address indicated by r3 offset by 0 - in other words, not offset at all. So right now it writes r2 to 06000000, the address specified by r3, which also happens to be the start of VRAM. The next instruction is "add r3, #0x2", or "add 2 to r3". In other words, it increments the address so that the next two-byte halfword gets written to its appropriate place in VRAM. Next is "mov r9, r3", which is "move r3 into r9", copying r3's value into r9 for some other purpose that is probably beyond the scope of our work here.

Does it break at the same instruction every time? How many times does it break before the title screen is displayed?

So it only breaks twice, hmm? I.e., it only writes to 06000000 twice before displaying the title screen?

The second one is the one you want. Check the registers (r0-r7) like you did the last time and see if anything useful comes up.

Well, crappity.

Unless you have some serious programming skills you have yet to mention to me, KC's right: you won't be able to do anything to the title screen without tracing the ASM code, figuring out how the compression works, coding your own functionally-identical decompressor (this part's easy), and finally coding your own equivalent recompressor (this part's hell).

Even if the case is already sort of resolved by chosing another game, I'd like to point out that a much easier way is usually just to bypass the original compression. You can get the decompressed graphics straight out of VRAM directly and then load it uncompressed or use the BIOS built in functions. Recompressing with the original algorithmn is usually a waste of time IMO unless you are really hard pressed on every byte of space. (And even then it's worth trying to get comparable results with the Bios compressions).

You're in luck. A friend of mine recently asked for me to search exactly for those graphics you're trying to search and find in NFS Carbon.

I've found it in the rom. Luckily, it's not compressed. Using Tile Molester, go to offset 0x1DEEE8 and try "8bpp linear" codec, "2-dimensional" mode, and try adjusting tile width using SHIFT + LEFT / RIGHT. With the right tile adjusting and palette, you can edit it.

Take a look:

http://img209.imageshack.us/my.php?image=carac3.png
http://img231.imageshack.us/my.php?image=tilejx6.jpg

It's a bit difficult edit it this way, but isn't impossible. I was able to edit "Press Start" graphic inclining the image 65º in anticlockwise direction.

You still can find other uncompressed graphics down in the rom. all in big codecs (link 15 or 16bpp). probably graphics used in car textures or tracks.

I suspect you're trying to translate this game for your native language, which isn't english. Relying on it, if there's some crucial graphic you wish to edit in order to make a 100% translation to your language, it's those flags graphics. probably it's compressed.

1. Take a look here:
http://www.romhacking.net/forum/index.php/topic,2634.0.html
and here:
http://www.romhacking.net/forum/index.php/topic,5426.15.html
you'll surely find useful ways for extracting palettes from GBA games and import them in tile molester.

2. Nope. You don't have to convert anything. this is the memory address. in hexadecimal. just copy&paste it in "Navigate > Goto", with checked on Hex and Absolute. It'll go directly to the address specified