> I am not sure about the planned restrictions for the inside area
> (REFLEX). How
> wide can it become? Currently is has to stay inside the limits
> you are already
> using for the titlescreen, right? So the COLUPF writes have some
> little tolerance.
The kernel won't get any wider than it is. So yes, the COLUPF writes have
some tolerance in the main part of the kernel, but less in the top and
bottom parts in order to handle paddle color changes for two players.
> IMO there are plenty of free cycles left. Here is an example from
> the main part
> of the kernel:
>
> .loop2 ; -2
> lda ballShape,x ;+4 2
> sta GRP1 ;+3 5
> SLEEP 7 ;+7 12
> lda block1l,y ;+4 16
> sta PF1 ;+3 *19* Update left half of playfield
> lda block2l,y ;+4 23
> sta PF2 ;+3 26
> lda (tryX),y ;+5 31
> sta COLUPF ;+3 *34* Set board color
> lda block2r,y ;+4 38
> sleep 7 ;+7 45
> sta PF2 ;+3 *48* Update right half of playfield
> lda block1r,y ;+4 52
> sta PF1 ;+3 55
> lda pcol ;+3 58
> sleep 3 ;+3 61
> sta COLUPF ;+3 *64* Set paddle color
> dex ;+2 66
> dec lineCount ;+5 71
> bne .loop2 ;+3/2 *74*/73
>
> First you can move the 2nd write to PF1 before the 2nd write to PF2.
> Then you can join two SLEEP (7+3) statements. Now we have moved
> all SLEEP statements outside the PFx writes.
I'd been wondering how to consolidate my SLEEPs. It never occured to me to
swap the order of my PF writes like that. Thanks for the awesome tip.
> Outside we now have:
> - set paddle color (has to be delayed until 64..69!)
> - update ball graphics (has to happen after 69)
> - loop overhead (doesn't matter where)
> - 17 free cycles (plenty enough! :-)
>
> After some rearrangement the code looks like this (untested!):
>
> .loop2 ; 58
> lda pcol ;+3 61
> sta COLUPF ;+3 *64* Set paddle color
> SLEEP 17 ;+10 5
> lda ballShape,x ;+4 9
> sta GRP1 ;+3 12
> lda block1l,y ;+4 16
> sta PF1 ;+3 *19* Update left half of playfield
> lda block2l,y ;+4 23
> sta PF2 ;+3 26
> lda (tryX),y ;+5 31
> sta COLUPF ;+3 *34* Set board color
> lda block1r,y ;+4 38
> sta PF1 ;+3 41
> lda block2r,y ;+4 45
> sta PF2 ;+3 *48* Update right half of playfield
> dey ;+2 50
> dec lineCount ;+5 55
> bne .loop2 ;+3/2 *58*/57
>
> So you have 24 cycles for skipDraw, which is more than enough. :-)
We've all said it before and I'll be happy to say it again. You're the
master, Thomas.
> When using skipDraw, you will use Y for the scanline counter AND the
> graphics data and X for the PF-data.
Actually, I should be able to keep it the other way around (y for PF data
and x for scanline) because the ball doesn't need to be (indirect),y
indexed, but my board color does.
> If neccessary we are also able to get rid of lineCount, this would
> reduce the additional overhead outside the loop:
> tya
> cmp Table,x
> This is 100% flexible but will cost you one cycle inside the loop.
> (I am really missing cpy abs,x here)
>
> Or you can do:
> tya
> and #(2^n-1)
> But then then your rowheights are restricted to 2^n.
I'm okay with keeping lineCount. :) Using a lookup table would eat up half
of the memory I would save by using skipdraw and I really like having the
bricks vertically separated.
> Hope that helps.
IMMENSELY! Thank you very much for taking the time to deconstruct my
kernel! This change should give me a lot of extra space to build in bells
and whistles, and also bring my kernel close to its final state. I just
wish I had enough time to work on it this morning. But it'll have to
wait... probably until tomorrow since it's my wife's birthday today.
> Have fun!
> Thomas
I'm having a blast!
-Lee
