Atari 2600 Programming for Newbies

Upside-Down

The trick here is that the 'dex' instruction will set the Z (zero) flag to 1 if the x register is zero after the instruction has executed, and 0 if it is non-zero. The 'bne' instruction stands for "branch if Z is zero" or more memorably "branch if the result was not equal (to zero)". In short, the branch will be taken if the x register is non-zero. Thus we have removed two cycles from our inner scanline loop. But at what cost? Since the loop is now counting 'down' instead of 'up', our tables will now be accessed upside-down (that is, the first scanline will show data from the bottom of the tables), and our whole playfield will 'flip' upside-down. That's fine—the solution for this is to change the tables themselves so they are upside-down, too!

All of that was a bit of a diversion—but it's important to understand how we are accessing our data in an upside-down fashion merely for the purposes of efficiency—in this case, saving us just 2 cycles per scanline. But those 2 cycles are some 2.6% of the time we have, and every little bit counts.

Animation

Before we continue, let's have a think about what we want a sprite draw to do—it's fine to be able to display a sprite shape anywhere on the screen (we've already touched on the horizontal positioning, and now we're well on the way to understanding how the vertical positioning works)—but sprites typically animate. How can we use the code shown so far to animate our sprites as well?

If we used the Atari computer method—presented above—of using a 'strip' of RAM to represent the table from which data is written to the screen, and modifying the data written to that table, then the problem is fairly simple—we just write different shapes to the table. But if we don't HAVE a RAM table, and we're forced to use a ROM table, then to get different shapes onscreen, we're going to have to use different tables. We can't modify the contents of tables in ROM! But the code above has the table hardwired into the code itself. That is…

    lda Sprite0Data,x

    sta GRP0

The problem here is that the address of the table is hardwired at the time we write our code—and the assembler will happily predetermine where this table is in the ROM, and the code will always fetch the data from the same table. What we really want to do with a sprite routine is not only fetch the data from a table—but also be able to change WHICH table we fetch the data from.

And here is an ideal use for a new addressing mode of the 6502.

    lda (zp),y

In the above code, 'zp' is a zero page two-byte variable which holds a memory address. The 6502 takes the contents of that variable (ie: the address of our table), adds the y register to it, and then uses the resulting address as our location from which to load a byte of data. It's quite an expensive instruction, taking 5 cycles to execute.

But now our code for drawing sprites (in principle) can look like this…

    lda (SpriteTablePtr),y

    sta GRP0

The problem this introduces is that the Y register is used for indexing the data table, whereas we were previously using the X register. There's no way around this—the addressing mode does not work with the X register! So let's change our kernel around a bit, and instead of using the X register to count the scanlines, we'll switch to the Y register…

    ldy #192   ;2

Kernel 



    lda PF0Table,y   ;4

    sta PF0   ;3

    lda PF1Table,y   ;4

    sta PF1   ;3

    lda PF2Table,y   ;4

    sta PF2   ;3



    lda (SpriteTablePtr),y; 5

    sta GRP0; 3



    sta WSYNC   ;3

    dey   ;2

    bne Kernel   ;3(2)

This is a bit better—now (as long as we previously setup the zero page 2-byte variable to point to our table) we are able to display any sprite shape that we desire, using the one bit of code. Here's what you'd need to do to setup your variable to point to the sprite shape data…

    lda #<Sprite0Data

    sta SpriteTablePtr

    lda #>SPrite0Data

    sta SpriteTablePtr+1

Additionally, the variable should be defined in the RAM segment like this…

SpriteTablePtr ds 2

Now let's review all of that and make sure we understand exactly what is happening… We have a zero page variable (2 bytes long) which holds the address of the sprite table containing the shape we want to display. Addresses are 16-bits long, and we've already seen how the 6502 represents 16-bit addresses by a pair of bytes—the low byte followed by the high byte (little-endian order). So into our sprite pointer variable, we are writing this byte-pair. The '>' operator tells the assembler to use the high byte of an address, and the '<' operator tells the assembler to use the low byte of an address. These are standard operators, but there's another way to do it…

    lda #address&0xFF  ; low byte

    sta var

    lda #address/256   ; high byte

    sta var+1

Other ways exist. It doesn't really matter which one you use—the result is the same. We end up with a zero page variable which POINTS to the table which is used to give the data for the shape of the sprite. In fact, the variable points to the very start of the table.

And this is our new problem! As we have earlier seen, if we had a RAM table, then we could move the sprite up and down by drawing it into that table and let our kernel display the whole 'strip' of sprite data. The effect would be that the sprite moved up and down on screen. But because we don't have that much RAM, we must programmatically determine on which scanline(s) the sprite data is to be displayed from the table, and which scanline(s) should contain 0-data for the sprite.

Essentially the process consists of comparing the current line-counter (the Y register) with the vertical position required for the sprite. If the counter comparison indicates that the sprite should be visible on the current scanline, then the data is fetched from the table—else a 0 value is used for the sprite data. Rather than stepping through the entire process and deriving the optimum result, we're going to just drop in the method used by nearly all games these days…

        sec                 ; 2  can often be guaranteed,
                            ; and omitted.


         tya                ; 2

        sbc SpriteEnd       ; 3

        adc #SPRITE_HEIGHT  ; 2

        bcs .MBDraw3        ; 2(3)



        nop                 ; 2

        nop                 ; 2

        sec                 ; 2

        bcs .skipMBDraw3    ; 3



.MBDraw3

        lda (Sprite),y      ; 5

        sta GRP0            ; 3



.skipMBDraw3

; Thomas Jentzsch Skipdraw 
;==================================================================

; The best way, I knew until now, was (if y contains linecounter):
  tya                   ; 2
; sec                   ; 2 <- this can sometimes be avoided
  sbc SpriteEnd         ; 3
  adc #SPRITEHEIGHT     ; 2
  bcx .skipDraw         ; 2 = 9-11 cycles
; ...

; --------- or ------------

;If you like using illegal opcodes, you can use dcp (dec,cmp) here:
  lda #SPRITEHEIGHT     ; 2
  dcp SpriteEnd         ; 5     initial value has to be adjusted
  bcx .skipDraw         ; 2 = 9
; ...

; Advantages:
;- state of carry flag doesn't matter anymore (may save 2 cycles)
;- a remains constant, could be useful for a 2nd sprite
;- you could use the content of SpriteEnd instead of y for
;  accessing sprite data
;- ???



;==================================================================
; An Example:
;
   ; skipDraw routine for right player
   TXA                          ; 2 A-> Current scannline
   SEC                          ; 2 Set Carry
   SBC slowP1YCoordFromBottom+1 ; 3 
   ADC #SPRITEHEIGHT+1          ; 2 calc if sprite is drawn
   BCC skipDrawRight            ; 2/3 To skip or not to skip?
   TAY                          ; 2
   lda P1Graphic,y              ; 4
continueRight:
   STA GRP0     

;----- this part outside of kernel

skipDrawRight        ; 3 from BCC
   LDA #0            ; 2
   BEQ continueRight ; 3 Return...