Well I gave it a shot but the attributes are still way off and crazy. I update 32 tiles every 8 pixels of movement, so I updated 2 attribute bytes every 32 tiles.

I'm thinking maybe the problem is that my offset added to the location of the attribute table low byte is rolling over at some point to $00 and leaping to an incorrect part of my nametable, then writing that as the last few attribute bytes. Does that sound possible or am I just flailing in the dark here? Here is the attribute code fully commented :-)


;--DRAW 2 BYTES OF ATTRIBUTE TABLE NOW--;

;If using $28, attribute table starts at $2BC0
;If using $20, starts at $23C0
lda whichnam ;will be either $28 or $20
cmp #$28
beq attr2 ;if its not $28, it must be $20, so continue from here

lda #$23
sta $2006 ;high byte of first attribute table
lda attroff1 ;low byte offset will go from $C0 to $FF
sta $2006 ;$2006 now knows where to copy nametable data TO.

;Address of correct map location is already in $0010 and $0011 from code before

ldy attroff1
ldx #0
attr0:
lda [$10],y
sta $2007
iny
inx
cpx #2 ;only draw 2 bytes of the next attr table at a time
bne attr0
sty attroff1 ;y increments 2 bytes and gets stored for next time
jmp endattr ;SKIP over the rest of the attribute code

attr2: ;we jumped to here if it was nametable $28xx
lda #$2B
sta $2006
lda attroff1 ;can use same variable as before because it still goes from $C0 to $FF
sta $2006 ;and it was reset to $C0 after the last nametable flipped.

ldy attroff1
ldx #0
attr3:
lda [$10],y
sta $2007
iny
inx
cpx #2
bne attr3
sty attroff1 ;we are done updating the attribute table a whole 2 bytes, wow!

endattr:

;--END OF ATTRIBUTE TABLE UPDATING--;


-Pulper