[stella] Earliest safe write to PF1 for asymmetrical playfield?

Sun Jul 6 02:00:55 CDT 2008

I don't understand the 2/3 delay, anyway, since it's my understanding that the Atari's playfield display is timed by the polynomial counters (or linear feedback shift registers), which update at a different rate than the CPU-- 4 color clocks equal 1 "tick" of the polynomial counter, whereas 3 color clocks equal 1 "tick" of the CPU. That means 1 "tick" of the polynomial counter equals 1-and-1/3 machine cycles, so 2/3 of a cycle corresponds to half of a polynomial counter "tick," or half of a playfield pixel. Is this related somehow to the staggered/alternating pulses from the two phase clocks or whatnots? I'm afraid if I try to understand it, my head will explode, so I just try to accept it without thinking about it!

If (some or all?) 7800s, and some 2600-compatible consoles (e.g., the Gemini) require a slightly longer delay between writing to the playfield registers and displaying the new values, does this mean they have different circuitry than the 2600 for their polynomial counters?

Anyway, here's a new table that shows the 2/3-cycle delay values, along with the 1-cycle delay values. It's interesting that for the one place where there's absolutely no fudging allowed-- writing to PF2 between the left and right copies of PF2 for a reflected playfield-- the delays work out to be the same value in both cases.

I've reorganized the whole table for this version, eliminating the calculations, and combining the two separate tables into one single table. The first column shows the "name" of the pixel for a repeated playfield, and the second column shows it for a reflected playfield. The third column shows the number of the screen position where the playfield pixel begins-- position 000 is the leftmost visible spot on the scanline, 159 is the rightmost visible spot, and the HBLANK screen positions are shown as negative values. The fourth column shows the color clock number for the start of the playfield pixel. Note that the third and fourth columns are shown purely for reference, to help anyone who wants to calculate the "latest cycle" values themselves. The fifth and sixth columns are the real meat of the table, showing the latest cycle by which you must write to a given playfield register if you want that particular playfield pixel to display the new value. The fifth column shows the "latest cycle" value based upon a delay of 2/3 of a cycle, and the sixth column shows the "latest cycle" value based upon a delay of 1 full cycle. An asterisk is shown at the end of each row where there's a difference.

I was going to draw a line between the rows where the playfield registers change, but that wouldn't work for the right half of the screen, so I just drew a line between HBLANK and PF0, and another line between the left and right halves of the playfield.

Note that the numbers after the dashes in the "names" of the playfield pixels do *not* correspond to the bit numbers!

Michael

repeatd reflectd posit clock -2/3 -1
=======================================
HBLANK | HBLANK | -68 | 000 | 75 | 75
---------------------------------------
LPF0-0 | LPF0-0 | 000 | 068 | 22 | 21 *
LPF0-1 | LPF0-1 | 004 | 072 | 23 | 23
LPF0-2 | LPF0-2 | 008 | 076 | 24 | 24
LPF0-3 | LPF0-3 | 012 | 080 | 26 | 25 *
LPF1-0 | LPF1-0 | 016 | 084 | 27 | 27
LPF1-1 | LPF1-1 | 020 | 088 | 28 | 28
LPF1-2 | LPF1-2 | 024 | 092 | 30 | 29 *
LPF1-3 | LPF1-3 | 028 | 096 | 31 | 31
LPF1-4 | LPF1-4 | 032 | 100 | 32 | 32
LPF1-5 | LPF1-5 | 036 | 104 | 34 | 33 *
LPF1-6 | LPF1-6 | 040 | 108 | 35 | 35
LPF1-7 | LPF1-7 | 044 | 112 | 36 | 36
LPF2-0 | LPF2-0 | 048 | 116 | 38 | 37 *
LPF2-1 | LPF2-1 | 052 | 120 | 39 | 39
LPF2-2 | LPF2-2 | 056 | 124 | 40 | 40
LPF2-3 | LPF2-3 | 060 | 128 | 42 | 41 *
LPF2-4 | LPF2-4 | 064 | 132 | 43 | 43
LPF2-5 | LPF2-5 | 068 | 136 | 44 | 44
LPF2-6 | LPF2-6 | 072 | 140 | 46 | 45 *
LPF2-7 | LPF2-7 | 076 | 144 | 47 | 47
---------------------------------------
RPF0-0 | RPF2-0 | 080 | 148 | 48 | 48
RPF0-1 | RPF2-1 | 084 | 152 | 50 | 49 *
RPF0-2 | RPF2-2 | 088 | 156 | 51 | 51
RPF0-3 | RPF2-3 | 092 | 160 | 52 | 52
RPF1-0 | RPF2-4 | 096 | 164 | 54 | 53 *
RPF1-1 | RPF2-5 | 100 | 168 | 55 | 55
RPF1-2 | RPF2-6 | 104 | 172 | 56 | 56
RPF1-3 | RPF2-7 | 108 | 176 | 58 | 57 *
RPF1-4 | RPF1-0 | 112 | 180 | 59 | 59
RPF1-5 | RPF1-1 | 116 | 184 | 60 | 60
RPF1-6 | RPF1-2 | 120 | 188 | 62 | 61 *
RPF1-7 | RPF1-3 | 124 | 192 | 63 | 63
RPF2-0 | RPF1-4 | 128 | 196 | 64 | 64
RPF2-1 | RPF1-5 | 132 | 200 | 66 | 65 *
RPF2-2 | RPF1-6 | 136 | 204 | 67 | 67
RPF2-3 | RPF1-7 | 140 | 208 | 68 | 68
RPF2-4 | RPF0-0 | 144 | 212 | 70 | 69 *
RPF2-5 | RPF0-1 | 148 | 216 | 71 | 71
RPF2-6 | RPF0-2 | 152 | 220 | 72 | 72
RPF2-7 | RPF0-3 | 156 | 224 | 74 | 73 *
---------------------------------------

-----Original Message-----
From: Thomas Jentzsch <tjentzsch at web.de>
To: Atari 2600 programming list <stella at atari2600.org>
Sent: Sat, 5 Jul 2008 5:08 pm
Subject: Re: [stella] Earliest safe write to PF1 for asymmetrical playfield?

Michael wrote:
> A while back, I created a table for myself that shows the latest
> cycles at which you can write to the playfield registers, for each
> playfield pixel (plus the beginning of HBLANK).

Very useful. Thanks!

After the development of Thrust, I had a few people reporting problems
which are related to PF writes (especially Gemini and some 7800, but).
It turned out, that they are slightly slower than a original 2600.
Instead of 2/3 cycles, they delay by 1 whole cycle.

Maybe someone with such hardware can make some tests.

Have fun!
Thomas                            
_______________________________________________________
Thomas Jentzsch         | *** Every bit is sacred ! ***
tjentzsch at web dot de |

_______________________________________________
Stella mailing list
Stella at atari2600.org
http://atari2600.org/mailman/listinfo/stella

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://atari2600.org/pipermail/stella/attachments/20080706/ab2c0742/attachment.html 