Code only runs when 'looking' at it

[Sanchezman]

I almost titled this post "Schrodinger's Breakpoints". Anyway:

In my current project, once the player loses, they need to press start to go back to the main menu and reset everything. The code for this is just a copy of the reset vector (sans waiting for 2 vblanks, and overwiting the stack.). Here's where things get odd. Whenever this code is supposed to run, it never does, but when I set breakpoints in places where the code SHOULD write were it to run, it works perfectly. I thought that it might be an issue with the outdated fceuxdsp 1.07 that I was using, but running it on newer emulators also fails to reset things properly.

heres the code I run:

Code: Select all

                                ...stuff here to check to see if I am pressing start

;/ Clear the RAM
				lda #$00
				ldx #$00
		@ramloop:
				sta $0000 , x
				sta $0200 , x
				sta $0300 , x
				sta $0400 , x
				sta $0500 , x
				sta $0600 , x
				sta $0700 , x
				inx
				bne @ramloop
	;\
				
				lda #$00	;. Disable Rendering
				sta $2000
				sta $2001
				
				jsr initialize_sound
				jsr initialize_vars
				jsr initialize_graphics
				
				lda #%10000001
				sta $2000
				lda #%00011110 ;. Show the background & the sprites
				sta $2001

                                jmp endInput

[Kasumi]

Whenever this code is supposed to run, it never does, but when I set breakpoints in places where the code SHOULD write were it to run, it works perfectly.

So are execute breakpoints firing for this code? I'd check that if you're only checking for writes. And I can't see a problem with what you've posted. How are you checking if start is pressed?

Also, why not just do jmp reset? You don't save much time by not doing the other stuff.

Edit: That... would sort of a be a bandaid, though. Why does RAM need to be cleared at all just for returning to a menu? What's your main loop look like?

[Sanchezman]

And I can't see a problem with what you've posted. How are you checking if start is pressed?

While I was about to answer this question, it made me realize the issue: My code relies on a start flag detecting if the start button is being pressed. If the flag is set, then the start button has not been released since the last time it was pressed. When I reset the RAM, I reset the start flag. With the debugger open, this was not an issue, since I can't be pressing the start button at the same time that I step through the code. Without the debugger, the game reset so fast that I didn't have time to let go of the start button before the main menu opened. It blasted through the menu so quickly that I was back in the game where I left off before I knew what had happened.

Thanks!

[tepples]

One way to prevent this is to always use the same subroutine to calculate newly pressed keys (new_keys = cur_keys & ~last_keys). I do this at the end of my controller reading code.