NTSC and sprite 0 hit

[Anes]

I did it. I get the right cc for the next instuction so i run first the PPU and THEN the CPU. The thing is that now Blargg's Nmi Timing Test thow me error #2... i can't fix it

[Zepper]

There's only 1 annoyance/hack I use but the following info is ok.
My PPU goes from 0 to 19 (VBlank), 20 (pre-render scanline), 21-260 (visible lines), 261 (dummy line).

1. NMI shouldn't occur if VBL is clear. I set a flag at PPU line 261 dot 341, and check it on the next clock (PPU line 0, dot 1) ~ if this flag was cleared (by reading $2002), NMI is ignored.
2. Reading $2002 cancels the NMI.
3. Writing to $2002 triggers an NMI only if $2000:$80 goes 0->1, and VBlank flag is true and NOT on PPU cycle #0.

*ONE* annoyance I couldn't figure out ~ if (1) occurs when the PPU has exactly 3 cycles to execute, the NMI must be acknowledged; otherwise, no.

* I think that a topic split is needed.

[zeroone]

Delaying the sprite zero hit enable flag time. Well, does your emulator pass on sprite zero hit test rom?

One test is failing: 10.timing_order.nes, #7 Lower-left corner too late.

With a delay of 2 PPU cycles all tests pass, but the status bar ends up shaking in Bart vs Space Mutants. I'd rather have a real game working even if the timing test fails; it's the lesser of 2 evils. I don't know how the test performs it's timing. What is it using for start and end time? The time reference point in my emulator maybe off. Not to mention that I added cycles to the NMI and IRQ.

On a side note, the status bar appears to shake in your emulator.

More importantly, is there supposed to be a delay of 3 PPU cycles between the dot that discovers the sprite 0 hit and the dot that actually sets the flag? The wiki is still unclear about this.

Hmm... so you catch all the CPU cycles in a full instruction, and runs the PPU for that amount x 3. Well, let's see ~ a sprite hit will be always missed in that instruction, because reading $2002 occurs before clocking the PPU, and the value is ORed with $40 after that read. ... Short answer: you're running the PPU after a full instruction (correct?), so there's a huge chance of missing PPU events. I might be wrong, but try to get the number of required CPU cycles for the next instruction, and runs the PPU for that amount.

Unfortunately, that concept works both ways. If instruction execution is atomic, then the PPU and CPU will be out of sync by +/- one instruction time. For instance, the CPU can change the CHR ROM bank index mid-scanline, which will cause an issue if it runs too early or too late. Similarly, the PPU can set a flag that is read by the CPU too early or too late. On another thread, it was suggested to advance the CPU only to the next read/write cycle as opposed to using atomic instructions. This could be accomplished with a second cycle count table.

[Anes]

The thing is, how to i mix atomic execution and cycle execution??

[Zepper]

Irrelevant.
It's all about emulation. Just follow what I told you.

[zeroone]

I started studying the FCEUX code to try to understand how it avoids the delay hacks that I needed to introduce to make certain games work. Apparently, it actually uses a lot of similar hacks. For example, for MMC3, they put the following code directly into their PPU implementation:

Code: Select all

if (((PPU[0] & 0x38) != 0x18) && s == 2 && PPUON) {
					//(The MMC3 scanline counter is based entirely on PPU A12, triggered on rising edges (after the line remains low for a sufficiently long period of time))
					//http://nesdevwiki.org/wiki/index.php/Nintendo_MMC3
					//test cases for timing: SMB3, Crystalis
					//crystalis requires deferring this til somewhere in sprite [1,3]
					//kirby requires deferring this til somewhere in sprite [2,5..
					//if (PPUON && GameHBIRQHook) {
					if (GameHBIRQHook) {
						GameHBIRQHook();
					}
				}

That s == 2 check means that the IRQ counter won't be clocked until the third sprite is loaded. The effect is a delay of 5 CPU cycles for NTSC.

[Zepper]

I wonder about (PPU[0] & 0x38) != 0x18, as ignoring both background and sprites enabled, plus the extra sprite 8x16 bit. Just weird.