JoJo Despacito AMV

There are 228 (160 visible + 68 not visible) color clocks on each scanline. The CPU is active ALL the time, unless you write to WSYNC at which point the CPU is immediately halted and doesn't become active again until the start of the next scanline. Since it takes 3 cycles to actually write WSYNC, a kernel which is using this to time scanlines only has 73 CPU cycles per line. Why 73? Because if we look at the color clocks per line, we see 228; but if we look at 3 color clocks for every CPU cycle, we actually have 228/3 = 76 CPU cycles per line. And if we use 3 of those to do a WSYNC, then we only have 73 available for other stuff. Voila!

And note, these 76 cycles for the whole line actually encompass the WHOLE line . . . 228 color clocks worth. Some of those will be during the 160 visible onscreen pixels (color clocks). Some will be during the 68 'horizontal blank' period—the invisible color clocks. And the CPU can be halted by a WSYNC at any time during the line—and it will be turned on at the start of the next line—no matter how long away that is.
It's quite important to understand the timing of things. Let's delve a bit more deeply into the synchronization between the 6502 and the TIA, and have a close look at when/where each pixel of the playfield is actually being drawn.

As stated above, the first 68 cycles of each scanline are the horizontal retrace period. So the very first pixel of playfield (which is 4 color-clocks wide, remember!) starts drawing on TIA cycle 68 (of 228 in the line). So if we want that pixel to be the right 'shape' (ie: on or off, as the case may be) then we really have to make sure we have the right data in the right bit of PF0 before cycle 68.

Likewise, we should really make sure that the second pixel has its correct data set before cycle 72 (68 + 4 color clocks). In fact, you should now understand that the 4 playfield pixels at the left of the scanline occupy TIA color clocks (68-71) (72-75) (76-79) and (80-83). The very first pixel of PF1, then, starts displaying at clock 84. So we need to make sure that data for PF1 is written before TIA clock 84. And so it goes, we should make sure that PF2 data is written to PF2 before the TIA starts displaying PF2 pixels. And that happens on clock (84 + 8 * 4 = 116)

Finally, we can now see that PF2 will take 32 color clocks (because it's 8 pixels, at 4 clocks each). As it starts on TIA clock 116, it will end on clock 147. The obvious calculation is 147 (end) - 68 (start) = 80 color clocks. Which nicely corresponds to 20 pixels at 4 color clocks each. OK, that's straightforward, but you should now follow exactly the correspondence between TIA color clocks and the start of display of particular pixels on any scanline.

Now, what happens at color clock 148? The TIA starts displaying the second half of the playfield for the scanline in question, of course! Depending on if the playfield is mirrored or not, we will start seeing data from PF2 (mirrored) or from PF0 (non-mirrored).

Now, and here's the really neat bit—and the whole trick behind 'asymmetric' playfields—we know that if we rewrite the TIA playfield data AFTER it has been displayed on the left half of the scanline, but BEFORE it is displayed on the right half of the scanline, then the TIA will display different data on the left and right side of the screen.

In particular, this method tends to use a non-mirrored playfield. We noted that PF0 finished displaying its 4 pixels on color clock 83 (inclusive). So from color clock 84 onwards (up to 148, in fact), we may freely write new data to PF0 and we won't bugger anything currently being displayed. That's 60 color clocks of time available to us.