News: 11 March 2016 - Forum Rules, Mobile Version
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia

Author Topic: Need help tracking down a hex address in ROM (Castlevania)  (Read 486 times)

spookgoblin

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Need help tracking down a hex address in ROM (Castlevania)
« on: August 22, 2017, 03:34:38 pm »
Hey all!

I'm working on my first ROM hack for a wedding present and want to take the big "C" in the Castlevania 1 logo on the title screen and shift its x-coordinate over to the left (I'm redesigning the logo).  Being a novice to this sort of thing, a lot of the resources I find have been going over my head and I unfortunately don't have time to start from square one (as much as I would love to learn Assembly).  That being said, I believe I understand the essentials of how a typical 8x8 sprite is made (i.e. y-coordinate, tile, attributes, x-coordinate), but I can't seem to figure out how that "C" in the logo is put together.

Can anyone help me find the hex address for this sprite or give me some advice on how to track it down in a timely manner?

Thank you!

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6056
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: Need help tracking down a hex address in ROM (Castlevania)
« Reply #1 on: August 22, 2017, 04:32:57 pm »
Are you positive it's a sprite?
Big logos are more likely to be "background" (tilemaps).
Quote
Sir Howard Stringer, chief executive of Sony, on Christmas sales of the PS3:
"It's a little fortuitous that the Wii is running out of hardware."

spookgoblin

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Re: Need help tracking down a hex address in ROM (Castlevania)
« Reply #2 on: August 22, 2017, 04:47:56 pm »
Are you positive it's a sprite?
Big logos are more likely to be "background" (tilemaps).

It seems pretty likely to me that it's a sprite.
I used Stake's title screen editor to place the logo (and everything else) where I'd like it.  However, in addition to the "C" being different colors (it looks like it's taking the palette of the surrounding "astlevania" tiles), a correctly colored fragmented "C" appears above it in its original position.
My description probably isn't too helpful (or intelligible), so I've attached a screenshot of what's occurring:



To double check, I hid the background graphics in FCEUX using the "Display > Graphics: BG" option.  When doing that, all that's left is the "C," the bat, and the "Push Start Key" text (only after pushing start does this particular sprite appear)

dACE

  • Sr. Member
  • ****
  • Posts: 301
    • View Profile
Re: Need help tracking down a hex address in ROM (Castlevania)
« Reply #3 on: August 22, 2017, 07:08:35 pm »
In this case I seem to remember the big 'C' being a sprite (at least most of it).

Have you checked out the editor Stake for Castlevania? That editor has a title-screen editor you could use.

/dACE

spookgoblin

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Re: Need help tracking down a hex address in ROM (Castlevania)
« Reply #4 on: August 22, 2017, 07:27:02 pm »
Using a hex corrupter, I think I have found where the tiles are stored in the ROM--or at least most of them. The bulk of the sprite seems to be hanging out at $003910-003B10 (going back a couple bytes to the start address will probably account for the rest). When I corrupted that range with random bytes, this is what I saw:



I still can't track down where the sprite is being built, though... Which is the part I need to find :(
« Last Edit: August 24, 2017, 06:42:21 pm by spookgoblin »

Dacicus

  • Jr. Member
  • **
  • Posts: 29
    • View Profile
Re: Need help tracking down a hex address in ROM (Castlevania)
« Reply #5 on: August 24, 2017, 11:01:35 pm »
The data for the sprite positions on the title screen starts at 0x1ABA in the ROM.  The quick way to move the sprites for the C 8 pixels to the left (your screenshot suggests to me that this is what you want to achieve) is to subtract 8 from each fourth byte starting at 0x1ABD and ending at 0x1B12.  I would be happy to explain how I found that information, but it does involve assembly and debugging.

spookgoblin

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Re: Need help tracking down a hex address in ROM (Castlevania)
« Reply #6 on: August 31, 2017, 02:54:31 pm »
The data for the sprite positions on the title screen starts at 0x1ABA in the ROM.  The quick way to move the sprites for the C 8 pixels to the left (your screenshot suggests to me that this is what you want to achieve) is to subtract 8 from each fourth byte starting at 0x1ABD and ending at 0x1B12.  I would be happy to explain how I found that information, but it does involve assembly and debugging.

Ahhh!  That did the trick.  Thank you so much!
I would absolutely love to hear how you arrived at this info.
All would ask is that you remember I'm very new to all this :)

Dacicus

  • Jr. Member
  • **
  • Posts: 29
    • View Profile
Re: Need help tracking down a hex address in ROM (Castlevania)
« Reply #7 on: September 03, 2017, 12:04:04 am »
First, I'd like to point out that NesDev is a good reference for NES programming and Andrew Jacobs's site is a good reference for the 6502 CPU in particular.  You may want to use the Addressing and Reference pages of the latter site when going over the code that follows.

The emulator I used was FCEUX 2.2.3.  If you open the PPU viewer while on the title screen, you see the sprites on the left and the background tiles on the right.  It looks like the sprite for the first part of the C is tile 0x3C and the second part is 0x3E; you can get the number by hovering your mouse over the tiles in the PPU viewer.  This will be useful later.

Sprites are handled via NES registers $2003, $2004, and $4014.  The first one of those determines where data is written into sprite RAM, which is usually called OAM.

The FCEUX debugger comes into play here.  Load the ROM and pause emulation at the title screen.  Then open up the debugger and add a write breakpoint on $2003 (Add button -> enter 2003 into Address box -> check the Write box -> leave the CPU Mem option toggled -> click OK).  This causes emulation to stop on a write to register $2003.  Click Run, and the debugger should stop at the following code:
Code: [Select]
>07:C064:8D 03 20  STA $2003
 07:C067:A0 02     LDY #$02
 07:C069:8C 14 40  STY $4014
The second and third lines are the useful ones, because they indicate that the sprite information is copied from CPU RAM $0200-$02FF via DMA.  DMA is used to copy 256 bytes into OAM at once rather than having to do it byte-by-byte.  This means that the sprite information is stored in CPU RAM $0200-$02FF in the order y-coordinate, tile, attributes, x-coordinate for each sprite that you mentioned above.  So $0200, $0204, $0208, etc. have the y-coordinate; $0201, $0205, $0209, etc. have the tile; and so on.

Now we need to find out where the data at $0200-$02FF comes from.  Set a write breakpoint on that range of addresses using the same process as before, but enter 200 into the first Address box and 2FF into the second.  You can disable the $2003 breakpoint by double-clicking on it in the list so that the letter E disappears after the colon.  When you click Run, the debugger should stop at the following code:
Code: [Select]
>00:80F4:9D 00 02  STA $0200,X
 00:80F7:B1 08     LDA ($08),Y
 00:80F9:9D 01 02  STA $0201,X
This is nice, because the second and third lines indicate that the tile values come from an address related to the value at $0008 in CPU RAM.  It may not be the C tile that's being processed, however.  To find that one in particular, we'll modify the breakpoint.  Select the $0200-$02FF breakpoint, click Edit, enter A==#3C into the Condition box, then hit OK.  This is now a conditional breakpoint because it will only work when the A==#3C condition is met.  It causes emulation to stop when $0200-$02FF is being written to but only if the accumulator (A) has value 0x3C, which is the first part of the C tile.  We know that the accumulator will have that value because of the LDA and STA instructions.

One thing to mention here is that the disassembly you see on the left side of the debugger is not always the order in which the code is executed.  Branch and jump instructions can cause instructions to be skipped or can jump to other areas of code.  This is relevant because the instruction immediately above the one indicated by the > may not be the one that was executed before it.  The trace logger can record the instructions in the order in which they are executed.  So open up the trace logger (Debug -> Trace Logger) and set it to log the last 100 lines in the drop-down box.  Then click Start Logging.  Now go back to the debugger and click Run.  It should stop at code similar to
Code: [Select]
>00:80F9:9D 01 02  STA $0201,XThe last line in the trace logger should be
Code: [Select]
$80F7:B1 08     LDA ($08),Y @ $9AAB = #$3CAgain, this means that the tile value comes from an address related to the value at $0008 in CPU RAM.  The info after the @ symbol indicates that the exact address is $9AAB. 

In the hex editor, go to $9AAB; File -> Goto Address is easier than scrolling.  You should see that 0x3C value that we want.  If you right-click on it and select Go Here In ROM File, you'll end up at 0x1ABB.  The nice thing about the hex editor is that you can change values as desired and see the effects without having to modify, save, and reload the ROM file.  You may need to reset the emulation, however.  Just select the address that you want to modify and type whatever value you want.  (Note: This may cause the game to crash depending on what you modify.)  To play around with this without interruptions, disable any breakpoints in the debugger and click Stop Logging in the trace logger.

If you look at the values following that 0x3C at 0x1ABB, you'll see 0x3E four bytes later.  This is the tile value for the second part of the C.  This may be a coincidence, since the data doesn't have to be stored sequentially in the ROM, but changing it in the hex editor also changes that part of the C.  Now we can hypothesize that the data indeed is stored sequentially, so the X-coordinate should be two bytes after the tile value, at 0x1ABD.  If you change this in the hex editor, the first tile of the C moves horizontally.  Keep doing this for every fourth byte, and you'll modify the positions of the sprites on the title screen.  You can do File -> Save Rom As to save your hack as a new ROM file when you're done.

There are a number of potential problems with this approach that I could discuss at this point, but what questions do you have first?

spookgoblin

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Re: Need help tracking down a hex address in ROM (Castlevania)
« Reply #8 on: September 12, 2017, 01:27:53 pm »
There are a number of potential problems with this approach that I could discuss at this point, but what questions do you have first?

First, I'd like to say thank you for taking the time to flesh out what looks like a very healthy chunk of information.  In all honesty, I have not had the time to sit down with it as it's horrendously difficult to work on this project without alerting the person I'm making this for.  To put it in perspective, I can pretty much only work on this hack while on lunch break at work!  If and when I can find myself with this elusive thing some people call free time, I plan to spend some time with your post and see if my newbie brain can make sense of it.

On another note, I ran into several other problems after implementing your suggestion. 
It seems that the nametable for the background graphics have the wrong palette set for one specific portion.  This is, I imagine, a byproduct of shifting the "C" over.
On top of that, I'm trying to turn the "C" into a "B" and the actual sprite isn't a rectangular shape (so I would have to add sprite data rather than just modifying it).

It's just a rabbit hole!

September 16, 2017, 04:12:14 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
There are a number of potential problems with this approach that I could discuss at this point, but what questions do you have first?

Okay, so I've had a bit of time to look over your post and a good chunk of it makes sense, but there are some inconsistencies on my end that are bit perplexing.  First off, I appear to be on the same version of FFCEUX as you, but the second code chunk doesn't look the same to me.

You posted:
Code: [Select]
>00:80F4:9D 00 02  STA $0200,X
 00:80F7:B1 08     LDA ($08),Y
 00:80F9:9D 01 02  STA $0201,X

But I saw:
Code: [Select]
>07:CB38:99 14 02  STA $0214,Y @ $0240 = #$00
 07:CB3B:88        DEY
 07:CB3C:88        DEY
 07:CB3D:88        DEY
 07:CB3E:88        DEY

So I'm not entirely sure if I'm inputting things wrong.

I also noticed that some of the info that the debugger spits back looks different than what you posted. 
For example, in the first code block you posted, you wrote:
Code: [Select]
>07:C064:8D 03 20  STA $2003
 07:C067:A0 02     LDY #$02
 07:C069:8C 14 40  STY $4014

But I saw:
Code: [Select]
>07:C064:8D 03 20  STA PPU_OAM_ADDR = #$00
 07:C067:A0 02     LDY #$02
 07:C069:8C 14 40  STY OAM_DMA = #$02

Why are these displayed differently?
I'm also not really sure how to interpret a lot of this data since I'm unfamiliar with the syntax of ASM.


On a separate note, is there a way I can use your method (or something similar) to track down background tiles?  More specifically, I want to edit the palette of an attribute table (if I have my terms correct) since shifting the big "C" over landed me in a funky spot where the logo's background tiles bleed into other palettes and create some color issues.

Lastly, this one seems like a super long shot, but I'm trying to turn that "C" into a "B."  I've got my graphic prepared already and I've imported what I can using YY-CHR, but there's a section in the middle that isn't part of the sprite (normally where the first "a" in "Castlevania" is nested).  I also notice that a lot of tiles are re-used but there's less repetition in my "B."  Is inserting this kind of sprite data to fill in that extra space a feasible undertaking?

Thank you again for your help, Dacicus.  I can't tell you how much I appreciate it.
« Last Edit: September 16, 2017, 04:12:14 pm by spookgoblin »