Atari 2600 Programming for Newbies

WSYNC Refresher

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.

Synchronization

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.

More About Timing

Time to revisit the timing relationship between the 6502 and the TIA. The TIA has 228 color clocks per scanline, but the 6502 speed is derived from the TIA clock through a divide-by-three. So the 6502 has only 76 cycles (228/3) per scanline. So if there are 60 color clocks of time available to change PF0, that corresponds to 60/3 = 20 cycles of 6502 time. Further conversions between TIA time and 6502 cycles show us that it must start after TIA cycle 84 (= 84/3) = 6502 cycle 28, and it must end before TIA cycle 148 (6502 cycle 148/3 = 49.3333). Aha! How can we have a non-integer cycle? We can't, of course. All this tells us is that it is IMPOSSIBLE to exactly change data on TIA color clock 148. We can change TIA data on any divisible-by-three cycle number, since the 6502 is working in tandem with the TIA but only gets a look-in every 3 cycles.

This inability to exactly time things isn't a problem for us now, as we have already noted that there are 60 TIA color clocks in which we can effect our change for PF0.

PF1 and PF2 operate in exactly the same fashion. PF1 is displayed from clocks 84-115 and on the right-side from clock 164 onwards (remember the right-side starts at clock 148, PF0 takes 16 color-clocks (4 pixels at 4 color-clocks each). So to modify PF1 so it displays different right-side and left-side visuals, we need to modify it between color clock 116 and 164. That gives us a narrower window of time in which we can make our modification—just 48 color clocks. But still, we can do that, right?

Finally, PF2 is displayed from clock 116-147 (let's check, that's 32 color clocks inclusive - 32 = 8 pixels x 4 clocks per pixel. Yep!). And on the right-side of the scanline, PF2 will display from clock 164 + 32 = 196 to clock 227. 227 - 196 = exactly 32 color clocks. Voila! So the window of opportunity for PF2, so to speak, is from color clock 148 to 195 inclusive. That's another 48 clocks.

So to summarize the timing for writing the right-hand-side PF register updates, we can safely modify PF0 from clocks 84 - 147, PF1 from clocks 116 - 163 inclusive, and PF2 from 148 - 195 inclusive. Note the overlap on these times. We could safely modify PF1 on (say) cycle 116, and then modify PF0 on cycle 130, and finally modify PF2 on cycle 190. The point being, it's not the ORDER of the modifications to the playfield registers that count—it's the TIMING that counts. As long as we modify the registers in the period when the TIA isn't drawing them, we won't see glitches on the screen.

One Thing You Need to Remember

Well, now you have all the information you need to generate an asymmetrical playfield. But there's one thing you need to remember—once you write data to the TIA, the TIA retains that 'state', or the data that you last wrote. So if you want an asymmetrical playfield, you not only have to write the new data for the right-half of the scanline, you have to write the right data for the left side of the NEXT scanline!

In fact, we already covered that. As long as PF0 is written before cycle 68 then it will display OK on the left … etc. So a typical asymmetrical playfield kernel will be writing 6 playfield writes (two to PF0, two to PF1, two to PF2) on each and every scanline. As you can imagine, you don't get a lot of change out of just 76 cycles of 6502 time per scanline, when as a minimum a load/store is going to cost you 5 cycles of time—and in most cases more like 6 or 7. That can equate to 40 or more cycles of your 76, JUST drawing the playfield data. Ouch!