>Here's the only problem. We need to perfectly time the swap from PF2L to PF2R.
>We want to update just as the scanline hits the center of the screen.
>If we swap too early, some data from PF2R is reflected to the left by early
>drawing. If we swap too late, some of PF2L is reflected to the right.
>I would suggest that reflecting some or all of bit 7 is tolerable IF you can
>repeat the phenomena for each scanline (which means careful timing).
>
>Here's how I see it (corrections welcome of course)
>Since my code is two scanlines long, I'm going to look at the SECOND
>middle crossing and ignore the first for now.
What about the first one, though? You've gotta get PF2R calculated by
cycle 49 so you can draw it on that scanline, no?
>start our clocks at time 0, 3 color clocks for every cpu clock.
>
> color CPU
>start 0 0
>end line1 228 76
>hblank +68
> 296
>middle +80
> 376 125.3 (376/3)
>
>which means our goal is to affect a swap right smack on top of cpu clock
>125, or color clock 375, one color clock early, giving a 1/4 pixel reflection.
This is when you want to do it. I'm not completely sure, but I believe
that once the TIA starts drawing a playfield pixel (4 color clocks wide),
it will not change that pixel until it's done. Remember, you've gotta do
that to PF2 on both lines of your two-scanline kernel - on CPU clock 49
as well as CPU clock 125.
>If we do it on cpu 124 (color 372) that's 4 colors early, thusly 1 pixel
>reflection.
>If we do it on cpu 126 (color 378) thats 2 colors late for 2/4 reflection.
>
>sta PF2 takes 3 cpu cycles (unless the TIA slows this down somehow)
If you need to, you can write it as sta $2000+PF2 . Address bit 12 is
set in that address, but it's ignored because the 2600 only has 8k of
addressable space. But it does count as an absolute address rather than
zero-page, so it slows it down by one extra cycle. (NOPs give two-cycle
granularity.)
>cpuclock121 nop (burn clock 121 and 122 for example)
> sta PF2 (use clock 123, use clock 124, write on 125)
>
>Is the TIA instantaneous in using new register data, or can we get away with
>writing to PF2 a little early (for example on cpu clock 124)??
>
>Well that question is probably a thread unto itself....
Just experiment, that's the only way to find out for sure :) I'd guess
that 49 and 125 would be your best bets.
>Here's my new code, which ignores the need to draw scanline1, but which
>buffers the data needed to draw scanline2. It does a little bit less (32
>pixels and not 40), but it runs faster.
[..]
>lda tempPF1R (3) [90]
>sta PF1 (3) [93]
>...
>
>93 < 130 means version 2 is faster Yay!
And now you should have enough cycles left to put in the logic to control
looping, and maybe even draw the spaceship :)
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
