Problem with nestest

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

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?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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?
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

http://wiki.nesdev.com/w/index.php/Full_palette_demo
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.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

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
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

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.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

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"
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

The period is the time between occurrences. On NTSC, the VBL period is 89342 pixels when rendering is disabled.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

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).
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

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?
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

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

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)
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

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.
Post Reply