This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Want to learn more about CPU/PPU synchronization

Want to learn more about CPU/PPU synchronization
by on (#232806)
While on tweeter, Membler mentioned if CPU/PPU synchronization was required for changing palette in hblank (It was not my tweet but I do it in my own project too and doesn't require that yet) . From that message, it made me realize that what if my current bug with my fadein/out with IRQ enabled with an MMC3 could be related to that? The bug doesn't happen every time and sometime stabilize so it could be related.

I started to search on the subject (still early stage of searching) and what I found for now is either this:
http://wiki.nesdev.com/w/index.php/PPU_frame_timing

or this:
https://wiki.nesdev.com/w/index.php/Con ... ronization

The first one seems to talk about timing but not really what to do with it. The second one goes in detail but for pal (did a quick look in it) but doesn't talk about NSTC.

I guess we must have talked on the forum somewhere for NTSC so I will search it from now but am I looking/searching for the right information? I want to make sure those article is what will help me understand on the subject.

Another thing I would like to know is if it's something that need to be done once when starting your program or for a specific event that you need to get them sync, which would means they could go out of sync based on what you do in your program.

Thank you in advance for any information on the subject. Time to search the forum in more details!

edit:

I think I just found Blargg threads:
viewtopic.php?f=2&t=6589&hilit=cpu+ppu+sync

Reading it right now.

edit2:

The more I read, the more I think it as no relationship with my bug since it help for raster effects and the bug I have is related to unstable palette when fading after waiting for NMI when IRQ handler exist. Oh well. I was so excited that I may have found the cause.

Still, the information is maybe useful since depending of the emulator, I had artefact for my color change in hblank in some emulator but not all. This could be the cause but I'm only changing one color and adjusting back the location of the rest of the screen in another NT. Will continue to read.
Re: Want to learn more about CPU/PPU synchronization
by on (#233669)
Sorry for the double post.

I was sure I fixed my issue with hblank but it seems I may have it another snag.

From the other post regarding what happens when disabling PPU in Hblank?, I was sure that my code was now stable since it was working fine on emulators. I was able to ask someone to test it on hardware and it seems that all kind of odd behavior occurs but not always, which point me back to this specific topic, CPU/PPU synchronization.

Before I start to dig into the wiki article since I know it will take me a lot of time to digest it (I'm tick for those things, I'm aware of that :lol:), what I would like to know is if I'm looking in the right direction? Is it possible that the PPU/CPU synchronisation could be affecting the timed code in hblank? If it does then I need to understand the details of it.

Based on people feedback who have experience on the PPU/CPU synchronization, this will help me to know where I should look next. Thank you in advance for any information on the subject.
Re: Want to learn more about CPU/PPU synchronization
by on (#233671)
I had totally missed this topic. Since nobody replied I'll try to my best abilities:

I believe the second link talks about syncronization in general, not just PAL. It has a "PAL timing" section at the beginning but I think it's only talking about how PAL is different from NTSC. The rest of the page applies to NTSC (so it seems to me).

As you said, yeah, cpu/ppu clock alignment could be causing a problem (or it could be something else). But I don't know of any emulator that simulates random sync on power-on. Is there one? I thought higan would do it but it doesn't even have a reset function, as far as I can see. Mesen doesn't seem to have this option either.

Finally, if you can't or don't want to show your project, then maybe you can generate a simplified demo of the problem? Just flat color tiles, etc and see if it still causes a problem on real hardware. That way you can perhaps share it here and people can take a better look. Just an idea ^^
Re: Want to learn more about CPU/PPU synchronization
by on (#233673)
Since there's two different degrees of "synchronization" that you could be talking about, I'll divide my answer in two:

1- CPU-vs-PPU "alignment". The independent dividers of the CPU and PPU produce subtly different behaviors and/or bugs in how the CPU interacts with the PPU. Unless you're doing something really off the wall, it seems unlikely that your problems could be due to this. (This is "subpixel" level. It also doesn't change ever after the CPU and PPU start)

2- Pixel level synchronization. Certain sufficiently advanced techniques require doing certain behaviors at specific times within a scanline. How precise you have to be depends on what exactly you're trying to achieve, but historically it's been both difficult to get accuracy better than within ±10 pixels, and few effects have tried to rely on better than that.
Re: Want to learn more about CPU/PPU synchronization
by on (#233674)
The main consequence of the variable PPU alignment is that if you're trying to time something sub-scanline (e.g. hblank) you need to leave yourself some extra margin in addition to the usual CPU jitter.

The only real advice I can give on this, though, is if you're doing something that needs more timing precision than just changing CHR banking or nametable scroll on a scanline, you have to test it on hardware. As you get more specific than that, there are just a lot of factors to account for, and as good as some emulators are, it's too "untested" an area to rely on.

We have a lot of detailed notes on the wiki like that which can help you figure out why when something weird happens, but I don't think you should expect to be able to read that document and know "what to do". Put something together with the best of your knowledge, and then test it in emulators and on hardware. You can hit reset a few times to try and see if the different PPU alignments affect it, but usually this isn't much of an effect.

If/once something goes wrong, we can ask more specific questions about what it's doing, and that's when those documents will be of more help to you.
Re: Want to learn more about CPU/PPU synchronization
by on (#233675)
@nesrocks

Thank you for the explanation about he wiki ;) Right now, I cannot talk about it yet publicly (and that's make things difficult to explain, I can't wait to talk :lol:) but I hope it will be possible soon. As for making a sample, it could be possible but would take time since I don't know "what" could be causing it to fail on hardware since I'm not the one that tested it. So for now, I need first to investigate the possible cause before extracting a sample that have to be in the same condition as the error.

@lidnariq

That is very simplified and clear, thanks! As for your question, I do not think that I'm doing anything super fancy at the moment. It could be the order that I'm doing them is causing the issue too but on emulators it doesn't occur.

What occurs is on a specific scanline (MMC3 scanline counter), an IRQ is fired. What I do is:

- I first change the NT to point in second one
- I acknowdlege the IRQ
- I repeat some NOP to time the code in hblank
- I disable the PPU
- I set a,x,y for address of PPU for updating color
- I reset the latch
- I update the color
- I now change address of VRAM to show a specific area of VRAM
- I re-activate the PPU
- I change the bank for fonts

I didn't write about saving/restoring register since those are obvious but this is basically what I'm doing midway: I change the bottom part of the screen to show the current text in a specific color and set proper bank for fonts. So, I don't think I'm doing anything fancy (I guess? ^^;;) so maybe my timing in hblank must be wrong, that is my only guess.


edit:

@rainwarrior

I guess I have no choice to find a solution to test on hardware since hblank is still something that is not very common. I should ask Vertrex28 on twitter too (unless never-obsolete "is" Vertrex28 and I just didn't read between the line :lol:) to know if he tested on hardware and what kind of issues he had. For now, it's one of many bugs on my todo list :D
Re: Want to learn more about CPU/PPU synchronization
by on (#233677)
Could this be a case of $2000/2002/2005/2006 read/write ordering causing internal PPU bits to be set/cleared, thus resulting in erroneous visual results?

Edit: Attached is an example of what I'm talking about.
Attachment:
ff2e.gif
ff2e.gif [ 80.73 KiB | Viewed 4214 times ]

It would really help to visually see what's going on for you, but I know you can't provide visuals for reasons.
Re: Want to learn more about CPU/PPU synchronization
by on (#233688)
oh, you're talking about a VMOD error? (VRAM mixup of death, just made that word up :lol:) I did have a few of them when my code was not synchronized but when you do palette change in hblank, it's mostly the color is affected since VRAM address that is going to be updated in hbank and the address palette are fighting each other while you try to write colors. Unless you close the ppu, that was a common quirk seen on emulator.

As for my current error, I based my questions on the feedback I kindly received from the person that tested and just sent a message in advance since he went trough the trouble for me and sync could have been an issue. After all the comments written and now that I have a better understanding, it may not be related. I was able to receive a video and the last test didn't seems to show the problem he had at first so it could be the test environment had issues and was causing quirk about what I wanted especially checked. How lucky am I :lol:

Still, there a possibility that this issue will rear its head again since we have to confirm if the machine was not the cause but like rainwarrior said, it's about time that I do more test on hardware to see if other issues are creeping since it's getting quite late in the project without such tests ^^;;

Once I have more feedback from the tests and if the error pattern shows again, I will see what I can do and ask more specific questions. For now, the thread did answer the original question so I'm happy to have more understanding about PPU/CPU synching. The only issue remaining is "maybe" there is an interesting bug lurking in the code or not and I'm the only one that can figure that part out ^^;;

I want to thanks everyone that gave feedback on that subject, I really appreciate it.