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.

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?

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.

rainwarrior wrote:

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.

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.

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

Quote:

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.

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.

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.

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).

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum