You probably found the routine that changes the palette. What you are looking for is the tilemap that assigns a palette for every tile on-screen. I believe for NES they are usually called name tables. Info on that can be found with FCEUX (I saw screenshots of it having a tilemap viewer).
Basically, it is going to be either of two cases:

• the tilemap is copied 1:1 to RAM -- this is the easy type
• the tilemap is created via a routine -- this will require asm work

Basically, there is going to be a routine that creates the map in RAM. If it is a 1:1 copy, you got lucky and you can just change the stuff in the original data and that's it. If you have to deal with a routine that draws these maps, you will have to find it and change its vectors according to your desires.

Also, another route to get around this problem is by simply not using the shade that is blinking - if you have another shade available that has the same color or can be changed to the same color without corrupting the rest of the title screen. This is oobviously the cheap way out and may not be possible in your case. You should try to break inside the routine that is executed when the values for the tilemap change in ram.

Also, you should probably wait till Disch sees this thread, he is much more knowledgeable and may have some other clues as far as terminology goes

cYa,

Tauwasser

Firstly, sorry for taking too long to reply. I had some difficult getting the tutorial at the point you gave me, tummai, so I had to go from the first class. Luckily, I'm now finishing reading about PPU Access (and some of these routines are related to the one I've found and mentioned early in the game), and I'm almost quite understanding the whole process. Not intuitive as I would have though, but with references like this link, the process is more understandable.

Secondly, thanks for the feedback. I wouldn't have expected a doc as nice as this one. Sweet!
Now, just for some considerations (I still have to finish the reading of the docs, so I may say some noobish - if I do so, pardon me ;P): it looks like that, in my picture, everything is considered background. I've came to this conclusion not only because all the graphics were exhibited in the same Name Table, but also because it goes scrolling all at once.

Now, let's say I know the position on the Name Tables of the bytes I want to remove the blinking effect. A simple look at the Name Tables at FCEUX was able to tell me that. There goes also the PPU address of these tiles, and if I would pause the emulation twice, once on each blink color, I would got two palette codes (what makes sense). If I add a breakpoint related to this PPU address, find the routine that changes the palette to these tiles and simply change the value (in a way that it doesn't swap), do you guys think this will work?

And oh, @Tauwasser - sorry, I really didn't got what you tried to say with shades. By saying shades, you mean simply changing the color of the tile? In a simple graphic editor? Sorry, I couldn't really understand this part.

And oh, thanks everybody again.

Okay, in theory, I got it completely. When it's time to put my skills on use, I'm having some difficulties, but I'll tell what I've figured from the last 3 hours reading your post, bunnyboy's tutorial, and mashing through the Debugger and the Name Table.

Firstly, you're right about the palettes. Palette 0 is the one that swaps, while Palette 1 is the one with purple and orange tones that makes almost the entire logo. The exceptions are the green texts, which also use Palette 0, the one that contains this specific tone of green. Palette 2 and 3 doesn't seem to be used on this background at all.

Well, I've quite understood the way that the attribute byte is defined. I've opened a screenshot of the title screen in GIMP and set up a grid of 16x16 tiles, what would represent the Attribute Tables. Follows the picture:



The picture shows that the palettes are being loaded as:
0 0
1 1
We are messing with NES, little endian (is that right? I just know that we must swap the bytes), then the attribute byte would then be: 1 1 0 0 = %01010000 = $50
So we know which byte is being sent to this name table. We must change this $50 to a $55 (so we'll have %01010101 = 1 1 1 1 - then all the bytes of this name table would use Palette 1, the non-blinking one), right?

Now, the last thing we should figure out is the exact address of this nametable, right? I've followed your recomendation (it wasn't clear at the beginning, but I've soon figured out the reason of this address range) and set up a write breakpoint at PPU $23C0 ~ $23FF. The debugger soon halted, and I was directed to a routine very similar to the one mentioned in bunnyboy's tutorial as "LoadAttribute Loop". It would be the following:

00:8123:B1 E0       LDA ($E0),Y @ $87C0 = #$00
00:8125:8D 07 20  STA $2007 = #$00
00:8128:C8           INY
00:8129:D0 F8       BNE $8123

Each time I would hit "Run", the indexed address would increase, and the value loaded from that address could vary. I'm assuming that this indexed address is the place on the ROM where the Attribute Byte's are being stored, is this right? If so, I would be able to navigate manually to that point and simply change the expected $50 to $55, right?

Geez, took me SO long to figure this out, and I'm suspecting this final part won't be so simple. I've learn't debugging with Parasyte's tutorial, and when I've changed Samus jump value, I just made a hex search using the hex sequence found in the debugger, and not really the address found. That's why I'm assuming this supposedly address range that contains the attribute bytes in ROM (what I suspect to be $87C0 ~ $87FF, one for each 2x2 area). Oh geez, it's already past 4AM here in Brazil, I'm probably saying heavy bullshit now >.<

Please, if I said something that makes sense, point it. I'm very glad for all the help you're giving, tummai, and I hope I can finish this translaction before next monday. Vacations are near over ;P

Oh, lord.
Actually, tummai, I suspected of this NTSC issue. The reason I suspected is simple, when I opened the Name Table, I would check the X and Y position of the blinking tiles. I'm not sure about the X position, as it doesn't matter for me, but I was certain Y position was 3, counting from 0. Following this logic, the blinking tiles should be at the bottom of a 2x2 area. This is was one of the most annoying things I've faced yesterday, cos' it didn't check with the grid I was setting on GIMP. I even tried to offset 8 tiles up the grid, but it was looking too weird and then I came back to the original setting, which had the top and bottom line cropped. If I just did followed the Name Table instead of the screenshot, I would had been sucessful! At least on this part ;P


Bankswitch. I didn't knew what it was until know. Well, the moment I looked at the debugger and it was snapping data from $87C0 and forward, I understood and fine. But, I've soon remembered that the ROM is usually big enough to need more than 4 bytes to write it's size: examples came to my mind when I opened Tile Molester and went to offset like 0001F312 and such. And then I though "Geez, this $87C0 can't be the actual address in the ROM where the data is being stored". And then I was left there, without knowing HOW to access this data, except, however, by doing a hex search for B1 E0 8D 07 20 C8 D0 F8, what would lead me to the place where the routine is being stored on the ROM. As the routine uses an indexed register, I wouldn't be able to modify my unwanted attribute table using this method.


Now there's something useful. I've never used the built-in hex editor of FCEUX, as I didn't knew any applications for this. I just did knew that it wouldn't make any difference on the ROM if I just modified the values in hex editor while it was viewing the NES RAM. But now that you gave me this tip #2, I think I'll be able to finish this damned blinking effect. And of course, the knowledge I've got in this topic is imensurable.

Just one small question, it's not pertinent to my problem, but it would be nice to know one thing: each 2x2 area has a attribute byte assigned to it, right? I've noticed that, when emulating in PAL mode, we have 16x15 = 240 attribute tables, right? So it's supposed that, If I set a breakpoint for PPU $23C0 ~ $23FF, I would be able to set all these 240 attribute tables, but how, if I just have 64 bytes avaliable in this range? I mean, the loop that loads the attribute tables would run just 64 times, instead of the 240 times needed, isn't this right?
This part is still not clear in my mind. But in the meantime, I'm trying to get the modification done! Thanks so far!

EDIT - Oh, final consideration - tha data is being snapped from the offset 000147D0. I mean, it starts to be snapped from this offset on the ROM, going until 0001480F. I just need to figure out which of these bytes is the one referent to my problematic tiles, and then I think the info about 240 attribute tables and 64 addresses come into play

Oh, so there is my confusion! I think I've understood completely how it works now, see if my logic is correct:



We can use one of this smaller blocks to determine which attribute byte is being sent into this block, but the same attribute byte that is being sent into this small block is, actually, being sent to the bigger block containing it. So the adjacent smaller blocks will also follow the same palette rule that was sent to the entire block. Sounds confusing, but in the overall, I think I understood. My mistake was to think that each small block would have an specific attribute byte, where, in the truth, is each big block that receives one attribute byte and applies it on all the smaller blocks contained on it. Thinking this way, is possible to fill the 240 2x2 tile areas with only 64 bytes, since they work on a 4x4 tile area.


And the final result. Thanks A LOT tummai, I'll be sure to write all this you teached me into a doc and present it to the Brazilian community, sooner or later. Some NES addicts that are friend of mine are already curious about what I'm studying, as they could use it on their translations or hacks. Spreading knowledge (and of course, mentioning your help in my translation Read me) will be my ways of repaying all you have done for me in this thread. Oh, the result!