A new PPU timing quirk (?)

Dwedit · Post by **Dwedit** » Wed Oct 26, 2011 9:57 am

I bet Blargg will flip out.

Bregalad · Post by **Bregalad** » Wed Oct 26, 2011 10:08 am

I'm not sure what you are talking about. What does exacly means "a master cycle is skipped" ?
Also does anything "bad" happens when you poll $2002 ?

cpow · Post by **cpow** » Wed Oct 26, 2011 10:31 am

thefox wrote:The quirk happens consistently (on some PPU-CPU synchronizations) for example in cases where a program polls $2002 for vblank or sprite 0 hit. Programs that don't read the registers during rendering are also consistently stable, so I doubt my test rig is faulty.

Doesn't this actually *shift* the PPU-CPU synchronization if the PPU delays for one master-clock cycle when this happens?

tokumaru · Post by **tokumaru** » Wed Oct 26, 2011 10:35 am

Let me see if I got this right: when you read from PPU registers during rendering it slightly screws up the frame's timing? Weeeeeeird...

How could we possibly use this to our advantage? Does it change the color blending or dot crawl in any way?

thefox · Post by **thefox** » Wed Oct 26, 2011 10:46 am

cpow · Post by **cpow** » Wed Oct 26, 2011 10:59 am

thefox wrote:HSync takes care of syncing every scanline so the slight differences in timing aren't really visible. Maybe in some extreme case with very carefully placed reads a scanline could be shifted/stretched a little bit horizontally...

I was hoping HSync would come into the discussion because I was having a hard time figuring out how the thing works at all with this quirk and the [probably massive] proportion of games that spin-lock on sprite-0 hits.

ReaperSMS · Post by **ReaperSMS** » Wed Oct 26, 2011 12:37 pm

This is with signaltap clocked from the 21MHz master?

I was going to say that it could just be clock jitter, or a side effect of synchronizing the signal, though that shouldn't manage to shift the scanline timing, short of causing the python script to miss a line here or there.

For my purposes, I'm going to go with a "oh hell no" approach for emulating this. The monitor I'm hooked up to rejects any jitter at all in the hsync rate.

thefox · Post by **thefox** » Wed Oct 26, 2011 12:48 pm

thefox · Post by **thefox** » Wed Oct 26, 2011 1:46 pm

MottZilla · Post by **MottZilla** » Wed Oct 26, 2011 1:52 pm

I'll give it a try.

Update: Sorry, there is no visible difference, even up close. I use a Sony PVM CRT with standard composite video from a standard US Front Loading / Toaster NES.

Do you think the revision of CPU or PPU chips is related to this effect?

Dwedit · Post by **Dwedit** » Wed Oct 26, 2011 2:02 pm

Should make it triggered by pressing A, not swapping roms. That would make it easier to see any differences.

MottZilla · Post by **MottZilla** » Wed Oct 26, 2011 2:29 pm

I agree, but I'm still pretty certain I saw no difference. And no effect as suggested that occurs.

thefox · Post by **thefox** » Wed Oct 26, 2011 3:52 pm

bigjt_2 · Post by **bigjt_2** » Wed Oct 26, 2011 5:15 pm

Okay so this thread's timely. I was just about to post a thread asking about an unnerving problem I discovered last night on my project where NMI is seemingly interrupting itself!

I've produced two log files from Nintendulator, both showing an instance where the NMI interrupt seems to happen at scanline 250, cycle 233. That's right, in both instances where I captured this bug it even happened in the same cycle. My NMI handler had not completed by this scanline and was still about a dozen or so lines away from RTI. This didn't happen in the same exact part of the code, however (the second time I captured it, it happened several frames after the first time I captured it) but when it did happen both times it was right at SL 250, CYC 233.

My code does read $2002 to wait for vblank A BUNCH - mostly when initializing new stages and loading new palettes, etc. Am I understanding what thefox is talking about here and is this the same kind of situation?

nesdev.org

A new PPU timing quirk (?)

A new PPU timing quirk (?)

Re: A new PPU timing quirk