Yes, but there appear to be different glitches that are caused by each of the alignments. It's not clear if a re-shaped PPU /CE signal will fix all the glitches ... because we haven't yet been able to come up with unique identifiers for each of the 4 (NTSC) alignments ... so we don't know to what extent the glitches are caused by invalid data on the data bus, or just bad timing.Andy18650 wrote: ↑Thu Mar 31, 2022 12:16 pm Is this caused by the clock phase difference between the CPU and the PPU? I think with some clever circuit, it is possible to 'lock' the relationship on every bootup. (for example, hold the PPU's RST pin down until the CPU's M2 becomes stable, then release that on a certain edge of the M2 pulse)
(See viewtopic.php?t=20892 - these are all caused by invalid data. In contrast, viewtopic.php?t=18092 is caused by bad timing, but not all the bad timing is subcycle-level )
Most of the problems here are that no-one's sat down with a 2C07 and measured everything. Recently org has decapped one, but I don't remember any of the differences that were found - I probably forgot to read it.Indeed, I think the numbers would be higher since the PAL PPU is clocked at 26MHz instead of 21, so it might take more cycles to meet the timing requirements of the SRAM. But the PAL C/APU clock is actually slower, therefore this has a greater chance to work on a PAL machine. However, I do not want to create a region/format specific machine. If this feature only works on a PAL machine, I would just abandon it.
For example, in the NTSC PPU, it takes the 21.5MHz clock and divides it by two and makes two biphase clocks that run at 10.7MHz. Visual2C02 calls those "pclk0" and "pclk1"; I call them "left half dot" and "right half dot".
org did figure out how pclk0/pclk1 are generated in the 2C07, using 5 latches in a twisted-ring counter where every other latch is clocked on opposite phases. So it looks like that should be two 50% duty square waves at 10.64MHz ...
But none-the-less, if the timing hasn't changed, it should still work around to somewhere around 5.5(plus or minus?) pixels from when the CPU starts the write to when the PPU finishes the write. On the 2A07, where DMA is slower, I wouldn't be surprised if that's reliable. (On the 6527P, it should be as problematic as the 2A03)
Modern ALS and ACT parts are faster than the ancient "F" series parts.My concern is: would these 74s be fast enough? are we forced to choose 74F series chips?
It's also ok if the delay is consistently far enough away from one pixel edge - the PPUs latch the EXT pins every pixel (so that they can do the palette lookup).
Do you already know about Visual2C02? http://www.qmtpro.com/~nes/chipimages/visual2c02/
It turns out that the EXT pins are accepted during pclk0, go all the way through the palette RAM, and are finally permitted to go further through the rendering stage afterwards during pclk1. (There's some more sources of latency before it hits the actual DAC, I believe). "pclk0" is directly visible externally during rendering as the PPU's ALE signal.