Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Rom Hacking: hukka | 2 guests
Acmlm's Board - I2 Archive - Rom Hacking - How do you find level data within a rom? | |
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
Dark Ludwig

Red Paratroopa
Level: 21

Posts: 26/172
EXP: 45740
For next: 4203

Since: 09-17-04
From: Georgia

Since last post: 9 days
Last activity: 2 days
Posted on 03-18-05 06:21 AM Link | Quote

*Nervous for speaking in first thread*

Ok now. This has puzzled me for quite some time. I have seen editors for this game, that game, and I know the level data had to have been found somehow. I was hesitant to ask, but I can't wait any longer: how do people find level data in a rom? I don't plan on making an editor, that's way over my head. I just wanted to know if people:

-Randomly edit values for eons until they find a change in one of the levels.

-Use a program (a tracer, maybe?) to locate data with certain properties.

-Get info from someone that works for nintendo (most likely not).

And if it is usually found some other way, then please tell me how. Also, I couldn't find a place that I could download a tracer. Does anyone know where I could download one?

Thanks in advance!
Bit-Blade
Pixel Artist

Level: 34

Posts: 187/445
EXP: 229264
For next: 24387

Since: 03-16-04

Since last post: 2 days
Last activity: 7 hours
Posted on 03-18-05 07:06 AM Link | Quote
Well, there are a few ways. Random corruption in one. You corrupt the rom one section at a time until the levels start to be configured, in other words you fucked with the level data. This is pretty time consuming and largely hit or miss (mostly miss), shooting in the dark. Second, if you can recognize patterns in hex (like some of us can) you can more or less zero in on where level data is and experiment to see exactly what does what there. Third, I would guess that some ASM hackers MIGHT be able to locate it, though this is a dumb guess that I have no idea of being right or wrong.

Rom corruption is a pain in the ass. About the only thing I can do is recognize compressed level graphics in the Super Metroid rom in hex.
Squash Monster

New Age Retro Hippie
Togateiru Fohku Kohgeki!!
GRUNGE no HAMSTER otona bite
Peace love and turnpike!

Level: 40

Posts: 549/677
EXP: 430507
For next: 10802

Since: 03-15-04
From: Maryland (of the Country Between Canada and Mexico)

Since last post: 5 hours
Last activity: 5 hours
Posted on 03-18-05 07:50 AM Link | Quote
The big three methods are corruption, manual scanning, and tracing.

Corruption is choosing parts of the ROM, usually in a systematic approach, filling them with garbage data using a tool like Corrupster, and testing the ROM to see what you messed up. It takes a little skill to figure out if you got level data or something else, like tile data, graphics, screen data, or something bizarre that's specific to your game. Once you've found level data, you can sometimes figure out what type of level format and compression the game uses right off the bat, and other times have to either manually edit or corrupt small parts to figure out the format.

Manual scanning is reading through the ROM, looking for data that looks like level data. This usually relies on you knowing what type of format the data is in. This is mostly a process of guessing what the developers were thinking. There are subtle clues to such things -- for example, a game with RLE compression is likely to have either rows or columns of the same tile repeating, while a game with other compression types will often go for more detail in a similar situation. If you're good and a quite a bit lucky, you can find level data the same way you'd find TSA data. By the time you've found level data by manual scanning, you probably already know how it works.

Tracing is reading the game's code as it runs untill you find level loading type stuff. It tends to make it fairly easy to understand the level format, but most of the time people only resort to tracing if the level format is too bizarre to use the other two methods. You usually have to use some form of tracing if the level format is very compressed or unusual -- corrupting only works if any compression present is very forgiving, and manual scanning only works if the compression is fairly simple, mostly dictionary or RLE.
Jathys

Red Goomba
Level: 11

Posts: 13/48
EXP: 5916
For next: 69

Since: 12-21-04

Since last post: 8 days
Last activity: 8 days
Posted on 03-18-05 09:29 AM Link | Quote
Corruption is awesome, when it's not completely random . . . Corrupt all of any specific value throughout the entire rom. If the game crashes, try a different value (you learn to avoid certain, often used values). If the game doesn't crash, check to see if the level looks any different. If it does, keep cutting the area you're corrupting in half and checking to see if the level is still corrupted.

Cutting the corrupted in half speeds things up drastically.
drjayphd

Beamos
What's that spell?




pimp!
Level: 56

Posts: 913/1477
EXP: 1387410
For next: 10766

Since: 03-15-04
From: CT

Since last post: 2 hours
Last activity: 2 hours
Posted on 03-18-05 10:42 AM Link | Quote
Not only that, but if you don't know much about what to look for, you can usually rule out a good chunk of the ROM by what's there. Generally, level data isn't mixed in with graphics, so if you open the ROM up in a tile editor, you can find where not to look.
NetSplit

Koopa
Level: 19

Posts: 21/117
EXP: 30378
For next: 5399

Since: 04-05-04

Since last post: 1 day
Last activity: 1 hour
Posted on 03-18-05 02:29 PM Link | Quote
Bah, everyone's overlooking TSA searching. If the game doesn't have compressed levels or some sort of weird format, this is probably the cleanest way to find level data. The only problem with it is that a whole lot of things have to go right for it to work, but they're common requirements and the method itself is really quick, so it's a good method.

Basically, you try to find the TSA data for 2x2 tile blocks by searching for the top left, top right, bottom left, and bottom right tiles (or other variations of this, such as top left, bottom left, top right, bottom right). Generally, TSA data will be set up so that the 4 bytes required for each block are all grouped together, so this tends to work pretty well. TSA data generally starts with a block for the sky or something of that sort (either sky or just a black block), so you should try to find the TSA for that first. When you find the TSA, you need to locate the beginning of it; once you've done that, you have the IDs for all 256 blocks. If the game uses 2x2 tile blocks for its level data (such as Milon's Secret Castle, but that's not a very good example for this because the level format uses 4 bits per block, not 8, and also uses a bit of compression. Also note that MSC is really small, so you can just manual scan it and find the level data very easily), you can search for some of the blocks from the first screen in either a left to right or top to bottom fashion and hopefully find the data. Generally, games that use 2x2 tile blocks don't have as much repetition in their levels (detail-wise) than games that use 4x4 blocks and are thus easy to identify, but they also tend to use compression.

So most games that this method works with use 4x4 tile blocks. You can find the 4x4 TSA the same way you found the 2x2 TSA, except instead of using 1x1 tiles to build a 2x2 block, you're using 2x2 tiles to build a 4x4 block. When you find that TSA, you can use it to find the level data (if it's uncompressed) pretty easily.

Sounds confusing, but it's pretty simple. A good game to try it out on is Ninja Gaiden 2. Give it a shot, and good luck.

BMF98567
BLACK HAS BUILT A SILLY DICE-MAZE!
GO!

Current list of BURNING FURY >8( recipients:
- Yiffy Kitten (x2)
- Xkeeper
Level: 53

Posts: 702/1261
EXP: 1094149
For next: 62970

Since: 03-15-04
From: Blobaria
Special Move: Rising Meatloaf Backhand Combo

Since last post: 21 hours
Last activity: 1 hour
Posted on 03-18-05 03:52 PM Link | Quote
Personally, I watch FCEU(X)D's RAM viewer as a level is loading. Once I find the decoded level data, I set a write breakpoint somewhere in that area (a lot of games use extra RAM at $6000 to store decoded level layouts, like SMB2). Re-enter the level, wait for the breakpoint to hit, and trace backwards from there. A definite bonus of using this method is that it almost always drops you right in the middle of the level decoding/decompression routine.
Xkeeper
The required libraries have not been defined.
Level: NAN

Posts: -2336/-863
EXP: NAN
For next: 0

Since: 03-15-04

Since last post: 2 hours
Last activity: -753366 sec.
Posted on 03-18-05 06:54 PM Link | Quote
I just open Hexsposeure and hold page down.


Hey, worked for Crystal Mines...
||bass
Programmer Admin
Level: 44

Posts: 239/817
EXP: 570813
For next: 40472

Since: 03-15-04
From: Salem, Connecticut

Since last post: 26 days
Last activity: 11 days
Posted on 03-18-05 07:19 PM Link | Quote
I find loading games in a 65816 disassembler to be an easy and fairly straightforeward method. If you know where any various data are located, you can always check which parts of the code call the data in a decent disassembler.
Kitten Yiffer

Purple wand
Furry moderator
Vivent l'exp����¯�¿�½������©rience de signalisation d'amusement, ou bien !
Level: 135

Posts: 8742/11162
EXP: 28824106
For next: 510899

Since: 03-15-04
From: Sweden

Since last post: 3 hours
Last activity: 4 min.
Posted on 03-21-05 08:26 AM Link | Quote
Manual scanning works pretty fine for me too, it took two tries before I found the level data on a certain game! It's not that hard on certain games. I can see why Crystal was easy to hack, it probably stores data in a quite similar way to the game i'm hacking in a way...

I should release a hack of that game... not telling yet thought.

I heard about using FCEUXD for finding level data, and I should probably use FCEUXD for finding the sprites data. I can edit the level itself in that game, but I hadn't found the data for objects and enemies for example.
Xkeeper
The required libraries have not been defined.
Level: NAN

Posts: -2314/-863
EXP: NAN
For next: 0

Since: 03-15-04

Since last post: 2 hours
Last activity: -753366 sec.
Posted on 03-21-05 08:31 AM Link | Quote
Originally posted by Kitten Yiffer
Manual scanning works pretty fine for me too, it took two tries before I found the level data on a certain game! It's not that hard on certain games. I can see why Crystal was easy to hack, it probably stores data in a quite similar way to the game i'm hacking in a way...

I should release a hack of that game... not telling yet thought.

I heard about using FCEUXD for finding level data, and I should probably use FCEUXD for finding the sprites data. I can edit the level itself in that game, but I hadn't found the data for objects and enemies for example.
I actually released a (bad and incomplete) document on that game. The level format goes something like this, and it's not hard to understand at all:

[xx] - denotes optional

Level header: XX XX XX XX XX XX XX XX >L50-{XX XX XX XX XX XX XX XX}
{ 330 bytes denoting level layout, always 330 (30 x 11) }

{ 3 x n bytes for hidden tiles } [FE { 3 x n bytes for L50 h. tiles }] FF { unknown monster format } [FE { unknown L50 monster format } ] FF

{next level header...}

There are no pointers, so I assume that it just keeps the last address in memory and starts reading there, or just starts from L1 and goes through (making expansion very easy... sort of)
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 3827/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 03-21-05 08:36 AM Link | Quote
I use/know a few different methods. Most of them are already mentioned here, but what the hell.

Corruption: Usually using a program like Corruptster. Corrupt a section of the ROM (usually one bank for big ones, a few hundred bytes for smaller ones) and see what happens. If it's not what you want, restore it and try again. It's usually better to set all the bytes to a specific value rather than random, because it's reproducible and easier to notice. For example if you set everything to 0x20 and corrupt the graphics, it's obvious because everything turns into lines. If you use random data you just see garbage, and there's no telling why - maybe you corrupted the graphics, changed pointers, broke ASM etc.

Mapping: Works best for small and/or commonly-hacked ROMs. Map out everything you do know (graphics, code, etc) and look at the rest. A debugger that can tell you what areas are executed can help with this.

Looking for patterns: Just take a look at stuff in hex and see if it looks like level data. This works best with uncompressed tile maps; you can usually almost see the level itself in the hex. Similarly you might try searching for patterns you know are probably in it, such as strings of tile numbers or coordinates. Tip: They're often found at the beginning of a bank.

Tracing: Look for references to the level data in RAM, known data in ROM (maybe you know where one level is, but need to find others and/or their pointers), or other level-related things, and trace through the code. If you can figure out how it tells where to get its data from, bam, you got it. Whether you figure out the format through more tracing or just trying stuff is up to you.
bbitmaster

Koopa
Level: 18

Posts: 72/103
EXP: 25264
For next: 4633

Since: 03-28-04
From: Knoxville, tTN

Since last post: 12 days
Last activity: 7 days
Posted on 03-22-05 08:12 AM Link | Quote
I find FCEUXD's code/data logger to be extremely easy to use for finding level data in most games with scrolling levels. All you have to do is tell it to work with the trace logger to only show code that accesses new data, and wait a minute in the level for all the music to play, and try to get all other unrelated code to execute before scrolling to a new part of the level, and BAM! Up comes the location of the level data that the game just scrolled in.
Dark Ludwig

Red Paratroopa
Level: 21

Posts: 28/172
EXP: 45740
For next: 4203

Since: 09-17-04
From: Georgia

Since last post: 9 days
Last activity: 2 days
Posted on 03-22-05 09:09 AM Link | Quote


FCEUXD and Geiger's SNES9X debugger won't help me, because I am one of those people who has just started learning assembly, but I still know how to use various programs that work with assemly stuff. I am trying to find the level data in a Gameboy Advance ROM, Wario Land 4 to be specific, and I've searched and searched but I can't find a GBA debugger THAT EITHER WORKS OR IS FREE, ESPECIALLY BOTH. So when I find the level data, i'll edit the values one by one, see what they do, take note, and figure out how the level is stored, maybe I could make a level per week like that. Even if it'll take that long, it's a neat game, I think it'd be worth it.

Could someone:

-Tell me the name of a good GBA debugger? I found one, but it's beta and doesn't even work.

-Tell me what kind of assembly GBA games use?

Thanks, and I'm keeping my ears closed to those of you who think I'm stupid for just learning assembly and choosing this as my first task. Trial and error never failed me before, so taking note of changes will pay off eventually.... I think....
labmaster

Blue Octorok
Level: 12

Posts: 33/43
EXP: 6135
For next: 1786

Since: 07-17-04
From: New Zealand!

Since last post: 10 days
Last activity: 2 min.
Posted on 03-22-05 09:18 AM Link | Quote
I use a modified version of VBA SDL, which includes a console debugger. If you're used to GUI debugging, it might take a bit of getting used to (and there's virtually no documentation :p), but I don't have any problems with it.

Note: none of the public builds include VRAM breakpoint support - so unless graphics are copied via DMA or one of the SWI's (in which case you can catch them via the logger in VBA Developer Version), you'll be out of luck. I've been planning on re-writing it, but I've kinda been waiting for the next version of VBA to be out.

The download is hopefully still up, somewhere at http://labmaster.4gigs.com

You might still be able to find one of the old (cracked) versions of No$GBA out there, but the compatibility isn't all that great.

RascalBoyAdvance allegedly has a debugger, but I haven't figured out how to breakpoints with it (if it can at all). Mappy VM also has a reasonable one, but as it hasn't been worked on for a considerable amount of time, compatibility ain't all that great.
blackhole89

LOLSEALS
Moderator of ROM hacking
EmuNET IRC network admin
Head GM of TwilightRO
Level: 47

Posts: 595/971
EXP: 739208
For next: 26995

Since: 03-15-04
From: Dresden/Germany

Since last post: 14 hours
Last activity: 12 hours
Posted on 03-22-05 12:11 PM Link | Quote
I commonly load the ROM at some address above bank 3 (it's -extremely- improbable to encounter anything but code below that point) and then start looking for any kind of patterns using page-down. If I encounter anything that looks suitable, I write a little program to just render the blocks at this point and see if I recognize the pattern.
This method actually also works on rather "modern" games... I did the same thing when figuring out the island data format for 1503 A.D. (yeah, it must have been aeons ago when I wrote an editor for that game) and when writing my RO .gat file editor (which still isn't released).
If that doesn't work, I used to do some tracing.
Parasyte

Bullet Bill
Level: 35

Posts: 376/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-22-05 04:14 PM Link | Quote
dark ludwig, GBA contains an ARM7TDMI CPU, meaning the assembly used is: [two instruction sets] ARM7 and Thumb.


(edited by Parasyte on 03-22-05 07:18 AM)
Kyoufu Kawa
I'm not bad. I'm just drawn that way.
Level: 70

Posts: 1353/2481
EXP: 3008456
For next: 7355

Since: 03-19-04
From: Catgirl Central

Since last post: 14 hours
Last activity: 13 hours
Posted on 03-23-05 12:34 AM Link | Quote
Originally posted by Parasyte

dark ludwig, GBA contains an ARM7TDMI CPU, meaning the assembly used is: [two instruction sets] ARM7 and Thumb.
I like Thumb. It's comfy and easy to hack.

* hugs his custom PkMn intro screen *
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 3872/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 03-24-05 12:34 AM Link | Quote
Originally posted by bbitmaster
I find FCEUXD's code/data logger to be extremely easy to use for finding level data in most games with scrolling levels. All you have to do is tell it to work with the trace logger to only show code that accesses new data, and wait a minute in the level for all the music to play, and try to get all other unrelated code to execute before scrolling to a new part of the level, and BAM! Up comes the location of the level data that the game just scrolled in.

Well sure, if it's not compressed.
Parasyte

Bullet Bill
Level: 35

Posts: 378/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-24-05 04:24 AM Link | Quote
What? If it's compressed, you'll also pull up the decompression routine in addition to the location of the compressed level data...
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Rom Hacking - How do you find level data within a rom? | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.013 seconds.