Last time I talked about how to stick a palette routine in the NMI so it refreshes every frame automatically, giving us free reign to edit the virtual RAM palette for quick updates. Now I’d like to cover how to get some flashiness going in the program. This will add a bit of pizazz to things with little to no effort. For now we will work on the basics of the code, and at another time we’ll touch on portability.
Let’s first get some arbitrary numbers for our base palette laid down and decide what we would like to animate:
palette: .byte $0f,$00,$c0,$30, $0f,$00,$10,$f0, $0f,$00,$10,$30, $0f,$00,$10,$30 .byte $0f,$00,$10,$30, $0f,$00,$10,$30, $0f,$00,$10,$30, $0f,$00,$10,$30
Let’s pick that $c0 in there. We know from last time that we can change something in the palette with a simple lda to sta. Since we want to animate, we’ll pick a few colors to use so we can do more than just a single update to the palette. Let’s refer to our diagram of colors and choose what we would like to change it to:

Let’s try something fluid, like making the color go from dark to light and light to dark. How about all the $cX values there? Alrighty, let’s put those into a table. Since we want to go from darker to lighter then back again, let’s set it up like so:
pal_animation1: .byte $0c, $1c, $2c, $3c, $2c, $1c
So the way it will work is to read the bytes in, and when the last byte is reached, start over. So when we start over the $1c goes back to $0c, making a fluid wave of dark-light/light-dark. The problem is, we can’t just read them in and expect things to work out. If we just read them all in, they would just overwrite each other, accomplishing nothing! Yes, we are going to need a timer. Let’s use another one to help out the X register for now, too. Later on we will need more than this, but for now these are the only reserve bytes we will use.
anim_ticker: .res 1 anim_offset: .res 1
Let me go ahead and paste the code, then we’ll go over what it is doing.
; initialize ldx #$00 stx anim_offset lda #$0a sta anim_ticker jsr animate_that_smeg ; ------------------------------------ animate_that_smeg: dec anim_ticker bne :++ lda #$0a sta anim_ticker ldx anim_offset cpx #$05 bne :+ ldx #$00 stx anim_offset jmp @next : inx stx anim_offset jmp @next : ldx anim_offset lda pal_animation1, x sta pal_address+2 @next: rts
Well, there it is! Like I said, portability later, for now, there it is. Let’s check out what it’s doing.
We have anim_ticker initialized to $0a. We decrement that number, and if it isn’t zero, jump to the portion where we load from our pal_animation1 table. This means that the same color is getting stored at pal_address+2 10 frames in a row. Once anim_ticker reaches #$00, we then push a #$0a back into it, test if anim_offset is #$05 (because we have six different colors in our table), and if not, increment that number, then jump to the end of the routine. However, if it IS at #$05, we store #$00 back into it and jump to the end of the routine and start the whole thing over. Not too shabby!
If you need to reread that last paragraph because you don’t understand the code, then do so! It’s not really all that complicated, and is something that will make your games/programs/demos look all uh… shiny! Anywhat, the next palette stuff we will deal with will be color manipulation. It will utilize this same code above as well, so, be ready!







Does this work with NESASM?