+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Level Data?
Pages: [1]
Author Topic: Level Data?  (Read 2 times)
matrix
Guest
« on: November 06, 2006, 06:33:22 am »
Quote
If level data in a game is uncompressed, you can usually easily find it simply by scrolling through the ROM in a hex editor and looking for patterns of bytes that you would consider level data (it helps to have worked with such data in a hex editor before). Some games can be very simple... If this method doesn't work, you can do a search for TSA data; finding TSA data is actually mostly covered in the previous section. If you can find the TSA data and can locate the start of the data, then you can use that data to tell what hex value each block uses. With that, you can search in the ROM for a few blocks from the start of a level, and if it's a micro based level data system, you'll have found it. If it's macro based, you'll want to find the 4x4 TSA data and do the same with that as you just did with 2x2 TSA. If neither of those work, chances are the game uses compression. You'll need to find it either with ASM or corruption.

Okay, so this is saying that the same hex values that make up the level backrounds are also used for level data?  I find that hard to believe.

How would I go about finding level data in RAM?  Is there a way to do it without a debugger?  I have experience with fceuxd/nesten, but it can't be very efficient trying to guess when a game is loading its level data while doing a cheat search.

Edit:  I should probably add what I've done already. 
I dumped the PPU. I can identify everything in the file except for a very small string of data in the name tables, which can't be found in the rom.
I dumped the CPU which led me to one section that I eventually ruled out through corruption.
There are about a dozen sections of the rom that I know what is used for, so I corrupted large chunks of the unknown sections with only one spot that I ruled out because I recognised ASM commands.

Any tips are greatly appreciated.
« Last Edit: November 06, 2006, 06:58:28 am by matrix »
jwurmz
Guest
« Reply #1 on: November 06, 2006, 11:04:23 am »
i'll take a stab at it. which game?
matrix
Guest
« Reply #2 on: November 06, 2006, 06:47:40 pm »
double dragon 1 nes
jwurmz
Guest
« Reply #3 on: November 07, 2006, 08:55:26 pm »
well one thing is for certain; the image data for level 1's background starts at $97 in the ROM. start changing the hex values at/after that offset and you'll see what i mean...
matrix
Guest
« Reply #4 on: November 08, 2006, 08:42:15 am »
Yeah, already found that.  Thanks anyways.
jwurmz
Guest
« Reply #5 on: November 10, 2006, 11:02:42 am »
do you have notes that detail the areas of ROM that are already ruled out?
matrix
Guest
« Reply #6 on: November 10, 2006, 05:27:28 pm »
x10 backrounds
x8000 title screen
xC0F5 p1 and enemy sprites
x19CA8 enemy data 1
x19FC2 rooms and scroll stop
x1A1D7 1p screen location
x1A2D7 enemy data 2
x1A3D7 something to do with area clear(thumbs up)
x1E2B5 no. of hearts (wired into high score)
x1E2C3 no. of lives
x1E8C3 no. of hearts(freezes game)
x1F1CE palletes
x20000 br pattern tables
x30000 sprite pat tables
jwurmz
Guest
« Reply #7 on: November 14, 2006, 01:22:44 pm »
well i've spent quite a but of time trying to wrap my head around the data stucture of levels (image data, clipping data, palette data, etc.) and i'm almost ready to throw in the towel. if we examine the level data byte-by-byte starting at x10 we're bound to run into a chunk of (compressed) data that relates to level clipping. here's what i have found...

these are the first 8 bytes starting at x10:

x10: [4A][80] - this controls the offset of where the background IMAGE data is pulled from for scene 1, level 1
x12: [1B][8C] - this controls the offset of where the background PALETTE data is pulled from for scene 1, level 1
x14: [87][83] - this controls the offset of where the background IMAGE data is pulled from for scene 2, level 1
x16: [53][8C] - this controls the offset of where the background PALETTE data is pulled from for scene 2, level 1

...and so on. the trouble is i can't figure out the coding convention with those bytes. for instance, the image data for level 1, scene 1 appears to begin at x97. the 2 bytes starting at x10 are [4A][80] but i don't see how this relates to x97. if you change the [4A][80] to [87][83], then level 1, scene 1 definitely uses the image data for level1, scene 2.... but what the hell is the coding convention? i don't see how the 2 bytes [4A] and [80] relate to the offset x97.... any ideas?
matrix
Guest
« Reply #8 on: November 14, 2006, 04:12:14 pm »
My only guess is the bytes at x10 are pointers pointing to a different bank, meaning we need to figure out X000?

I noticed this before when I was corrupting large chunks: something interesting in level 1 scene 2 when the girl comes out of the elevator, after the doors close, the door image is loaded from a different spot.  ie, if you change 8783, the scene is all messed up, but the doors are still intact.  I tried to find the second spot to no avail.

I know what you mean about throwing in the towel.  This game has me frustrated and burnt out.
Disch
Guest
« Reply #9 on: November 14, 2006, 07:57:22 pm »
Quote from: jwurmz on November 14, 2006, 01:22:44 pm
x10: [4A][80] - this controls the offset of where the background IMAGE data is pulled from for scene 1, level 1
x12: [1B][8C] - this controls the offset of where the background PALETTE data is pulled from for scene 1, level 1
x14: [87][83] - this controls the offset of where the background IMAGE data is pulled from for scene 2, level 1
x16: [53][8C] - this controls the offset of where the background PALETTE data is pulled from for scene 2, level 1

...and so on. the trouble is i can't figure out the coding convention with those bytes. for instance, the image data for level 1, scene 1 appears to begin at x97. the 2 bytes starting at x10 are [4A][80] but i don't see how this relates to x97. if you change the [4A][80] to [87][83], then level 1, scene 1 definitely uses the image data for level1, scene 2.... but what the hell is the coding convention? i don't see how the 2 bytes [4A] and [80] relate to the offset x97.... any ideas?



Looks like your standard pointer table to me.

This is MMC1 (probably with typical 16k swapping at $8000).  So....

offset 0x00010  would be $8000
offset 0x0005A would be $804A (your scene 1 graphics)
offset 0x00397 would be $8387 (your scene 2 graphics)

Pointers seem to get progressively higher as the table extends.

offset 0x00097 is probably just part of the image data.  Considering the pointer points to 0x0005A and the pointer after it points to 0x00397 -- I would wager the image data for the scene lies within that range.
matrix
Guest
« Reply #10 on: November 15, 2006, 02:41:20 am »
Thanks Disch.

The second pointer actually points to the att table.
Neil
Guest
« Reply #11 on: January 01, 2009, 08:52:20 pm »
-necrobump to save a thread from the great board prune of 2009-
don't see a level data doc on this site for this. dunno if this stuff is on data crystal.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC