Asymetrical Reflected Playfield

[Just Jeff]

Good Afternoon,

 

I want to do a reflected asymmetrical playfield where PF2 sometimes appears left of center, sometimes right. Is that possible or practical? Should i just try PF1 instead? Or don't even try reflected asymmetrical?

 

Thanks for the help!

[tschak909]

the playfield positions are static, you can't move them left or right, you can only shift the bits.

 

-Thom

[+SpiceWare]

I originally used repeated asymmetrical playfields in Stay Frosty, but changed it to reflected asymmetrical to save cycle time and reduce RAM requirements. You can see that in Part 3 and Part 4 of my SF blog series.

 

The key thing to note is you must update PF2 for the right side of the screen at exactly cycle 48. Any sooner or later and the display will be incorrect.

[Just Jeff]

tschak909....

Appear, not move. So I'd store either zero or the playfield data right at cycle 38 for the right side. Most other times for the left.

Edited July 10, 2016 by BNE Jeff

[Just Jeff]

I originally used repeated asymmetrical playfields in Stay Frosty, but changed it to reflected asymmetrical to save cycle time and reduce RAM requirements. You can see that in Part 3 and Part 4 of my SF blog series.

 

The key thing to note is you must update PF2 for the right side of the screen at exactly cycle 48. Any sooner or later and the display will be incorrect.

 

OK I'll check those out in a bit. And correction.. cycle 48. Thanks. So it is done then? I need consistent lines I suppose. If I recall from the Collect series, the .byte $2C trick keeps the cycles consistent with the bcs DoDraw branch time right?

Edited July 10, 2016 by BNE Jeff

[+SpiceWare]

Yes, the STA PF2 must end on cycle 48. I don't have many cycle counts in the early source examples. The final source has them like this:

 

        sta GRP0                      ; 3
        lda (FrostyColorPtr+.SEC*2),y ; 5   8
        sta COLUP0                    ; 3  11
        lda (FireImagePtr+.SEC*2),y   ; 5  16
        sta GRP1                      ; 3  19
        ldx IceData+.SEC*4            ; 3  22
        stx PF1                       ; 3  25
        ldx IceData+.SEC*4+1          ; 3  28
        stx PF2                       ; 3  31
        ldx IceData+.SEC*4+2          ; 3  34
        SLEEP 9                       ; 9  43
        dey                           ; 2  45
        stx PF2                       ; 3  48 <- must be at 48
        ldx IceData+.SEC*4+3          ; 3  51
        stx PF1                       ; 3  54
        lda (FrostyImagePtr+.SEC*2),y ; 5  64
        and (FrostyMaskPtr+.SEC*2),y  ; 5  69
        sta WSYNC                     ; 3  72

---

DoDraw is written so the cycles are exactly the same no matter which path through the code is taken, which makes it very useful for kernels that require precise timing like this.