Author
|
Topic: Tracing through SWIs with VBA-SDL-H (Read 641 times)
|
Spikeman
Guest
|
 |
« on: December 07, 2006, 09:40:32 pm » |
|
I'm trying to find the compressed title screen graphics for my project (Rockman.EXE 4.5), and by using breakpoints to read when it writes to the VRAM, I've found that whatever loads the graphics and stuff does so inside a SWI (0C, if that matter)..
The problem is I have no idea how to trace through that SWI call, or even find the code that it goes too. Any tips?
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #1 on: December 07, 2006, 09:59:15 pm » |
|
SWI is a BIOS function call. What you're looking at is similar in principle to DMA transfers on the SNES, only signposted more clearly.
What you should be interested in is not the SWI, but what comes before it. Unlike a SNES DMA call, the registers themselves contain the source/dest values and et cetera.
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #2 on: December 07, 2006, 10:04:06 pm » |
|
All right, what registers should I be interested in?
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #3 on: December 07, 2006, 10:12:32 pm » |
|
Depends on the SWI. Each SWI value ("SWI $0B", "SWI $0C", etc.) calls a different BIOS function with different register arguments. I don't remember the details, but the info should be easy enough to dig up.
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #4 on: December 07, 2006, 10:31:59 pm » |
|
Oh okay, I'll let you know if I have any success.
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #5 on: December 08, 2006, 12:31:58 am » |
|
I found out that the SWI the game is calling copies a chunk of memory from one place to another. I set a breakpoint on the specific memory I thought it was and kept pressing "c" until I found the one that wrote to 6000000 (where the screen's loaded in VRAM). This is a summary of the calls around that: 30076e4>3000000
30076b8>6000000
30076b8>6004000
30076b8>6008000
30076b8>600c000
8607f58>600d800
8607f38>3002c30
607f58 in the ROM turned out to be the font, probably the text that says "PRESS START". I'm really confused, do I need to log all these SWI commands to a file and sift through them all until I find the right one?  |
|
|
|
|
Ryusui
Guest
|
|
« Reply #6 on: December 08, 2006, 01:50:12 am » |
|
Apologies, I managed to completely miss the question. ^_^;
All right, I'm assuming the game doesn't use the BIOS' LZ compression, right? If that's the case, the SWI you're looking at is the tail end of the process: the graphics are likely being extracted to somewhere in memory before being copied to VRAM.
What you want to do is BPW for where the title screen is extracted to in normal RAM (you should be able to figure out the address by performing a memory dump in vanilla VBA and loading it in GBA format in TLP or Tile Molestor). That should lead you straight to the compression routine, and from there to the address of the compressed title graphics.
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #7 on: December 08, 2006, 02:21:37 am » |
|
I don't think that it uses the BIOS LZ routine, because I couldn't find the graphic in unlz-gba..
Anyways, I managed to find the graphics, but in a different way. I did a bpw on 6000000, and found that data was copied from 201c004. I then did a bpw on that and found data being copied to it from several places around 87cea94 (that's the first place loaded into 201c004). I looked around there in unlz-gba (I still thought it was LZ), and got something, but when I edited it, it distorted the whole screen in such a way that it probably isn't LZ, or at least not the BIOS version. Since I know kind of where the graphics are what should I do? I have no idea what compression it uses or even exactly where the graphics are.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #8 on: December 08, 2006, 02:42:04 am » |
|
Congrats, that's actually what I just told you to do. ^_^;
From the sounds of things, the compressed data begins at 87CEA94; trace the routine and get an idea of what it does. Most graphics compression seems to use some form of LZ; the specifics may vary, but the basic form of the routine is pairs of compression codes denoting a length of bytes to copy and the relative distance backwards to copy from. There should also be some mechanism for determining which bytes are "plaintext" and which are compression codes.
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #9 on: December 08, 2006, 02:53:38 am » |
|
Oh and one thing I'm still a bit confused about: How do I know if it's even compressed? Are there any utilities to view/edit graphics with 256 colors for GBA? As far as I know TLP doesn't support 256 colors.. I want to make sure it's compressed before trying to search for a compression routine.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #10 on: December 09, 2006, 04:59:40 am » |
|
Tile Molestor supports 256-color graphics.
An easy litmus test would simply be to dump the uncompressed graphics from the game in progress (use VBA for this), open it in a hex editor and search for a particular byte sequence from it in the ROM. If you search and nothing comes up, the graphics are compressed.
Surprisingly, the title screen for Sylvanian Families 4 is uncompressed, so it's not impossible.
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #11 on: December 09, 2006, 03:56:15 pm » |
|
An easy litmus test would simply be to dump the uncompressed graphics from the game in progress (use VBA for this), open it in a hex editor and search for a particular byte sequence from it in the ROM. If you search and nothing comes up, the graphics are compressed.
I'm pretty sure I tried that and couldn't find anything, put that was back when I was pretty new at Rom hacking, now I know that the title screen is tiled, so maybe I'll try dumping the tile data and searching for it. I'll also check out Tile Molester. Thanks for all your help! |
|
|
|
|
Ryusui
Guest
|
|
« Reply #12 on: December 09, 2006, 05:40:49 pm » |
|
I'm pretty sure I tried that and couldn't find anything, put that was back when I was pretty new at Rom hacking, now I know that the title screen is tiled, so maybe I'll try dumping the tile data and searching for it. I'll also check out Tile Molester. Thanks for all your help!
That's actually exactly what I just suggested you do. ^_^; Tile Molestor has a few odd quirks, but it's to TLP what a power drill is to a pocketknife. It supports more formats, features better bitmap importing functions and has more "paint program"-like features (MS Paint sure as hell doesn't have a color replace function!). It's worth upgrading to. |
|
|
|
|
Spikeman
Guest
|
|
« Reply #13 on: December 09, 2006, 05:56:32 pm » |
|
Oh really? I always thought TLP was better than Tile Molester.  Guess I better get Tile Molester then. Edit: I get two errors when starting Tile Molester. First it says no languages are installed. Then it says it can't find tmspec.xml in My Documents. Help?  Edit: Fixed it, just copied tmspec.xml to My Documents.  Edit: I'm not quite sure how to view it in 256 color mode, I think it might be 8bpp though. If it is, I looked through the ROM and I don't see the graphics, I think they're compressed. |
|
|
|
« Last Edit: December 09, 2006, 06:27:55 pm by Spikeman »
|
|
|
|
Ryusui
Guest
|
|
« Reply #14 on: December 09, 2006, 07:22:10 pm » |
|
256 color = 8bpp, yes. (Don't worry about planar vs. linear for 8bpp; they're the same thing in this case.)
I don't remember the exact formats for different console types, but Tile Molestor will default to the proper 2bpp formats for NES, Game Boy and others, and the proper 4bpp formats for SNES, Genesis, GBA and etc..
|
|
|
|
|
|
RHDN Forum Archive
