I'm making a bit of progress...right now, in just trying to successfully read a hit without glitching or locking up.
I can visibly see where I'm getting a split (right now, ugly horizontal line that flickers...i'm sure that's a timing issue) but unfortunately, the bigger problem is that:
a) I get a push (like the scroll is getting messed up...can mess with that a bit later)
b) it seems like everything *above* the line is drawing from the wrong table, even though there haven't been any writes to 2000 (and even hard-writing something just before the sprite zero check doesn't help this).
Any ideas?
**** Actually, not sure what magic just happened but just going back through seemed to fix things. Huh. Ok. I think I'm right there.
********** Nope, nevermind. Here's what's happening.
(rendering is off)
Code:
;; checks game state...if not a screen where sprite 0 is drawn, skip this code
WaitSpriteNot0:
BIT $2002
BVS WaitSpriteNot0
LDA #%11000000
checkSprite0:
bit $2002
BEQ checkSprite0
;;;;;; some arbitrary numbers in a dummy loop here to try to get to the end of the scanline
;;;;; should change a color in the last sub palette.
;;;;;; this works with no issue if I don't do the sprite zero check
;;;;; so something with the sprite zero check is the problem?
DoSingColorSwap:
LDA $2002
LDA #$3f
STA $2006
LDA #$0c
STA $2006
LDA #$30
STA $2007
If I skip the sprite 0 loop and just do the single color swap, no problem. Work's just fine, for the entire screen. But with the sprite 0 hit and trying to separate the screen, the color does not change, I get *animated junk* at the top, scroll value was pshed off, and it seems that in some spots it is drawing the right value (f5, which should be a blank tile) but from the wrong pattern table. I tried different versions of the sprite zero check discussed here. All with the same result.
Currently, i am drawing sprite zero at #$d0 if it helps (and it is definitely colliding with background).