Differences

This shows you the differences between two versions of the page.

--- base:dysp_d017 [2016-04-22 13:09] – created compyx
+++ base:dysp_d017 [2016-04-26 13:52] (current) – added link to github repo compyx
@@ Line 7: / Line 7: @@
 Anyway, a DYSP can be done in many ways, the way I'm describing below is probably the easiest way, since it keeps the timing for each raster line constant by 'cheating' with $d017 manipulation.
+{{:base:d017-dysp.png|Screen of the DYSP in action}}
 ==== Assembling the code ====
-The code below is in [[http://tass64.sourceforge.net/]64tass] format, and can be assembled using:
+The code below is in [[http://tass64.sourceforge.net/|64tass]] format, and can be assembled using:
-<code>64tass -C -a -o dysp.prg dysp.asm</code>, assuming one would copy and paste the code into a file called 'dysp.asm'.
+<code>64tass -C -a -o dysp.prg dysp.asm</code>... assuming one would copy and paste the code into a file called 'dysp.asm'.
+Update: The code is now hosted on [[https://github.com/Compyx/dysp-d017|GitHub]], just clone the repo and run <code>make</code> to assemble, or <code>make x64</code> to assemble and run.
+==== Sprite stretching theory ====
+I'm not going into detail on how sprite stretching works, there's an [[magazines:chacking5#the_demo_cornerstretching_sprites|excellent article]] by Pasi Ojala on sprite stretching, explaining this trick in great detail.
 ===== The Problem =====
-Moving sprites into the side border is fairly easy, but requires cycle exact timing. There are plenty of articles here which explain this. Using a constant Y-position for the sprites makes timing the code easy, the problem arises when we want to have variable Y-positions for each sprite, this screws with our timing.
+Moving sprites into the side border is fairly easy, but requires cycle exact timing. There are plenty of articles here which explain this. Using a constant Y-position for the sprites makes the timing code easy, the problem arises when we want to have variable Y-positions for each sprite, this screws with our timing.
 There's a multitude of ways to solve this, I'll be describing what I consider the easiest and 'cheating' way of doing it. We use sprite stretching via $d017 to keep our timing constant.
+===== The Solution =====
+Using the $d017 sprite stretching technique, we can make our sprites arbitrarily high, repeating each line of a sprite for as long as we like. This keeps our border opening routine simple.
+Here's the routine, basically an adjusted FLD with side border opening and sprite stretching.
+The interesting part is the d017_table access, this allows use to stretch (or not) each line of each sprite:
+<code 6502tasm>
+; The $d017 stretcher
+;
+; Basically an FLD with $d017 manipulation and open borders: we use the FLD
+; effect to inhibit bad lines, giving us 63 cycles on each rasterline, of which
+; a lot of cycles get eaten by the sprites
+;
+; At each line we set Y-stretch to false, immediately followed by true, which
+; causes a line of a sprite to be stretched indefinitely. When we set the
+; Y-stretch to false at a line (after the initial false condition), we allow
+; the VIC to update its position in the sprite matrix, thus displaying a line
+; of a sprite
+;
+; This loop can be unrolled and optimized to allow for raster splits, if
+; desired
+stretcher
+        ldy #0
+        ldx #0
+-       sty $d017               ; set Y-stretch to false
+        lda d017_table,x        ; set Y-stretch to true for selected sprites
+        sta $d017
+        lda d011_table,x
+        bit $ea
+        nop
+        nop
+        dec $d016               ; open side border and do FLD to inhibit
+        sta $d011               ; bad lines
+        inc $d016
+        inx
+        cpx #64
+        bne -
+        rts
+</code>
+==== Stretching the first and last sprite line ====
+The trick to variable Y-positioning is to stretch the first line of a sprite until we reach the Y-position where we want the sprite to display, then displaying 19 lines of the sprite (not stretching the sprite(s)), and then stretching the last line of the sprite until the loop ends.
+Suppose we would want to display three sprites, each one one pixel lower than the next. 'A' means sprite 0, 'B' sprite 1 and so on. A[xx] means which line of the sprite we display, 00 is the empty sprite line which we use to stretch until we display the actual sprite data (01-19), line 20 is the empty line we use to complete the loop.
+<code>
+Sprites            $d017             Display
+---------------    --------------    ---------------------
+A00   B00   C00    %11111111  $ff    (nothing, we stretch the first, empty, line
+A01   B00   C00    %11111110  $fe    AAA
+A02   B01   C00    %11111100  $fc    AAA  BBB
+A03   B02   C01    %11111000  $f8    AAA  BBB  CCC
+A04   B03   C02    %11111000  $f8    AAA  BBB  CCC
+...   ...   ...    %11111000  $f8    AAA  BBB  CCC
+A20   B19   C18    %11111001  $f9         BBB  CCC
+A20   B20   C19    %11111011  $fb              CCC
+A20   B20   C20    %11111111  $ff    (nothing, we stretch the last, empty, line
+</code>
+==== Generating the $d017 values ====
+Generating the correct $d017 value is quite simple, but takes some cycles.
+  * fill $d017 table with $ff (all sprites are stretched)
+  * for each SPRITE:
+    - get Y-position of SPRITE
+    - mask out bits in $d017 table, starting at Y-position, for 19 lines
+  * next SPRITE
+In pseudo-code, this would look like this:
+<code>
+        ; fill $d017 table with $ff
+        ldx #0
+        lda #$ff
+-       sta $1000,x
+        inx
+        cpx #64
+        bne -
+        ; render sprite 0
+        ldy sprite0_y
+        ldx #0
+-       lda $1000,x
+        and #%11111110    ; don't stretch sprite 0
+        sta $1000,x
+        iny
+        inx
+        cpx #19           ; repeat 19 times
+        bne -
+        ; more code ...
+        ; render sprite 7
+        ldy sprite7_y
+        ldx #0
+-       lda $1000,x
+        and #%01111111    ; don't stretch sprite 7
+        sta $1000,x
+        iny
+        inx
+        cpx #19
+        bne -
+</code>
+==== Limitations ====
+This of course means we can only use 19 pixels high sprites, lines 0 and 20 are cleared so we don't see the stretched sprite data.
 ===== The Code =====
+Putting it all together, we end up with the code below. I use two sinus tables for the X-movement, giving us 344 pixels total movement (actually a little less to avoid the DMA sprite access bug in the right border) and a single sinus for the Y movement.
+Again, this code is not up to (my) demo standards: change the border color to non-black and you'll see the border-opening bugs at the start of the routine.
 <code 6502tasm>