3 replies to this topic

[Animan]

As I have decided to use the playfield as the scoreboard for my Monaco GP 2600 project, I have hit a minor snag.

I am using score digits that are 3 pixels wide (technically 4, but the digits only use 3), and using that in PF0 is fine. However, trying to load this into PF1 is a problem.

I want to load 4-bit data into half of PF1, and a different set of 4-bit data into the other half. How can I do this?

Sorry if this sounds slightly confusing. Here is a crappy MS Paint picture to help.

Attached Thumbnails

• 

Edited by Animan, Sat Sep 25, 2010 2:22 PM.

[SeaGtGruff]

Animan, on Sat Sep 25, 2010 2:21 PM, said:

I want to load 4-bit data into half of PF1, and a different set of 4-bit data into the other half. How can I do this?

To set the lo nibble, you first want to clear its old value with an AND, then load its new value with an ORA:

   LDA PF1_RAM ; some RAM byte that holds the value for PF1
   AND #$F0	; clear the lo nibble
   ORA NEW_VAL ; some RAM byte that holds the new value
   STA PF1_RAM

To set the hi_nibble, you first want to clear its old value with an AND, then load its new value with an ORA:

   LDA PF1_RAM ; some RAM byte that holds the value for PF1
   AND #$0F	; clear the hi nibble
   ORA NEW_VAL ; some RAM byte that holds the new value
   STA PF1_RAM

That's just a generic solution. For a more specific solution, it depends on how you're going to organize things.

For example, how are you going to store the data for the digits? When using characters that take up only a nibble, one approach is to store the same data in both nibbles of a byte. Then when you want to set the data for a nibble, load the whole byte, mask off the side you don't need, and ORA the remaining value with the byte you're changing:

   ; set the address pointers for the first digit
   LDA #<digit_0
   STA first_digit
   LDA #>digit_0
   STA first_digit+1
   ; set the address pointers for the second digit
   LDA #<digit_1
   STA second_digit
   LDA #>digit_1
   STA second_digit+1
   ; get 8 lines of data
   LDY #7
load_digits
   ; get the first digit and store it
   LDA (first_digit),Y
   AND #$F0
   STA result
   ; get the second digit and store it
   LDA (second_digit),Y
   AND #$0F
   ORA result
   STA result
   ; loop until done
   DEY
   BPL load_digits
   ; etc.

digit_0
   BYTE %01000100
   BYTE %11101110
   BYTE %10101010
   BYTE %10101010
   BYTE %10101010
   BYTE %10101010
   BYTE %11101110
   BYTE %01000100

digit_1
   BYTE %11101110
   BYTE %01000100
   BYTE %01000100
   BYTE %01000100
   BYTE %01000100
   BYTE %01000100
   BYTE %11001100
   BYTE %01000100

; etc.

Michael

[bogax]

Animan, on Sat Sep 25, 2010 2:21 PM, said:

As I have decided to use the playfield as the scoreboard for my Monaco GP 2600 project, I have hit a minor snag.

I am using score digits that are 3 pixels wide (technically 4, but the digits only use 3), and using that in PF0 is fine. However, trying to load this into PF1 is a problem.

I want to load 4-bit data into half of PF1, and a different set of 4-bit data into the other half. How can I do this?

Sorry if this sounds slightly confusing. Here is a crappy MS Paint picture to help.

Not sure I understand maybe this will help

A eor A = 0
A eor 0 = A

so

A eor B eor A = B

so you've got two bytes (letters are nibbles) ab, cd

 lda ab    ; the byte containg ab
 eor cd    ; the byte containg cd
 and #$F0  ; the high nibble of the accumulator is a eor c the low nibble is 0
 eor cd    ; the high nibble is a eor c eor c = a the low nibble is 0 eor d
           ; that is, the accumulator is now ad

Edited by bogax, Sun Sep 26, 2010 3:44 AM.

[Nukey Shay]

Yeah, there are a bunch of ways to approach this. You could store digit bitmaps in 4 tables so you don't need to mask nybbles if time/ram is an issue (so the kernel can just reuse the same variable as it prints). Or you could store reversed copies of digits in the low nybble of the regular copies, and use LSR/ASL to shift them into position if saving romspace is an issue. Or you could expand the score display routine to use the "venician blinds" technique if you want more digits without needing a whole lot of ram(the one present in Space Invaders shows 2 4-digit scores...which can be easily edited to show 2 5-digit scores). Alternately...if your scores are only 2 digits for each player, you could use a single bitmap table and reset CTRLPF to display in reversed mode...confining the printing to only 1 of the PF registers.
And any of those methods can take advantage of the "score mode" bit in CTRLPF...so that the playfield color is taken from the player sprites as it is displayed.