Provided you've made all the changes I've talked about, and provided I haven't told you to make a change that was messed up (which is certainly possible), I've really found about all I can while just reading the code and I cannot debug for you any other way. Whenever I end up with a problem that I absolutely cannot solve, I just rewrite it.
There are very few variables involved here.
There are only two registers that should be affecting how to scroll the nametables when your screen is being rendered. $2005, and $2000. (Well, others can affect it, but not if you write to these last.) Break on writes to them, and find out what variables are stored there. Then find the code that updates those variables and find out why it's wrong. The fact that CameraX+1 is basically never touched makes it seem like you should be checking CameraX to see if it's doing something like switching between 0 and 255. (The only way I think that the nametables could be switching that quickly without CameraX+1's help).
Edit: You know what? Try commenting out jsr draw_sprite and/or jsr FamiToneUpdate. If doing that works, you've run out of vblank time. It probably isn't FamiTone, but last time I check draw_sprite was before scroll_screen. It's tough for me to tell how much time draw_sprite would take, but if commenting it out helps it should be moved directly before or directly after FamiToneUpdate.
But at this point, if that edit isn't true, I'd honestly just rewrite it. Remove 100% of the code that affects scroll variables and scroll registers. Then rewrite them slowly, and make sure independent parts work before putting them together. I may be wrong here, but I think you're trying to write too large pieces of code at once without verifying each small part. There's no reason not to verify even tiny things. Even for stuff that doesn't have any graphical output, you can just look at RAM values in a memory viewer.
d-pad->moves character->affects scroll variables->affects scroll registers
is harder to debug than
d-pad->affects scroll variables->affects scroll registers
which is harder to debug than
d-pad->affects scroll variables
which is harder to debug than
d-pad (And I assume you already have working code to check for button presses!)
I did something like this before I made my scrolling dependent on my character.
(I was already sure my d-pad checking subroutines worked well)
Code: Select all
;variables scrollxlow, scrollxhigh
jsr p1left;If left is not being pressed
bne skipscrollleft;branch
lda scrollxlow
sec
sbc #$01
sta scrollxlow
lda scrollxhigh
sbc #$00
sta scrollxhigh
skipscrollleft:
jsr p1right;if right is not being pressed
bne skipscrollright;branch
lda scrollxlow
clc
adc #$01
sta scrollxlow
lda scrollxhigh
adc #$00
sta scrollxhigh
skipscrollright:
You can actually look at those variables being updated in a memory viewer when you press the d-pad. If for some reason it's wrong (which it may be!), you'll only have to look at <30 lines of code.
When it's right, you can use those variables to actually update the scroll registers.
At the end of the NMI...
Code: Select all
lda ppu2000;a variable that contains the same value in $2000
and #%11111100
sta ppu2000
lda scrollxhigh
and #%00000001
ora ppu2000
sta ppu2000
sta $2000
lda scrollxlow
sta $2005
lda #$00
sta $2005
If something goes wrong, I'll only have to look at <20 lines of code.
Once I'm sure that works, I can make it so the scroll variables can't scroll past a max value or min value I set. When that works, I can make it so the scroll values are only added to when the character is past 192. When I'm sure that works, I can make it so a heavy enemy landing can shake the screen a little. If at any point something goes wrong, you'll know the newest thing is what's going wrong. (Well, sometimes something new creates a situation something old handles wrong that was never tested. But then... that usually means something old wasn't as well tested as it could have been before something new was added
)
Doing this also really helps us, since we don't have to follow as much of the thread to help.
Short version: I've done about as much as I can with the info I've been given, and don't know what other info I could ask for that would help. I would rewrite it and check each
very small part before moving on. I'm almost certain it will be faster than debugging what you've got, since I am rather stumped.