I found a line in the debugger that said:
LDA $00FE = $1E
But I couldn't navigate to the ROM address by going to $00FE in RAM and right-clicking as there was no "Go to in ROM" option at those addresses :O
Well first of all you need to know how the NES's RAM works: $FE is in zero page, and is part of the NES's working RAM, i.e. what it uses to do stuff during a game. From $0000 to $07FF is the 2KB internal RAM, and everything between that and $2000 is just a mirror of it. So of course you can't "go to in ROM" there because that's not the ROM.
The ROM is located between $8000 and $FFFF: which part of the ROM depends on what the mapper has given to the RAM at that moment. This is a quirk of the NES hardware, that it only has 32KB available for the ROM so to use more you need to swap it in and out (this is for the program (PRG) but the same restrictions apply for the character (CHR) ROM too - except that's just 8KB). Check this for details:http://wiki.nesdev.com/w/index.php/CPU_memory_map
Okay, let me look at those three PPU addresses you gave and see if I can find them in the ROM for you.
So I write click on $23C1 in PPU RAM and set a write breakpoint to find out how $AA got there. Reset... first $FF is written to it, so I click Run, and next I see $AA is written to it: in the debugger it says "STA PPU_DATA", which means "store what's in A to the PPU_DATA register", which is the register the CPU uses to write things to PPU RAM. So how did $AA get in the Accumulator (that is, A)? Well, look directly above it:
LDA ($01),Y @ $B0F5 = #$AA
This means "load the Accumulator with a byte, and get the address for it by reading the address at $01 and adding Y to it". Now, this might sound confusing, so let's look at the screen.
We can go to $01 in CPU RAM and see that it has $C4, and $02 has $B0. Because the CPU is little-endian, it means the least significant byte goes first. In practice, that means we swap them. So $C4B0 becomes $B0C4. So the command says "go to $B0C4 plus Y". The debugger tells us that Y currently contains $31. What's $B0C4 plus $31? Why, $B0F5 of course, which is what is written in the debugger - as well as it telling us that $AA is what it found there.
So we now go to $B0F5 in CPU RAM and find $AA, surprise surprise, but we come across a problem. We only want to change $23C1, but if we look around it, we see $AA in $23C0 to $23C7, but at $B0F5 we only see one $AA. This is because the program is written to say "write $AA here, and do it 8 times". So if you wanted to change one of those $AA bytes, you'll need a bit more work. And it's getting late so I'll leave that for now.
Anyway, where is $B0F5 in the ROM? Well, go there in RAM, right-click "go here in ROM file" and it's at $1B105. Change $AA to, say, $FF, reset, and voila: the top part of the screen has gone all green. Now you see why the program told to write $AA all along the top: it's where those big grey squares are.
Which means I have to ask: are you sure you want $23C1? The others maybe, but that one doesn't seem to affect your new title.
Anyway, I'm tired now... I hope I've got you started though.
(P.S: I wrote all of the following before I realised that those three PPU addresses you mentioned were in the attribute table, not the name table. Now, it may be useful to you, or not... but I spent a while writing it so I'm not gonna delete it if it might be useful
First of all, understand the difference between background and sprites, because they are very different indeed. The current background is stored in the PPU RAM between $2000 and $2FFF in the form of a nametable. When a value is placed here, it references something in the pattern table (between $0000 and $1FFF) which is where the graphics are located. Sprites, on the other hand, are located in object attribute memory (OAM) which is apparently part of the PPU but for some reason appears at $200 in the CPU RAM. I don't know why, I just roll with it. This has four values: X and Y position, the tile number (again, referring to the pattern table) and a byte for attributes (flip horizontal or vertical, for example). I'll give you this link before I continue:https://wiki.nesdev.com/w/index.php/PPU
Let's say you know there's a background tile at $23C1 that you want to replace with something else (this is just an example, not necessarily what you're doing). I go to $23C1 in PPU memory in FCEUX and see, for example, $C2. Now, the program told the PPU to put that there: the CPU reads the program, and sends the info to the PPU through registers (i.e. it first picks the address - $23C1 - and writes it to the address register, then picks the tile - $C2 - and writes it to the PPU writing register. So, we need to know where in the code is the instruction to say "put $C2 at $23C1". Now, for a title screen graphic with lots of tiles, you'll probably just find a list of tiles and it writes them one by one from the upper-left of the screen, because it's easier. But anyway, I can right-click and set a write breakpoint for $23C1 in the PPU RAM and it'll break whenever that address is written to.
So I reset the NES and of course it breaks, probably because it writes $00 to it to clear the screen. But at some point it will break because it's writing $C2 to it. So I look at the debugger to see where that $C2 came from, and as I said in a previous post, if you're lucky, it'll say it loaded the Accumulator with $C2, and it got that from somewhere between $8000 and $FFFF - the ROM. If you're unlucky, it'll say somewhere lower than that, meaning you have to do a write breakpoint to THERE and find out how it got THERE.
Sprites are a different kettle of fish, because obviously they're not so static: they can fly all over the place, and so they may be in the ROM slightly differently, but it's still possible to find them, of course. This time you'll want to figure out which sprite you're looking for in the $200 to $2FF section and set a write breakpoint to the byte that tells you the tile. Same process as the background tiles from there, pretty much.
EDIT: I just re-read my first post in this thread: I already told you where in the ROM to find this stuff... and about the ROM being above $8000. Well, hopefully you can now figure out how I got there.