Trying to Assign a Different Palette to Tiles (Hogan's Alley

Here's a simple request. I have a sprite with tiles I want to assign an existing palette to.

Here's the sprite I want to change:


Into this:

(where are the spoiler tags?!)

Anyway, the problem I have is that only one of the tiles uses white in its palette and I need the two tiles surrounding it and the tile above it to share the same palette:


The palettes are shared by other sprites, so altering them will ruin the other sprites that I've already worked on.

You'll have to debug the game to find out how this information is stored. A good starting point would be to see where in the OAM the relevant sprites are, and then set up a breakpoint for these specific slots in the shadow OAM (the page in RAM that gets copied to OAM by a sprite DMA).

Then, by looking at the code, you'll be able to see how the OAM entries are formed, and where sprie attributes and pattern indices come from. Hopefully it will be something straightforward, uncompressed data straight off the ROM, but it could also be coming from RAM, meaning it has been previously decompressed from ROM, in which case you'd have to set a breakpoint for that memory range, and keep going until you find where this data comes from.

In FCEUXD SP, I found that changing the value in address 021A changes the palette to the tile on the left (one of the ones I need), but I hit a roadblock in trying to find the breakpoints.

I entered a 'write' breakpoint with address 021A with the condition "A == #22" (the value I think it normally is), but when the debugger comes back up, I can't find the address it loads from.

Try using breakpoint in combination with trace log.

e.g. breakpoint on change to some RAM address, start running until breakpoint is hit, save the trace.

From there you can read the trace backward from the end to find where the data came from.

Isn't FCEUXD SP old as fuck? Not that it matters here, I'm only saying there's hardly any reason to use that since FCEUX, which is slightly less outdated, has the same debugging features. Or is there anything I'm missing?

If there's a much better, up to date program, let me know.



Okay, I don't know how to do that. I see the Trace Logger, but I don't know how to read the data that comes from that.

Does the same behavior occur in version 2.2.2?

A trace log is a just a list of instructions that were executed, in the order that they happened.

Also on each line is some other data representing the current state, e.g. value currently in A/X/Y registers, status flags, etc.

Like I said, FCEUX. Tepples linked to the latest version, which I believe is about 6 years newer than the latest FCEUXD SP.


Open the CPU debugger an pause the CPU (click "step into"). Now open the trace logger and select "log to file" (I find it easier to use a proper text reader to view the fine than that awkward window), then click the "start logging" button. Now go back to the CPU debugger and set up the breakpoint for $0200-$02ff and click "run". I clicked "run" a few more times to catch a few writes to the OAM, so I could get a better overview of the process. Once you think you have enough just stop logging and open the file in a text editor. The are messages indicating where the breakpoints happened. I just did this and noticed a few things about Hogan's Alley:

1 - The X and Y coordinates come directly from a table, probably reused for all characters, and offsets are added to them so the sprites can move around the screen. The resulting Y coordinate is then decremented by 1, probably to compensate for sprites being delayed by 1 scanline.
2 - The attributes are read from ROM through a pointer at memory location $12. This pointer is probably changed for each character, so you have to see where it points to when the game is drawing the character you want to change and that will probably be the table you're looking for.
3 - The tile index also comes from the table pointed by $12, but it's read beforehand and goes through some processing before being written to the final location. Some values appear to have special meanings too (maybe things like "end of line"?).

So yeah, pay attention to $12 and try to see where it points to when the character you want to change is being processed. There you'll probably find a table of alternating tile indices and attributes.

Ooh! Thanks. I'll go do this tomorrow after work, it's getting late.

I still can't figure out what's going on:

I found that memory addresses 0212, 021A, and 0222 affect the tiles I want to modify, but they all lead me to $0093, and so does 021E, which uses the palette I want to change the others to!

What is this sorcery?

Edit: Oh God! I think I found it.

Double Edit: I did it!

(by the way, that was my lame attempt at making a DK with the default colors. Now I just need to reinsert my old tiles)

Thanks everyone!

Care to share?

Sure! https://www.youtube.com/watch?v=KzF1qbLpD9w

If you're talking about how I found the source address, I had to find what was modifying $0093 by values 01 and 02. I hit 'step into' until I found one, went to the address in rom, and was happy to find that changing it did what I was looking for. But... I saw that changing one tile would also change subsequent tiles next to it that shared the same palette, but I've played that game before and was able to configure it the way I needed (& with exactly the same number of bytes, thankfully).