Score Corruption

[Cybearg]

I'm working on a game that switches between two scores that are kept in memory, so I have to handle the splitting and incrementing of these "virtual" scores by hand. The problem is that one of two things happens:

 

1. If I set decimal mode, the numbers don't increment from the tens place to the hundreds place or from the thousands place to the ten-thousands place.

 

2. If I don't set decimal mode, the score gets corrupted

 

I made a simple example (attached, and below) so everyone who is willing can experiment with the set/clear decimal modes if it would help to figure out how it needs to be done in order to work.

 

rem batari Basic Program
rem created 6/17/2013 5:15:11 PM by Visual bB Version 1.0.0.566

dim p0sc1 = l
dim p0sc2 = m
dim p0sc3 = n

dim p1sc1 = o
dim p1sc2 = p
dim p1sc3 = q

rem set up score bytes for reading/writing
dim sc1=score
dim sc2=score+1
dim sc3=score+2

def scoreshow = a{0}

scorecolor = $0E

main

rem handles moving values to the hundreds and ten-thousands places
if p0sc3 > $99 then p0sc2 = p0sc2 + $01: p0sc3 = $00
if p0sc2 > $99 then p0sc1 = p0sc1 + $01: p0sc2 = $00

if p1sc3 > $99 then p1sc2 = p1sc2 + $01: p1sc3 = $00
if p1sc2 > $99 then p1sc1 = p1sc1 + $01: p1sc2 = $00

rem handles adding to the score per frame
rem NOTE: if statement is unnecessary in this context, but kept because it is used in another context, just in case it matters somehow
if !player0y then p0sc3 = p0sc3 + $10
if !player1y then p1sc3 = p1sc3 + $10

rem copies stored value to the score
rem NOTE: the scoreshow option is unnecessary in this context, but kept because it is is used in another context, just in case it matters somehow
if !scoreshow then sc1 = p0sc1: sc2 = p0sc2: sc3 = p0sc3 else sc1 = p1sc1: sc2 = p1sc2: sc3 = p1sc3

drawscreen

goto main

 

Hopefully someone figures out what I couldn't.

scoretest.bas

scoretest.bas.bin

scoretest.bas.asm

[+Random Terrain]

If you are using an adapted version of this, you should have no problems:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#savehighscore

[SeaGtGruff]

I'm working on a game that switches between two scores that are kept in memory, so I have to handle the splitting and incrementing of these "virtual" scores by hand. The problem is that one of two things happens:

I think the corruption is happening because you aren't checking the digits individually. Plus, you aren't adjusting the digits for overflow until after you've already moved them to the score. And finally, this would all be easier if you used assembly.

 

Based on your ifs I take it that p?sc3 is the lo byte, p?sc1 is the hi byte, and p?sc2 is the middle byte. So I'd suggest something like this:

 

  if !player0y then gosub increment_p0score
  if !player1y then gosub increment_p1score
  rem etc.
  goto main
increment_p0score
  asm
  SED
  LDA p0sc3
  CLC
  ADC #$10 ; or whatever you need to add
  STA p0sc3
  LDA p0sc2
  ADC #0
  STA p0sc2
  LDA p0sc1
  ADC #0
  STA p0sc1
  CLD
  RTS
end
increment_p1score
  asm
  SED
  LDA p1sc3
  CLC
  ADC #$10 ; or whatever you need to add
  STA p1sc3
  LDA p1sc2
  ADC #0
  STA p1sc2
  LDA p1sc1
  ADC #0
  STA p1sc1
  CLD
  RTS
end

scoretest.bas

scoretest.bas.bin

[Cybearg]

If you are using an adapted version of this, you should have no problems:

 

http://www.randomter...l#savehighscore

What I'm doing isn't really like that at all. The problem comes from the adding and shifting values between variables and the score. Some kind of corruption happens with the BCD-compliant values, either in the way the score is displayed or in the way the numbers are handled. Comparing values and saving them works just fine.

[Cybearg]

I think the corruption is happening because you aren't checking the digits individually. Plus, you aren't adjusting the digits for overflow until after you've already moved them to the score. And finally, this would all be easier if you used assembly.

 

Based on your ifs I take it that p?sc3 is the lo byte, p?sc1 is the hi byte, and p?sc2 is the middle byte. So I'd suggest something like this:

 

if !player0y then gosub increment_p0score
if !player1y then gosub increment_p1score
rem etc.
goto main
increment_p0score
asm
SED
LDA p0sc3
CLC
ADC #$10 ; or whatever you need to add
STA p0sc3
LDA p0sc2
ADC #0
STA p0sc2
LDA p0sc1
ADC #0
STA p0sc1
CLD
RTS
end
increment_p1score
asm
SED
LDA p1sc3
CLC
ADC #$10 ; or whatever you need to add
STA p1sc3
LDA p1sc2
ADC #0
STA p1sc2
LDA p1sc1
ADC #0
STA p1sc1
CLD
RTS
end

 

I'll give that a shot! It certainly seems to work in the context of this demo, anyway.

 

So by the look of it, you set decimal mode, load the value, add to it, then use the carry bit to increment further numbers, is that it?

[SeaGtGruff]

So by the look of it, you set decimal mode, load the value, add to it, then use the carry bit to increment further numbers, is that it?

Yes, if you do it in assembly then adding to the lo byte with decimal mode set will take care of any overflow from the lo nibble to the hi nibble for you-- and if the hi nibble overflows (rolls over) then the carry will be set, so you just add 0 to the next byte without clearing the carry first. And if the middle byte overflows then the carry will be set again, so adding 0 to the hi byte will automatically bump it up as well. Basically, the decimal mode and the carry bit take care of everything for you.

 

Edit: PS, if you want to make the two subroutines more generic, you can put the value you want to add to score in a variable, then when you do the first ADC you would use ADC VARIABLE (whatever the variable is), rather than using immediate mode.

Edited June 18, 2013 by SeaGtGruff

[Cybearg]

Works perfectly. Thanks much, SeaGt!