Right, I agree. The PPU's intricacies are what make it difficult to write a good tutorial. When I wrote my own emulator as a personal learning project in C I did it myself except the background rendering of the PPU which I ported from a popular cycle-accurate Go project. In writing this book, what I've done is go and say "how can I write the absolutely minimum PPU so that the most basic NROM games will play (like Donkey Kong & Tennis)." My rewritten from scratch PPU is as simple as possible, only doing any rendering once per frame (the simplified PPU only does anything 60 times per second). I have it working well on very simple commercial and public domain games in C. Now my challenge is to get it ported and performant enough in pure Python, the language of the book.
Is it possible to sync python up enough to get it to write frames accurately without a significant amount of lag? I'd certainly be interested in how to get it to do that.
> Simple NES emulator
The timings get really tough between the PPU / CPU with all of the scanline tricks you can do, even with an NROM setup. Many 6502 instructions don't behave like you think they would with page boundaries, there are some hardware errors. The PPU / registers get all kinds of weird with their behavior too, such as $2003/$2004 (sprite addr / data) basically being broken on real hardware and Sprite DMA only falling on even cycles, etc. Each mapper is it's own unique snowflake as well, the MMC3 and VRC6 scanline interrupts work completely differently in hardware. There are many more examples of strangeness.
I'd love to see someone tackle it and wish you luck.