I bet Blargg will flip out.
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 ?
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?
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 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.
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.
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?
Should make it triggered by pressing A, not swapping roms. That would make it easier to see any differences.
I agree, but I'm still pretty certain I saw no difference. And no effect as suggested that occurs.
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?
You get two NMIs whenever you write to register 2000 to enable NMIs, and you haven't already cleared the VBL flag by reading from 2002. Nothing weird there.
thefox wrote:
Most likely reason for your problem is that you're toggling (0->1->0) the top bit of $2000 (the NMI enable bit) somewhere in your NMI handler. You can read more about this here:
http://wiki.nesdev.com/w/index.php/NMIEasiest way to fix it is to read from $2002 at the beginning of the vblank to clear the vblank flag.
That seemed to do the trick. Thanks again, sir!
Front-loading NES, PowerPak, three power cycles each with several resets, no repro. I know the A button is working because it works in the PowerPak menu, but there's no twitching and no effect of pressing A. Should I open the NES and read off the CPU and PPU revision numbers?
Then, should we summon Blargg?
thefox wrote:
Here's a one more version, I replaced the grid with vertical lines:
http://thefox.aspekt.fi/ppu-grid-twitch3.nesI tried this on my unmodified PAL NES and I saw the "effect" there as well, it was less pronounced though (which would make sense, since on PAL NES one master clock cycle corresponds to only 0.2 pixels compared to NTSC's 0.25).
EDIT: I'm going to write a better test for this matter later today.
It is possible that if the PPU-CPU alignment is a certain way that the CPU reads always hit in the "sweet spot", whatever that might be, that the PPU doesn't incur this extra cycle.
I'm thinking out loud here:
There's 3 PPU-CPU alignments for NTSC. Lets assume the CPU can be in one of two states, namely "reading from $200x", and "NOT reading from $200x". In my diagram, "R" means Read, "L" means Latch address (PPU during rendering). CPU states are "+" for "reading from $2002" and "-" for "NOT reading from $2002".
The following diagram represents a BIT $2002 as found in thefox's code.
Code:
Alignment 1:
PPU LRLRLRLRLRLR
cycle 0123456789AB
CPU RRRRRRRRRRRR
cycle 000111222333
state ---------+++
Alignment 2:
PPU RLRLRLRLRLRL
cycle 0123456789AB
CPU RRRRRRRRRRRR
cycle 000111222333
state ---------+++
The above shows that there's really only two PPU-CPU alignments to be concerned about. Namely "CPU read from $200x starts in the PPU's Latch cycle", and "CPU read from $200x starts in the PPU's Read cycle"
If we assumed the "sweet spot" is the address-latching cycle of the PPU during rendering...does it hold up? I see thefox's code uses:
Code:
BIT $2002
BIT $2002
BPL $FB
Break that down to CPU cycles:
Code:
* *
RRRRRRRRRRR
01234567890
1
The *'s indicate where the CPU reads from $2002 for one CPU cycle, 3 or 3.2 PPU* cycles in length. We see that the above code sequence is an odd-number of CPU cycles in length [for the most part...the final BPL will be 2 cycles not 3], so this means that the CPU reads from $2002 should oscillate with respect to PPU cycles. Every-other CPU read of $2002 will "start in the PPU Latch cycle", or "start in the PPU Read cycle".
So it seems the "sweet spot" theory doesn't hold up, if it's true that the effect is sometimes present, sometimes not. The structure of the code is such that the "sweet spot" should be occasionally hit--it's an odd number of CPU cycles long.
Perplexing...and fun!
Sorry for the double post...
thefox: can you post a photo of what "the effect" looks like? If it's true that HSync resynchronizes things I would expect the effect to show up somewhere in the middle of the scanline, given the number of CPU cycles it should take to cause enough reads to cause a visual shift. Or, does "the effect" show immediately on the left edge?
Are you really going to notice any artifacts from this kind of thing when TVs themselves distort the picture so much? Screens blinking between white and black move all the other pixels around.
Dwedit wrote:
Are you really going to notice any artifacts from this kind of thing when TVs themselves distort the picture so much? Screens blinking between white and black move all the other pixels around.
That's why I asked him to post a picture of it. It could be there's just an increased amount of Paranormal Activity in his region of the world at present.
Sorry but I had to write this:
You are beginning to see the Matrix!
I just gave the ROM a whirl on my NTSC NES with my PowerPak. I tried it several times, with several resets each time. I didn't see anything. The picture comes in crystal-clear on my CRT, so I don't think I'm missing anything.
What ever happened to the PPU visual project or the people working on it over at virtual6502? That'd be an amazing thing right now to help see what this does and is all about.
I've also received news that the person who normally does the chip depackaging/delayering/photography for Visual6502.org has been abnormally busy for the past several months and does not expect to have any free time until early next year, so in all likelihood there will be no further progress on the Visual 2C02 for quite a long time.
Do you know what your CPU and PPU revisions are on the system you are seeing this effect on? And do you have another system of a later or earlier revision to try it on? Have you been able to try a different TV?
How many test cases are there (just out of curiosity?)
There are at least 4 models/revisions of NES consoles right? Should NOACs be in there too?
Also, traditional TVs, CRTs, DLP and LCD monitors
Also PAL and NTSC output (not sure if NTSC-J counts)
I mention screens and signal format in case this is an artifact of how the output is generated rather than the code itself. Disclaimer: I'm talking way over my head. I wouldn't know a NOP from a NAP.
I just see a constant dot pattern, and pressing the A key have no effect, nor pressing the power button or trying again.
I tried this with my Power Pak and not directly in a devcard however.
Yes. This is a latter revision toploader NES, so it has a "modern" revision of the PPU in it (I don't remember the details but I can check if this is necessary).
I will give the new test a try soon.
Again, I see no difference between holding A and not holding A (NTSC NES + PowerPak), and I see very little if any difference between my NES and Nestopia in NTSC mode.
Acmlm, BMF, and I have all noticed that we'll occasionally get some weird scanlines while playing various older NES games, like SMB.
On SMB, we'll occasionally get a scanline that has some brown junk, and it'll just be somewhere in the middle of the sky for a frame.
I was also getting this issue in the horizontally-scrolling section of Kid Icarus, where as I scroll, there'll be the occasional "wrong" scanline somewhere in the screen. The weird thing is that this doesn't always happen; sometimes I'll play the game and never get this quirk, and sometimes I'll play the game and get this quirk a lot, but it's always in the horizontally-scrolling segments of the game.
Could this be related?
Sorry to poke into this topic again, but, has anyone taken thermal issues into consideration? Sometimes hardware behaves differently at cold boot as opposed to warm boot or after hours of play..
Well when I tested my system had not been running long at all. I doubt it had time to gain any significant heat. And the room temperature is cool.
Well, I received an unmodified mobo (thanks bunnyboy), and I did see some very minor "glitching" with it, it was similar to what I saw on PAL NES, i.e. some of the "subpixels" (on my HDTV) around some lines were flickering when a program was polling $2000, but stopped when it wasn't. This is quite hard to notice though, and not what I saw when I posted the "twitching" ROM.
So, as far as I understand this, this thing was a combination of couple of things. First of all, when I did the wiring to hook up the signals to my FPGA, the /CS and register select bits of the PPU were right next to the clock wire, and were glitching up the clock. FPGA saw the clock glitches as extra clocks, so that's where the erroneous SignalTap logs came from. I actually didn't think of this at all at the time I did the logs (due to inexperience with hardware) but it seems very obvious now.
As for the minor "glitches" in video output in an unmodified PAL/NTSC NES, I'm guessing the /CS and the 3 register select pins/traces are adding a small amount of interference to the composite video output of the PPU.
So to conclude, the only somewhat interesting find here seems to be that the polling of PPU regs does seem to be adding a very small amount of noise to the video signal. It's practically unnoticeable though.
Drag wrote:
Acmlm, BMF, and I have all noticed that we'll occasionally get some weird scanlines while playing various older NES games, like SMB.
...
Could this be related?
I doubt it, but that's a strange problem indeed. I've never noticed anything like that.