6502 newb question - how to count 0 to 65536

[Tyrop]

I am wondering if there is a niftier way to do this than using a lot of branching based on the carry flag, say using ADC?. Or maybe that is already the most efficient way?  I am looking to use 3 bytes so the end result will be 3 memory locations reading 00 00 01.

[Rybags]

For a simple count you could use INC or ADC.  3 bytes gives ~ 16 million values.

The branch is only needed if doing INC.  Use CLD before the ADC sequence if in an interrupt or unsure if you could be in decimal mode.

 

  lda count

  clc

  adc #1

  sta count

  lda count+1

  adc #0

  sta count+1

 

For 3 bytes there you can just repeat the count+1 actions for count+2

 

Using INC... 3 byte e.g.

  inc count

  bne noinc1

  inc count+1

  bne noinc1

  inc count+2

noinc1

 

 

Edited January 28 by Rybags

[+VinsCool]

It depends on how exactly you want to make use of it, but I imagine it is not intended to be very complex.

If you only want to increment by 1, using the INC and BNE instructions may do a good job for it I think.

 

I was thinking about something like this:
 

counter	dta $00,$00,$00

increment
	inc counter+0
	bne increment_done
	inc counter+1
	bne increment_done
	inc counter+2
increment_done
	rts

 

Once the counter+2 value had incremented, you will have $00,$00,$01 in memory.

 

[EDIT] Darn, I was a bit too slow, lol 😅

[Tyrop]

Thank you for the responses. So in Rybags’ first example, there are 2 ADC’s but 1 CLC. Wouldn’t I have to put a CLC before the second ADC?

[phaeron]

1 hour ago, Tyrop said:

Thank you for the responses. So in Rybags’ first example, there are 2 ADC’s but 1 CLC. Wouldn’t I have to put a CLC before the second ADC?

No, you specifically need to keep the carry flag to bridge the carry out of the first addition and into the second. That's how the two ADCs combine their 8-bit additions to calculate a 16-bit addition. The CLC at the beginning is needed to prevent joining with some unrelated previous calculation.

[tebe]

Mad Pascal

var e: cardinal;

begin

 for e:=0 to 65536 do ;

end;

 

compile, view file *.a65

    lda #$00
    sta E
    sta E+1
    sta E+2
    sta E+3

l_008C
; --- ForToDoCondition
    lda E+3
    cmp #$00
    bne @+
    lda E+2
    cmp #$01
    bne @+
    lda E+1
    cmp #$00
    bne @+
    lda E
    cmp #$00
@
    scc
    jne l_0096

; --- ForToDoEpilog
    inc E
    bne @+
    inc E+1
    bne @+
    inc E+2
    bne @+
    inc E+3
@
    jne l_008C
l_0096

 

Edited January 28 by tebe

[Wrathchild]

@Tyrop Do you need to hold the value 65536 as you could simply detect the loop back to zero instead and only use a 2 byte counter.

 

DoTest
 JSR ResetCounter
TestCounter
 JSR IncCounter
 BNE TestCounter
AllDone
 JMP AllDone
 
ResetCounter
 LDA #0
 STA Counter
 STA Counter+1
 RTS

IncCounter
 INC Counter
 BNE @+
 INC Counter+1
@
 LDA Counter
 ORA Counter+1
 RTS

 

[flashjazzcat]

You can omit LDA Counter/ORA Counter+1 and it will still work.

[Tyrop]

16 hours ago, phaeron said:

No, you specifically need to keep the carry flag to bridge the carry out of the first addition and into the second. That's how the two ADCs combine their 8-bit additions to calculate a 16-bit addition. The CLC at the beginning is needed to prevent joining with some unrelated previous calculation.

Thank you for the explanation. But there will also be a third ADC because I am counting to 65536.  If I do a third ADC and the carry bridges over to the third ADC, won't the third byte increment prematurely, and won't it increment every time the first byte goes past $FF? 

[phaeron]

3 minutes ago, Tyrop said:

Thank you for the explanation. But there will also be a third ADC because I am counting to 65536.  If I do a third ADC and the carry bridges over to the third ADC, won't the third byte increment prematurely, and won't it increment every time the first byte goes past $FF? 

Nope, because after the second ADC the carry flag will only be a 1 if there was a carry out of the 15th bit. ADC sets the carry whenever the addition result it computes has the 8th bit set, or is >= 256. Any carry state coming in is used and replaced by the new carry state, it's not cumulative. It always reflects whenever there was an extra count overflowed out of the last addition that needs to be added into the next addition of the higher order byte.

 

If you have $0102FF, then the first ADC #1 computes $FF + 1 + 0 = $100, so the first result byte is $00 and C=1. The second ADC #0 computes $02 + 0 + 1 = $03, so the second result byte is $03 and C=0. The third ADC #0 computes $01 + 0 + 0 = $01 and C=0. The full result is then $010300.

 

If you have $01FFFF, then the first ADC #1 computes $FF + 1 + 0 = $100, so the first result byte is $00 and C=1. The second ADC #0 computes $FF + 0 + 1 = $100, so the second result byte is $00 and C=1. The third ADC #0 computes $01 + 0 + 1 = $02 and C=0. The full result is then $020000.

 

[Tyrop]

Ahhh!  There was my misunderstanding.  I thought once the carry is set, it will remain set until it is cleared.  I didn't realize that a new ADC will flip the carry back to 0 if there is no carry.  Thank you!