Typically, animation is handled by a RAM address for the animation frame (generally
$1602). You can then multiply this value by the number of tiles per frame in order to get indices to tables containing the data for each tile.
For example, if you had a 64x64 sprite (16 tiles), your animation routine would look something like this:
Code LDA $1602,x ; do some binary math here to multiply by 16
ASL #4
PHX
TAX
LDA #$16 ; number of tiles to write
STA $0F
.tileLoop
LDA $00
CLC : ADC XOffs,x
STA $0300,y
;... (likewise for other bytes)
INY #4
INX
DEC $0F
BNE .tileLoop
PLX
; done! jsl to $01B7B3 now
RTS
XOffs:
db $00,$10,$20,$30 ; frame 0 (notice there are 16 bytes)
db $00,$10,$20,$30
db $00,$10,$20,$30
db $00,$10,$20,$30
db $00,$10,$20,$30 ; frame 1
db $00,$10,$20,$30
db $00,$10,$20,$30
db $00,$10,$20,$30
;...
For unusual tile counts, you have to get a bit creative with your numbers by combining bitshifts (ASL) with adding copies of $1602. For instance, to multiply by 12 (which has a binary representation of 1100):
Code LDA $1602,x
ASL ; multiply by 2 (x -> 2x)
CLC : ADC $1602 ; add one copy (2x -> 3x)
ASL #2 ; multiply by 4 (3x -> 12x)
If you compare the binary representation with the math here, it might make sense how you get to that (1 -> 10 -> 11 -> 1100). Of course, for numbers with a lot of bits set (e.g. 0x2F), it'll just be faster to actually throw it into the SNES's multiplication registers.
Professional frame-by-frame time wizard.
YouTube -
Twitter -
SMW Glitch List -
SMW Randomizer