blargg wrote:It's possible in software to detect which of these four alignments the NES powered/reset into. [...]
Out of curiosity, how do you do this? Do you just mean in the sense that you get four different behaviors that can be detected but don't know the precise alignments they correspond to?
Right. Before I tested with a scope recently, I knew the signatures of the four, and had them in what turns out correct order, based on the way more events would occur earlier in one direction, and more later in the other.
blargg wrote:Once that is figured out, then we can figure out where the /NMI occurs relative to my methods of synchronizing the CPU to it, which will then tell us all the timings of my tests at the hardware level. From there, it can all be done in software. We would have enough information to make tests that prompt the user to press reset possibly multiple times until it detects the proper alignment, then runs whatever test. So in code we could software test PPU events down to the PPU cycle (actually, down to the master cycle).
Not sure if I'm getting this. Do you mean something like the following?
- Figure out the precise CPU/PPU alignments the four possibilities correspond to with a logic analyzer.
- Make a test that detects which alignment it's in and then times where different things happen.
- Combine (1) and (2) to figure out the behavior at the master clock level.
Yeah. By prompting the user to press reset until the correct alignment is reached, the test program can, under its own control, initiate a CPU read or write at any point in the PPU frame, to master clock
Are you sure it's just four alignments by the way? Maybe the PPU can start n ticks before/after the CPU as well, and the tests still pass if they use relative timings.
But maybe it won't matter...
It can't be more. The CPU and PPU run off (AFAIK) the same edge of the master clock (PPU's color uses both edges, but that's separate). The CPU divides by 12, the PPU 4. Using previous terminology, cycle = CPU, dot = PPU. So you get three whole dots per cycle. There are only four different alignments of this, based on the PPU's divide-by-4.
Going to the entire frame, the PPU's frame is never a multiple of 3 dots, so every frame the alignment of the frame itself to a cycle shifts. This ensures that it doesn't matter what alignment a cycle to a frame has at power. If every frame were a multiple of 3 dots, then yes, you'd have 12 different alignments, corresponding to the CPU's divide-by-12.
And of course this is NTSC. According to the Wiki, PAL frame length's fraction is half a CPU cycle, and CPU divider is 16, so there are potentially 8 different CPU-frame alignments at power/reset.
To clarify about alignments, we have two different kinds. One, a cycle relative to a dot (not any particular one in the frame). The other, a cycle relative to the first dot of the frame. And of alignment, there are (obviously) various ones for each dot, since the CPU and PPU run at different rates. Of all the different possible alignments, for a given length of operation after power/reset, only a subset can ever be encountered. I take the topic to be talking about the number of distinct subsets. For an NTSC, there are four of these, both for cycle-dot alignment and cycle-frame alignment. For PAL, my calculation above suggests one cycle-dot alignment and 8 cycle-frame alignments.
Yet another way of putting the concept is that the relative synchronization of the CPU, PPU, and frame dividers reliably generates a random value at power/reset and preserves it during operation, regardless of what the CPU does (enable/disable rendering, whatever). On NTSC, this value has four states, and on PAL, eight states.