The problem with this is that there is no guarantee that the person using an emulator isn't using a joypad.

I've been working on this for the last five hours and am not getting anywhere, blah. I'm trying to change the attribute of a background tile to use a different color palette. Maybe I'm failing at googling the correct terms but I can't seem to figure out an easy way (or even a hard way) to find the code in the ROM hex editor to change them. I can find the code in the PPU memory no problem. This has all been done in FCEUX 2.2.2. Maybe there is a more straight forward program to handle this task?

Some of my resources (for my later reference):

http://archive.rpgclassics.com/su...
http://badderhacksnet.ipage.com/b...r-floppy&Itemid=7
http://nesdev.com/NESprgmn.txt...
http://gilgalad.arc-nova.org/docs...
http://www.thetechnickel.com/vide...

Well, this seems to be more of a hacking question. I'm not sure what game you are hacking, but if you know what is happening in the PPU at the time, have you tried putting a conditional in the debugger that matches where you want it to change? For instance if it is address $23c9 that you want to change, and you know what it is already, put the conditional of $23c9 == #170. The 170 would be whatever you know it is at this point. It'll probably snap somewhere in NMI if it is loading on the fly, and that will show you where it is loading from, which will probably be somewhere in RAM. After you find out where it is loading from, then you can change the conditional to match the address in RAM, which will probably allow you to find where it is loading from.

I've tried that but perhaps I am going around it the wrong way? Or maybe I just don't know how to effectively read the debugger.

If I put in the conditional for address $23CC, A == #00, it'll snap and I'll have this read out:

00:F1BB:8D 00 20 STA $2000 = #$10
00:F1BE:A9 20 LDA #$20
00:F1C0:8D 06 20 STA $2006 = #$CC
00:F1C3:A9 00 LDA #$00
00:F1C5:8D 06 20 STA $2006 = #$CC
00:F1C8:A2 04 LDX #$04
00:F1CA:A0 00 LDY #$00
00:F1CC:A9 24 LDA #$24
00:F1CE:8D 07 20 STA $2007 = #$00
00:F1D1:88 DEY
00:F1D20 FA BNE $F1CE
00:F1D4:CA DEX
00:F1D50 F7 BNE $F1CE
00:F1D7:A9 23 LDA #$23
00:F1D9:8D 06 20 STA $2006 = #$CC
00:F1DC:A9 C0 LDA #$C0
00:F1DE:8D 06 20 STA $2006 = #$CC
00:F1E1:A0 40 LDY #$40
00:F1E3:A9 00 LDA #$00
>00:F1E5:8D 07 20 STA $2007 = #$00
00:F1E8:88 DEY
00:F1E90 FA BNE $F1E5
00:F1EB:60 RTS -----------------------------------------
00:F1EC:8D 06 20 STA $2006 = #$CC
00:F1EF:C8 INY
00:F1F0:B1 00 LDA ($00),Y @ $0336 = #$B3
00:F1F2:8D 06 20 STA $2006 = #$CC
00:F1F5:C8 INY
00:F1F6:B1 00 LDA ($00),Y @ $0336 = #$B3

That's happening while NMIs are turned off and filling an entire nametable. One problem I see with what you want to do is that it seems to be using the first palette for all of the background, since it is LDA #$00 STA $2007 and does it for all 64 bytes of the attribute table (the LDY #$40/ DEY / etc). You'd need to find a way (and find room) to make some sort of subroutine that writes what you want in a specific place before the screen is turned back on.

Ok, that kinda makes sense. The entire background is using the first palette. I guess I am stuck with that for now at my skill lvl! Thanks for the feedback!

Alright, another hard to ask question (the hard part being the wording, no clue if I am using byte correctly for example).

After the color palettes for a level I am hacking, I get a bunch of attributes for the background. In the hex editor, I'll see:

... 23 E1 03 88 00 88 23 E9 ...

Now $23E1 corresponds to one the 32x32 attribute areas on the background, 23E9 will be another one.

The bytes 88 and 00 on the bit level would represent the color palettes used for each quarter of the 32x32 attribute area.

So the only byte here I don't know what it does is the 03 byte. The first 88 contains the attributes for the $23E1 attribute area and the 88 and 00 are for other attribute areas, so I assume that the 03 byte defines which attributes areas the 00 and second 88 palette attributes belong to (relative to 23E1)?

Anyone able to point me in the direction of what makes up the byte immediately following the attribute area (the 03 in this case)?

I obtained all my knowledge about all this from this article (for my reference really): http://badderhacksnet.ipage.com/b...

I'm having a strange issue regarding controller input. Recently, I tried redoing my controller reading code to match the one in the Nerdy Nights subroutines tutorial. For the most part, it works as it should, but every time I press left the game crashes. Nothing I change in my code makes a difference and I have no clue what could be causing it, as it for some reason only does this when I press left. Any ideas?

Your engine is doing it, not the subroutine, I'd hope. Post the controller code.

EDIT:  I have actually fixed the problem.

Well, what does LDA buttons1 do, when you LDA right after it?

And the problem doesn't seem to be that code otherwise, I'd check to see what else reads from that memory location, and see the difference between builds.

LOL, right before I replied.

I have a little problem...
I wanted to save some space on my title screen so I came up with this little routine. However, all it does is that it makes my background flash. Does anyone know what the problem is?

That's a confusing ass loop.  I gave up.

If you can't solve it, I guess I'll have to come back to my old loop then

This is probably a Obscure Question and pretty sure it's been answered in Nerdy Nights but,
I wan't to change the controls from A and B to the Left and Right on the D-Pad. But i have completly no clue how and Nerdy Nights currently didn't help. I was wondering how to do it but (obviously) it's difficult to make it possible.

You need to take the button they check for on that part of the engine and change it. Start by working back from controller readying with $4016 and $4017, and see where they store the variables. Then find the one they use in the engine, and just fiddle with them and see which action each check handles. Then, change the button they check for from the L/R buttons to A/B. Anything more than that needed help/explaination, might as well be asking us to do it for you honestly. Not that there is anything wrong, just don't expect results tbh.

What part of Nerdy Nights are you at?  If you get to one of the later lessons, it starts using different controller code.

Can you post what controller code you're currently using?

It doesn't really matter anymore now, I've figure it out. I'm sure i'll ask more questions here in the future. 

I'm on Nerdy Nights week 2 and I want to know what's meant by 8 sprites per scanline. What exactly are sprites? Are they tiles or are they groups of tiles?

A scanline is a single horizontal row of pixels.  Sprites are objects that are independent from the background.  When you think of sprites, think of moving bullets or walking enemies.  Each sprite can be either 8x8 or 8x16 pixels.  For general size reference, in Super Mario Bros, the "?" block is 16x16 pixels.

So, the 8 sprites per scanline limit means that if you place 9 sprites overlapping the same scanline, the 9th will not be visible.  Certain games use tricks to cycle sprites causing flickering when there are more than 8 sprites on a scanline. This way you will still be able to see the object without it completely disappearing.

Typically it's just a single "tile," as most games don't use the 8x16 sprites.

Also, can we get this thing re-stickied?

Still, many games use 8x16 sprites. Battle City, Super Mario Bros. 2 and 3, Contra, and so on.

I see what you are doing. You are using $FF as a flag in the table to jump to the "Black_Loop" loop. The number after $FF in the table is the number of times that "Black_Loop" is supposed to write tile $00. So in the title table, $FF will tell the loop to start and it will run $42 times. X Increases to 2 and now the "Write_Title_Tile" loop is enabled which writes tiles:
$1D,$0D,$19,$1C,$0F,$00,$00,$30,$31,$32,$33,$34,$35,$36
  .db $37
to the background. Then $FF hits again, "Black_Loop" is enabled, and tile $00 is written $03 times. This continues for the rest of the table.

The only thing I can see is that you are ending the table with $FF,$33 which is in the "Black_Loop". However, your code exits the loop in the "Write_Title_Tile" loop.

Write_Title_Tile:
  STA $2007             ; write to PPU
  INX                   ; X = X + 1
  CPX #$FA              ; Compare X to hex $FA <--Exit Loop when X equals #$FA
  BNE LoadTitleLoop ; Go back to LoadTitleLoop if it's not equal

Since you start the Write_Title_Tile loop with writing to the PPU, this could wreck the entire loop if there is nothing in the table for it to write after $FF,$33.

Hope that makes sense.

Also, I don't know if X is equal to $FA during the Write_Title_Tile. I figured up that you have $FB tiles, so that means that $FF in the Title table would be X=$FA. Although, my math could be wrong.

I honestly don't think you are exiting your loop.