Jump to content
  • entries
    650
  • comments
    2,606
  • views
    869,992

Step 3 - Score & Timer display

SpiceWare

3,262 views

After getting a stable display, I like to implement the routines for displaying the score. You can see that in the first builds of Frantic, Medieval Mayhem, and Space Rocks. Even though we're not ready to show the player's score, the display is very useful for showing diagnostic information - such as this build of Frantic which uses it to show which sprites are colliding with the player.

To draw the score we're going to use the playfield graphics. The playfield pattern is comprised of 20 bits stored in 3 bytes of the TIA.

  • PF0 - only the upper 4 bits are used, and they're output in reverse order
  • PF1 - all 8 bits are used, output as you'd expect
  • PF2 - all 8 bits are used, output in reverse order

Andrew Davie posted this rather nice diagram in his 2600 Programming For Newbies tutorial which shows how that works:


blogentry-3056-0-08445000-1404002247_thumb.png



The 20 bits are either repeated or reflected to draw the 20 bits on the right half of the screen.

For our game a two digit score and a two digit timer will meet our requirements. We could show a single digit each in PF1 and PF2, but due to the reversed output of PF2 that would mean we'd need to create both normal and mirrored digit graphics. Instead, we're going to create digit graphics that are 3 bits across, which will allow us to show two digits using PF1. You may have seen the graphics in my prior blog entry with the revised mode file for jEdit. Each digit appears twice as we can use a simple mask to get the tens (AND #$F0) and ones(AND #$0F) digits. If we only saved the image as the ones position we'd need to apply 4 shift instructions to create a tens position image.


blogentry-3056-0-02500300-1404001019_thumb.png



PF1 is displayed twice on the screen and if we time it correctly we can change the contents of PF1 so that both sides of the screen are different. Andrew Davie posted another handy diagram that shows the timing:


blogentry-3056-0-02761900-1404002256_thumb.png



In looking at the diagram we can figure out the update times required for each instance of PF1

  • left PF1 - need to update on or after cycle 66 of the prior scanline, or on or before cycle 28 of the current scanline
  • right PF1 - need to update on or after cycle 39 and on or before cycle 54 of the current scanline

As mentioned before, the RIOT chip in the Atari 2600 stands for RAM, Input/Output and Timer. For this update we're going to look at the RAM and Input.

In order to show the score we need to keep track of a few things, so let's allocate some space in RAM:

        ORG $80
    
    ; Holds 2 digit score, stored as BCD (Binary Coded Decimal)
Score:          ds 1    ; stored in $80

    ; Holds 2 digit timer, stored as BCD
Timer:          ds 1    ; stored in $81

    ; Offsets into digit graphic data
DigitOnes:      ds 2    ; stored in $82-$83, DigitOnes = Score, DigitOnes+1 = Timer
DigitTens:      ds 2    ; stored in $84-$85, DigitTens = Score, DigitTens+1 = Timer

    ; graphic data ready to put into PF1
ScoreGfx:       ds 1    ; stored in $86
TimerGfx:       ds 1    ; stored in $87

    ; scratch variable
Temp:           ds 1    ; stored in $88 
 



Vertical Blank is now doing a little bit of work:

VerticalBlank:
        jsr SetObjectColors
        jsr PrepScoreForDisplay
        rts             ; ReTurn from Subroutine
 



When the macro CLEAN_START initialized the Atari's hardware, it set all the colors to black. So we need to set the object colors if we want to see anything. This routine also reads the state of the console switches (via one of RIOT's Input registers) in order to determine if the player selected Color or Black & White:

SetObjectColors:
        ldx #3          ; we're going to set 4 colors (0-3)
        ldy #3          ; default to the color entries in the table (0-3)
        lda SWCHB       ; read the state of the console switches
        and #%00001000  ; test state of D3, the TV Type switch
        bne SOCloop     ; if D3=1 then use color
        ldy #7          ; else use the b&w entries in the table (4-7)
SOCloop:
        lda Colors,y    ; get the color or b&w value
        sta COLUP0,x    ; and set it
        dey             ; decrease Y
        dex             ; decrease X
        bpl SOCloop     ; Branch PLus (positive)
        rts             ; ReTurn from Subroutine
    
Colors:
        .byte $86   ; blue       - goes into COLUP0, color for player0 and missile0
        .byte $C6   ; green      - goes into COLUP1, color for player1 and missile1
        .byte $46   ; red        - goes into COLUPF, color for playfield and ball
        .byte $00   ; black      - goes into COLUBK, color for background
        .byte $0E   ; white      - goes into COLUP0, B&W for player0 and missile0
        .byte $06   ; dark grey  - goes into COLUP1, B&W for player1 and missile1
        .byte $0A   ; light grey - goes into COLUPF, B&W for playfield and ball
        .byte $00   ; black      - goes into COLUBK, B&W for background
 



The score and timer will be stored using BCD (Binary Coded Decimal) but for now we'll treat and display them as hexadecimal values (that's why the digit graphics are 0-9 then A-F). This routine takes the upper and lower nybble (4 bits) of the Score and Timer and multiplies them by 5 in order to get the offset into the digit graphic data. The 6507 does not have a multiply command, though it does have a shift feature which is equivalent to *2. If a nybble is value X then X * 2 * 2 + X is the same as X * 5:

PrepScoreForDisplay:
    ; for testing purposes, change the values in Timer and Score
        inc Timer       ; INCrement Timer by 1
        bne PSFDskip    ; Branch Not Equal to 0
        inc Score       ; INCrement Score by 1 if Timer just rolled to 0
    
PSFDskip:
        ldx #1          ; use X as the loop counter for PSFDloop
PSFDloop:
        lda Score,x     ; LoaD A with Timer(first pass) or Score(second pass)
        and #$0F        ; remove the tens digit
        sta Temp        ; Store A into Temp
        asl             ; Accumulator Shift Left (# * 2)
        asl             ; Accumulator Shift Left (# * 4)
        adc Temp        ; ADd with Carry value in Temp (# * 5)
        sta DigitOnes,x  ; STore A in DigitOnes+1(first pass) or DigitOnes(second pass)
        lda Score,x     ; LoaD A with Timer(first pass) or Score(second pass)
        and #$F0        ; remove the ones digit
        lsr             ; Logical Shift Right (# / 2)
        lsr             ; Logical Shift Right (# / 4)
        sta Temp        ; Store A into Temp
        lsr             ; Logical Shift Right (# / 8)
        lsr             ; Logical Shift Right (# / 16)
        adc Temp        ; ADd with Carry value in Temp ((# / 16) * 5)
        sta DigitTens,x ; STore A in DigitTens+1(first pass) or DigitTens(second pass)
        dex             ; DEcrement X by 1
        bpl PSFDloop    ; Branch PLus (positive) to PSFDloop
        rts             ; ReTurn from Subroutine
 



The Kernel's been modified so it now uses the data in DigitOnes and DigitTens to update PF1. Each line of graphic data is output twice so the digits are drawn over 10 scanlines which gives them a better appearance than if they had been drawn over 5 scanlines.

        ldx #5
    
ScoreLoop:              ;   43 - cycle after bpl ScoreLoop
        ldy DigitTens   ; 3 46 - get the tens digit offset for the Score
        lda DigitGfx,y  ; 5 51 -   use it to load the digit graphics
        and #$F0        ; 2 53 -   remove the graphics for the ones digit
        sta ScoreGfx    ; 3 56 -   and save it
        ldy DigitOnes   ; 3 59 - get the ones digit offset for the Score
        lda DigitGfx,y  ; 5 64 -   use it to load the digit graphics
        and #$0F        ; 2 66 -   remove the graphics for the tens digit
        ora ScoreGfx    ; 3 69 -   merge with the tens digit graphics
        sta ScoreGfx    ; 3 72 -   and save it
        sta WSYNC       ; 3 75 - wait for end of scanline
;---------------------------------------
        sta PF1         ; 3  3 - @66-28, update playfield for Score dislay
        ldy DigitTens+1 ; 3  6 - get the left digit offset for the Timer
        lda DigitGfx,y  ; 5 11 -   use it to load the digit graphics
        and #$F0        ; 2 13 -   remove the graphics for the ones digit
        sta TimerGfx    ; 3 16 -   and save it
        ldy DigitOnes+1 ; 3 19 - get the ones digit offset for the Timer
        lda DigitGfx,y  ; 5 24 -   use it to load the digit graphics
        and #$0F        ; 2 26 -   remove the graphics for the tens digit
        ora TimerGfx    ; 3 29 -   merge with the tens digit graphics
        sta TimerGfx    ; 3 32 -   and save it
        jsr Sleep12     ;12 44 - waste some cycles
        sta PF1         ; 3 47 - @39-54, update playfield for Timer display
        ldy ScoreGfx    ; 3 50 - preload for next scanline
        sta WSYNC       ; 3 53 - wait for end of scanline
;---------------------------------------
        sty PF1         ; 3  3 - @66-28, update playfield for the Score display
        inc DigitTens   ; 5  8 - advance for the next line of graphic data
        inc DigitTens+1 ; 5 13 - advance for the next line of graphic data
        inc DigitOnes   ; 5 18 - advance for the next line of graphic data
        inc DigitOnes+1 ; 5 23 - advance for the next line of graphic data
        jsr Sleep12     ;12 35 - waste some cycles
        dex             ; 2 37 - decrease the loop counter
        sta PF1         ; 3 40 - @39-54, update playfield for the Timer display
        bne ScoreLoop   ; 2 42 - (3 43) if dex != 0 then branch to ScoreLoop
        sta WSYNC       ; 3 45 - wait for end of scanline
;---------------------------------------
        stx PF1         ; 3  3 - x = 0, so this blanks out playfield
        sta WSYNC       ; 3  6 - wait for end of scanline
 



Score and Timer:


blogentry-3056-0-03794300-1403999356_thumb.png


when TV Type switched to B&W:


blogentry-3056-0-98305000-1403999361_thumb.png



You'll notice that the score and timer are different colors even though they're both drawn using the playfield. This is because I've modified the Vertical Sync subroutine to turn on SCORE mode. SCORE mode tells TIA to use the color of player0 for the left half of the playfield and the color of player1 for the right half.

VerticalSync:
        lda #2      ; LoaD Accumulator with 2 so D1=1
        ldx #49     ; LoaD X with 49
        sta WSYNC   ; Wait for SYNC (halts CPU until end of scanline)
        sta VSYNC   ; Accumulator D1=1, turns on Vertical Sync signal
        stx TIM64T  ; set timer to go off in 41 scanlines (49 * 64) / 76
        sta CTRLPF  ; D1=1, playfield now in SCORE mode...
        rts         ; ReTurn from Subroutine
 


ROM
collect_20140628.bin

Source

Collect_20140628.zip

 

COLLECT TUTORIAL NAVIGATION

<PREVIOUS> <INDEX> <NEXT>

  • Like 1


11 Comments


Recommended Comments

Hello..

 

Could you please explain why the digits are multiplied by 5? I'm not sure I understand what "offset" means here.

Share this comment


Link to comment

The graphic shape for each digit is defined, in order, at DigitGfx (see second image in the blog entry). Each graphic image is 5 bytes high.

 

To draw a specific digit, use the following equation to get memory location in ROM for the correct shape: DigitGfx + (digit * 5). To draw an 8 that'd be DigitGfx + (8*5) or DigitGfx + 40.

 

Offset is the digit * 5 part of that equation - specifically it's the offset from DigitGfx.

Share this comment


Link to comment

Ohhh.. I kept thinking that this was being applied to the number graphics, not the location of the number graphic in memory; that you were masking the 10s digit, then taking the ones digit and "offset"ing to the left for some reason. But that made no sense, of course..

 

Thanks again!

Share this comment


Link to comment

After compiling, I see messages- bytes until the end of the cartridge and bytes until HumanGFX. What's the relevance of bytes until the graphics?

Share this comment


Link to comment

I'm working up a new blog entry to answer this, though it's taking a bit longer than expected as I've been dealing with bad allergies the past few days.

 

For now, the short answer is it has to do with preventing the extra CPU cycle that can occur when using indexed instructions, specifically the two lda DigitGfx,y instructions just after ScoreLoop:. The extra cycle happens if DigitGfx + Y is on a different page of memory than DigitGfx, and can throw off time critical routines like those in 2600 Kernels.

  • Like 1

Share this comment


Link to comment

To elaborate on Darrel's answer, you usually align your graphics to a 256-byte page, because of the extra cycle that he's talking about, which throws off your timing.

This means there's usually an empty gap between your code and the graphics, as the graphics data is moved forward to the nearest page boundary. It's often useful to know how much space is there, because (like the bytes until the end of the cartridge), it's basically free space that you can use.

(and once you fill up and go beyond that space, the graphics data will get pushed back to the NEXT page. If your'e not paying attention, you'll suddenly see your bytes-free-until-end-of-cartridge counter drop by 256, which can be confusing if you only added one or two instructions.)

  • Like 1

Share this comment


Link to comment

To elaborate on Darrel's answer

Thanks! Got sidetracked on my followup blog entry due to weather in the Houston area. While I've not experienced any flooding, my roof sprung a leak and a bunch of water came in through the bathroom's ceiling light fixture. Roof technician left just a bit ago, now I'm waiting on them to work up the estimate and get in queue to get the roof fixed.

Share this comment


Link to comment

Just spent a couple of hours retyping your code in and making sure I understand what's actually happening. That kernel was all a bit strange until it 'clicked' in my head. Thank you for doing these posts... it's blowing my mind how clever 2600 coders need to be 8).

  • Like 1

Share this comment


Link to comment

Just a FYI - "This is because I've modified Vertical Sync to turn on SCORE mode". I think you meant to say CTRLPF here.

Share this comment


Link to comment

Thanks - I've modified the text to clarify I was referring to the Vertical Sync subroutine, which is the code from label VerticalSync: to the instruction rts. The comment within the subroutine points out sta CTRLPF as the specific register that does it (along with the lda #2 that occurs 5 instructions prior to it as the same value also goes into VSYNC).

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...