tokumaru, on page 43, wrote:
Setting the scroll should ALWAYS be the very last thing in your VBlank handler.
This is not true for our game.

The end of my VBlank handler looked something like this:
Code:
jsr update_vram
;modify the flag
inc FrameReady
SkipUpdates:
jsr FamiToneUpdate
;"Setting the scroll should ALWAYS be the very last thing in your VBlank handler." -tokumaru pg 43
lda needscroll
beq +end
lda FORWARD_scroll
beq +
jsr scroll_screen
jmp +end
+ jsr scroll_screen_left
+end ;return from the NMI (vblank)
pla
tax
pla
tay
pla
rti
Now, after being blessed with fixing a lot of the problems we found, I turned on the music and the screen started being lowered two rows (16 bits) whenever draw_our_column was being called. And that reminded me of tepples' guidance, that
t gets clobbered everytime $2006 and $2007 are written to and so I should be sure to write $2000 and $2005 afterwards to fix
t (his post is linked to at top of page 91). After checking, it was clear that $2000 and $2005 were being written to, inside a scroll_screen, every frame $2006 and $2007 were being written to, somewhere inside update_vram, and so it seemed that
jsr FamiToneUpdate was taking too long. So after finding
this earlier advice from tokumaru also on page 43 I tried moving
jsr FamiToneUpdate to a spot right after
+end because it doesn't include PPU operations. The game works and the screens don't lower 16 pixels for instances after draw_our_column is called inside update_vram while the music is playing!!

edit: tokumaru, I understand now that there was a hidden reason behind your words that are quoted above... posted this to help others who read your quoted statement.

I really respect you tokumaru; thank you so much for all of your fantastic help and ideas!

edit3: changed a "to" to "too" and changed text referring to page 92 to refer to page 91. Two mistakes corrected
