is the program program rom really that small?

[pizzach]

Hi guys! I'm new here!

I have been poking around NES programming for the first time this last week. Mapper 0 has been nice because it is so simple. Today my graphics started glitching if I add around two to three new lines of code. I know haven't been especially careful about optimization yet, but still I was a bit surprised it was so fast hitting the limit in program size.

Super Mario Bros must have been using some mad optimization right? I managed to implement left/right scrolling, left/right movement/ and hit detection for the right side. I'm a bit baffled how Nintendo managed to stick so much into such a small cart.

[tepples]

If your code is updating the VRAM, then a glitch as you add lines of code might mean you're exceeding the vertical blanking interval. Does the problem disappear if you change your NES emulator to PAL mode?

[Jeroen]

Ya cause really your compiler usually tellls you when you exeed program size. AND most emulators do this to. So ya you're probably exeeding vblank.

[atari2600a]

Ya cause really your compiler usually tellls you when you exeed program size. AND most emulators do this to. So ya you're probably exeeding vblank.

Compiler?

Anywho yeah sometimes what seems like at the time the weirdest writes can cause graphical glitches. I once accidentally got this waterfall effect on my background from what seemed at the time a perfectly logical $2007/$2008 write!

(I forget the details)

[pizzach]

Anywho yeah sometimes what seems like at the time the weirdest writes can cause graphical glitches. I once accidentally got this waterfall effect on my background from what seemed at the time a perfectly logical $2007/$2008 write

I know what you mean atari2600a. Fighting to get backgrounds working and then getting them to scroll and split correctly took a lot of trial and error. The NES really isn't that forgiving of mistakes.

Anywho, thanks for the quick reply Jeroen and tepples! I currently use the old perl version of p65 and test using fceu. (p65 gave me the least problems on my linux box.) I am not sure if it's a vblank problem or not in my code. I did some code cleaning/optimization and bought myself some more time before problems started again. Now if I add another line, in stead of the screen glitching, the collision logic starts acting funky.

I made a small effort to make sure the important graphical updates come first in my vblank loop. It seems like adding code to the start/reset function is asking for threading type problems so I have avoided it. Im going to post the main code for my vblank loop (it isn't too long)

Code: Select all

		lda busy ;skip if the previous vblank didn't complete (frame dropping)
		bne irq


		lda #$01
		sta busy

			;set tile loading vertical (increment of 32)
			lda #%10001100
			sta $2000
				ldy column'pointer	;column
				ldx #0	;screen
				stx target'viewport
				jsr load'tile'column
		
				ldx #4	;screen
				stx target'viewport
				jsr load'tile'column
			lda #%10001000
			sta $2000

			inc timer
			jsr scroll'screen
			jsr update'sprite
			jsr react'to'input

			;Split the screen for a non-scrolling section
	*		lda $2002  ; wait for sprite 0 collision
			cmp #%00100000
			beq -
			lda #$00 
			sta $2006  ; Reset VRAM
   			sta $2006
			sta $2005  ; Scroll X
			sta $2005  ; Scroll Y

			jsr detect'collision;

		lda #$00
		sta busy

[Disch]

Sprite zero hit is bit 6 (%01000000). You're checking bit 5 (%00100000) which is sprite overflow.

[MottZilla]

The NES really isn't that forgiving of mistakes.

I think you mean, Computers aren't forgiving of mistakes. They only do what you are telling them to do, it's your job not to tell them to drive off a cliff.

[tepples]

The NES really isn't that forgiving of mistakes.

I think you mean, Computers aren't forgiving of mistakes.

Unless pizzach meant "compared to something like the GBA". On the GBA, you usually don't have to worry about exceeding vblank time because the VRAM is dual-ported and everything else (HDMA, audio) can be double-buffered.

[Dwedit]

Well, that an VBLANK time is very long on the GBA.