nesdev.com
http://forums.nesdev.com/

Problem with nestest
http://forums.nesdev.com/viewtopic.php?f=3&t=7051
Page 4 of 4

Author:  Vash [ Fri Nov 12, 2010 6:23 am ]
Post subject: 

Thanks for your help. I passed the cli latency test but now I have a problem with 01-vbl_basics. It says : "VBL period is too short with BG off".

I've read form the wiki that when BG is off, the complete frame is one ppu clock shorter. So instead of being 341*262=89342 PPU clocks, it should be 89341.
As it says that VBL period is too short and not too long, I don't get it.
My VBL period is 21 * 341 = 7161 PPU clocks. Even when I put it longer, it doesn't work.
Anyone sees what I'm missing here?

Author:  tepples [ Fri Nov 12, 2010 8:22 am ]
Post subject: 

Vash wrote:
I've read form the wiki that when BG is off, the complete frame is one ppu clock shorter.

Which page on the wiki says this?

Author:  Vash [ Fri Nov 12, 2010 8:41 am ]
Post subject: 

http://wiki.nesdev.com/w/index.php/Full_palette_demo

Quote:
The PPU has two frame lengths, short and long, and an internal flag that toggles every frame and determines whether the frame will be short or long. A long frame is 341*262 PPU clocks, while a short is one PPU clock less. The missed clock occurs around the end of VBL, and only if rendering is disabled.

Author:  thefox [ Fri Nov 12, 2010 9:18 am ]
Post subject: 

Yeah, that's a typo, it should be "and only if rendering is enabled." as can be seen here: http://wiki.nesdev.com/w/index.php/PPU_frame_timing

Author:  blargg [ Fri Nov 12, 2010 10:02 am ]
Post subject: 

BTW, this error on that page is a perfect example of why I hate duplicating information; it leads to inconsistencies. My advice: if a page is describing a palette demo, don't take anything it says about anything other than the palette demo as fact, merely a suggestion of what you might find documented elsewhere.

Author:  Vash [ Fri Nov 12, 2010 10:58 am ]
Post subject: 

Yes you're right but when I searched "vbl period" in the wiki, this page is the only one returned.

So the VBlank length is :
- 6820 ppu cycle when BG is off.
- 6820 ppu cycle when BG is on with an even frame
- 6819 ppu cycle when BG is on with an odd frame.

But even when I put a bigger number, I still got this error : "VBL period is too short with BG off"

Author:  blargg [ Fri Nov 12, 2010 11:12 am ]
Post subject: 

The period is the time between occurrences. On NTSC, the VBL period is 89342 pixels when rendering is disabled.

Author:  Vash [ Fri Nov 12, 2010 12:04 pm ]
Post subject: 

It's 89342 ppu cycle so it's 29780.66 cpu cycle.

It's still not working.
Here is what I do : every 29780.66 cpu cycle, $2002.7 is setted to 1 to indicate the start of VBlank. It's also the case with BG on with even frame. For an odd frame with BG on, $2002.7 is setted every 29780.33 cpu cycle (minus one ppu cycle).

Author:  blargg [ Fri Nov 12, 2010 12:39 pm ]
Post subject: 

First, saying it's "not working" is not as useful as describing the symptoms. Do you mean "it's still giving the same error"?

What happens if you increase it by 10 cycles? Decrease by 10 cycles?

Author:  Vash [ Sat Nov 13, 2010 6:22 am ]
Post subject: 

I have tried to increase the number of cycles and from 29780.66 cpu cycle to 90374 cpu cycle, I have the "VBL period is too short with BG off" error. Then at 90375 cpu cycle, I have the "VBL period is way off" error.

Here is my main loop to show you how I do it :

Code:
numberOfCyclePerFrame = getFrameCPUCycleLength();
if (m_cpuCycle < numberOfCyclePerFrame)
{
      executeInstruction(&m_cpuCycle);                                                              
        numberOfCyclePerFrame = getFrameCPUCycleLength();

               
      if (ppuCycle>= 6820 && vBlank)
      {
            clearVBlank();
            vBlank = false;
      }
               

      //NMI
      if(launchNMI())
         NMI();

      //IRQ
      if(launchIRQ())
         IRQ();

      //reset previous cycle count
      previousCycle = m_cpuCycle;
}
else
{
      //reset the number of cycle
      m_cpuCycle = m_cpuCycle - (int)(numberOfCyclePerFrame/3);

               
      setVBlank();
      vBlank = true;

      //reset the ppu cycle counter
      ppuCycle = m_cpuCycle * 3;
}


Basically what I do is execute instructions for 29780.66 or 29780.33 cpu cycles (depending on the BG and the even/odd frame). Once the number of cycles passed, I reset $2002.7 to 1 (cause it's the start of a new frame so it's the vblank). At 6820 ppu cycles , I put $2002.7to 0 because it's the end of the vblank (20 scanlines after the start : 20 * 341)

Author:  blargg [ Sat Nov 13, 2010 9:32 am ]
Post subject: 

What units is numberOfCyclePerFrame in? The if makes it look like it's in cycles, but the part where you divide it by 3 makes it look like it's in pixels. At this point, you're probably going to have to write your own logging so you can get things basically behaving correctly. Once an emulator gets too far incorrect, a test ROM can't make much sense of what it's doing.

Page 4 of 4 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/