You need to point the PPU to the sprite RAM. Without looking I want to say:

LDA $2002
LDA #$3F
STA $2003
LDA #$00 
STA $2003

That will point it to the PPU's pallet ram. Then you upload a new pallet, or you can do something like storing $3F10 and then only change the pallets you need. Go to $3020 to upload both palettes at the same time.

3GenGames, you've confused me. The sprite palettes are in bits 0and1, not as you've specified above. Also. Couple other things I can't xo on my phone.

Do this to change the palette for sprites:
LDA $2002 ; this resets the toggle
LDA #$3F
STA $2006
LDA #$10
STA $2006

LDX #$00
: LDA myPaletteTable,x
STA $2007
inx
cpx #$10 ; $10 hex == 16 decimal
bne :-

This gets you pointing at $3F10 which is the first of the sprite palette.
It then copies 16 bytes to the sprite palette.

This assumes you are set to increment PPU by 1.

Refer to this page: http://wiki.nesdev.com/w/index.ph... and the entry that says: VRAM address increment per CPU read/write of PPUDATA

Yes, if you want to move NOT sprite 0, you skip $0200-$0203 and just move $0204 and $0207 for sprite 1.

To change the color of the sprite, you need to first of all edit the palettes that you have. There are four different palette sections for sprites. Something like this is in your document if you're using nerdy nights.

$xx,$00,$00,$00, $xx,$00,$00,$00, $xx,$00,$00,$00, $xx,$00,$00,$00 ;sprites
$xx,$00,$00,$00, $xx,$00,$00,$00, $xx,$00,$00,$00, $xx,$00,$00,$00 ;background

The first 16 bytes are the color palette for sprites. You need to write #$00 to $0202 to use the first section, #$01 to $0202 to use the second palette, #$02 to $0203 to use the third, and #$03 to use the fourth.

Of course you're going to need to change all of the values in the palette area to something other than $00 to get colors you want.

The first color in each of the 16 4-byte sections (designated here with x's) is the transparent color. Usually these all need to be the same, but I think basically whatever you have the first value set at, it will automatically make the other 7 first-bytes that same value. So don't be surprised if you try to change that color and nothing happens.

Sorry. I am touching on changing the palette since I thought he just asked that, but I guess he wants to assign the sprite a different palette. Since he is confused about the palette assigning, I'll try to help with that now:

Finally had a chance to get back on track with the lessons! Went back a bit to refresh what I had studied, but so far so good. Lesson 4 is in the bag! It's really cool to be able to change the colors on the back of Mario's head/hat. Cheers!

was that a joke?

Nope. On digitally run TV's, it will likely roll the screen. Don't use it. Use 0F.

Quoted from nesdev wiki "Note that a value of $0D should not be used (brightness=0, hue=13), as this results in a "blacker than black" color that causes stability problems on some televisions. "

That'd be it.

I'm having a trouble doing palette cycling and was wondering if anyone could help, when I change a palette color my entire background winds up pushing itself down for some reason, my lil code snip is

[code]
lda $2002
lda #$3F
sta $2006
lda #$00
sta $2006
lda #$0F
sta $2007
RTS
[/code]

before:



after code runs:



(the boxes on top are just reference points to see whats happened)

if anyone has an idea off top of their head of what would cause this please lmk

Are you only doing it in vblank? That could be because of the $2006 writes during rendering aren't the same as pointing it so memory, it affects the internal registers for such things as scroll and stuff. And also, you're only changing palette 0 there, so that'll only affect the background color 0, making it 0F, which is the right color black. For best help, post all of your code and we can point all the stuff out.

Always at the end of vblank, after all PPU updates (but still in vblank) remember to set the scroll using $2005 *and* $2000.

3GenGames: I'm gonna change more palette values, I just condensed my code down to easily show the problem

thefox thanks I'll try that out

If you want me to help, I'm online all the time, just send me a PM and I'll work with you to fix it.

Just curious, where in the PPU memory are these 64 sprites stored which you transferred via DMA, where is sprite memory located?
I thought it would be somewhere between $0000 and $2000 but the mario.chr data is stored there correct?

Sprites are in their own RAM, internal to the PPU chip. Writing them with DMA is the only reliable way to access it.

Ok then, thanks for the quick reply bunnyboy!

*Edit*
This should only be posted in the week 5 tutorial section, remove this post. I accidently posted here first, wasn't paying attention as to which week I was posting under.

Is this an acceptable way to make sprites move slower than 1 pixel per Vblank:

; Just before JMP Forever I cleared the X register.
ReadA:
LDA $4016 ; player 1 - A
AND #%00000001 ; only look at bit 0
BEQ ReadADone ; branch to ReadADone if button is NOT pressed (0)
; add instructions here to do something when button IS pressed (1)
INX ; if a press is registered for 3 Vblanks then translate the sprite.
CPX #$03
BNE ReadADone
LDX #$00 ; Once it has been moved reset the Vblank counter.
LDA $0203 ; load sprite X position
CLC ; make sure the carry flag is clear
ADC #$01 ; A = A + 3 (changed to 3)
STA $0203 ; save sprite X position (sprite moves 1 unit right).
ReadADone: ; handling this button is done

I've tried it and it works, just wondering if it's the right way to go about it.

Hmm, I can get mario to move as a whole, but I get an additional sprite moving along at the top of the screen, it appears to be a duplicate of the first sprite. Any idea why this would happen? Here is my code to shift mario across:


     LDX $00
ReadA:
     LDA $4016 ; player 1 - A
     AND #%00000001 ; only look at bit 0
     BEQ ReadADone ; branch to ReadADone if button is NOT pressed (0)
; add instructions here to do something when button IS pressed (1)
SpriteUpdateA
     LDA $0203,x ; load sprite X position with offset
     CLC ; make sure the carry flag is clear
     ADC #$01 ; A = A + 1
     STA $0203,x ; save sprite X position (sprite moves 1 unit right).
     INX
     INX
     INX
     INX
     CPX $10 ; When x=16 done all sprites.
     BNE SpriteUpdateA
ReadADone: ; handling this button is done

I do the exact same for moving left but I subtract of course But the algorithm is the same.

*Edit*
I fixed it! ah damn syntax, I didn't put a '#" before $! But I'm still curious as to why another mario sprite would appear?

It's hard to say but effectively what that code would be doing is loading a number representing each sprite's x-coordinate, adding the value stored at memory address $0001, then storing that value in the sprite's x-coordinate.

Yeah that's exactly what I thought, it is quite strange how the y-coordinate is effected by comparing the value stored at memory address $10 and not the value #$10. Especially because I am not doing anything with the addresses which hold the y-coordinates. I think it might actually have to do with how I wrote the address (even though that wasn't intended), normally they are written as a 4 digit hex value, I think that's the key, it's incorrect syntax.

Can I see your entire code? Paste it at pastebin.com, please.

I was having some issues with the palette, so I tried to run the provided code for this section as a sanity check. Unfortunately I don't think I'm getting the expected results.

When I run sprites.nes in FCEUX I get this:
http://i.imgur.com/R0VYK.png...

Here is the debug PPU viewer:
http://i.imgur.com/hO3ln.png...

Anyone know why the provided code may not be running as expected? It looks to me like some of the color palette isn't loading properly. The patterns table also looks a bit weird, but it may just be that this is the first patterns table I've looked at since I'm following along with the series.

Looks like it is running as expected. You need to change your palette entries if you want it the colors YOU want. The colors are from the chart in the first post.