This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

is the program program rom really that small?

is the program program rom really that small?
by on (#36964)
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. :shock:

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.

by on (#36965)
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?

by on (#36966)
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.

by on (#36980)
Jeroen wrote:
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! :P

(I forget the details)

by on (#37000)
Quote:
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. :lol: 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. :shock:

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:
      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

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

by on (#37025)
pizzach wrote:
The NES really isn't that forgiving of mistakes. :shock:


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. ;)

by on (#37044)
MottZilla wrote:
pizzach wrote:
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.

by on (#37061)
Well, that an VBLANK time is very long on the GBA.