The first problem is easily solved: overlap PPU registers.tepples in this thread wrote:I can see two practical problems with running two 2C02 PPUs in a master/slave configuration. The biggest is that the missing dot on every other frame when rendering is enabled would cause the PPUs to drift out of sync over time, 30 pixels for each second in which one PPU's rendering is enabled and the other's not. Another is that you'd need two separate sets of CHR RAM and nametable memory, one for each PPU, unless you can design some sort of multiplexer circuit.
If you have solutions for these, I'd be interested to see a new topic about them.
If PPU1 has its decoder as M2 AND /A15 AND /A14 AND A13 AND /A3, and PPU2 has its decoder as M2 AND /A15 AND /A14 AND A13 AND A4, then writes to $2011 will turn on both at the exact same time. And writes to $2000...$2007 address only PPU1, and writes to $2018-$201F address only the other.
Of course, there's no way to get OAM DMA into the second one. I'm not clear just how problematic this is: whether a layer of background-colored sprites is actually useful. If we don't need to accommodate sprites, then "just" giving PPU2 8 KiB of RAM for 4scr nametables and background tiles seems like an obvious choice.
I think the exciting thing about the dual-PPU circuit is that it could have been easily done in the 1980s, even if it wasn't.
(As far as emulation ... I'd be much more excited to see a dual-APU tracker that could target Vs. System / VT03 / Donkey Kong.)