Hardware Dumping images from GBA games

TimzUneeverse

Member
OP
Newcomer
Joined
Mar 4, 2019
Messages
10
Trophies
0
Age
20
XP
115
Country
United States
Hello. I'm trying to dump images from the GBA version of Nicktoons Racing, which I'm gonna need for the Japanese translation. Can you please provide me with some tools that are helpful?
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,338
Trophies
3
XP
27,277
Country
United Kingdom
That is just dumping them. The OP is more after getting graphics from the game.

Anyway I go long in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ if you want.

Generally though there will be four approaches to grabbing graphics.

1) Emulator ripping.
VBA and no$gba debug and many other emulators will have a tile viewer in them (sometimes OAM viewer or BG viewer depending upon what aspect of the hardware the game uses). It will show the graphics loaded in the memory at present, with colours (or at least a slider to choose from).
If people are just making sprite sheets then they will tend to start out with this. You can also use cheats to help with this -- want the sprite to an end game sword or something? Why bother playing to the end game when you can just make an inventory cheat.

2) Simple graphics hunt. Open ROM in tile editor. Set to one of the GBA modes. Press page down until you see something. Repeat for various other GBA modes (technically there are two, though a type of simplistic compression means there are three) and tile sizes (it does not get quite as fun as the DS but there are means to have custom tile sizes). You can try to narrow it down a bit if you know something else

3) Searching for compression. Not all games use it but the GBA has a few different compression formats its BIOS knows about and games can use. It has a telltale signature which some tools can search for (several detailed in the documents I linked at the start). Others will have their emulator log all such calls and feed that log to a program.
Somewhat related is pointer searching. I usually use it for text as there are a few things that make spotting text pointers a bit easier but graphics are still a possibility here. The GBA ROM is visible in memory in various places. Most games however only use the 08000000 through 09FFFFFF window, and as most games are 16 megs or less then it is only the 08000000 through 08FFFFFF window*. Search the ROM for 08. If you get a result back where 08 is found mostly a fixed distance apart** then it is probably a pointer section. What those pointers point at is anybody's guess until you figure it out (could be text, could be music, could be levels, could be stat tables... and, or course, could also be graphics.

*if you do happen to want the extra 16 megs for your translation or something then it is simply a matter of changing the pointers that originally located the stuff you want to somewhere in the 09 region. Expanding GBA ROMs is trivial compared to a lot of older systems and there is no need to mess with headers or anything like that.

**many times they will be end to end, other times there will be things in the middle or some extra padding. Similarly 08080808 is a perfectly valid pointer (indeed having another 08 in there somewhere is more probable than some other numbers) so don't assume it absolutely has to be that fixed distance, just mostly is or could be viewed to be.

4) Tracing and more active methods. The most basic form is grabbing the data from 1) and searching for that in the ROM. Everything else will tend to be around it. Obviously if it is compressed then that gets harder, and some things will be a bit more dynamic so that also gets harder.
I would not necessarily suggest it for this sort of thing but you also have corruption -- corrupt part of the ROM, run it and whatever is now broken is likely what you corrupted.
After that comes big boy tracing. https://www.romhacking.net/documents/361/ is another guide to it, I have something similar in the docs above too. However you can skip vba-sdl-h if you want as no$gba debug version is free these days. The principle is the same whatever system you are playing with though, never mind two emulators of the same system. Again you can also use cheats and cheat making techniques to help narrow it down for you, as well as more basic hacking techniques.
Said principle generally runs you find what you want in memory and when it gets loaded in there (typically it will be between one menu and another, or one game mode and another -- the GBA has a whopping 32 kilobytes of sprite space most of the time so things tend to be cycled in and out http://pineight.com/gba/managing-sprite-vram.txt ) and set the debug emulator (usually via a break on write aka bpw (breakpoint write) or log on write) to tell you when that memory area was fiddled with. If it is a break on write then it will stop the game, tell you what is happening at that point and the last however many instructions. If one of those is a memory read, DMA read, BIOS compression read or similar to the ROM then you have it, if it from RAM then you might have a compression function to handle first but go back through that and you will end up in the ROM eventually.
 
  • Like
Reactions: Alexander1970
General chit-chat
Help Users
  • No one is chatting at the moment.
    Skelletonike @ Skelletonike: