6502 assembly: carry result in 16bit subtraction

Question

I have recovered an old 6502 emulator I did years ago to implement some new features. During testing I discovered something wrong, surely due to an error in my implementation.
I have to loop through a 16 bit subtraction until the result is negative: quite simple, no? Here is an example:

V1 equ $90  
V2 equ $01  
Label:
 sec  
 lda V2  
 sbc #2  
 sta V2  
 lda V1  
 sbc #10  
 sta V1   
 "Branch" to Label if result is >0, otherwise exit  
 rts  

Now, the problem is to identify which branch to select or to find a different solution. The BCS is not valid if the V2 subtraction clears the carry.
The BPL in not valid if V1 is 'negative' (>$80).
It should be easy, but...

EDIT
I did not find in the aswers a real solution.
Let me try to follow the logic, firstly with the original values as in code.

1. Carry is set by SEC
2. The fist sub (1-2) clears the carry. V1 = $FF
3. the second sub ($90-$0A-1 (not borrow)) results in V2=$85
4. carry is cleared; result ($85FF) is still negative)
   I can not test the result with BCS (to jump to label) nor BMI since V2 is negative.
   So?

With a different set, i.e. V1=$1 and V2=$0A I will have a result < 0, which is my goal to stop iterations.
Any suggestion?

Answer 1

Generally, a sequence like this (I've slightly amended the code in your question to make it more self contained)

V1 equ $91  
V2 equ $90  
 lda #00
 sta V2
 lda #20
 sta V1 
Label:
 sec  
 lda V2  
 sbc #2  
 sta V2  
 lda V1  
 sbc #10  
 sta V1   

will work as expected. With the values used in the code, the carry will be cleared after the first subtraction and will be set again after the second. If it is not, then the most likely cause is a bug in your emulator. I have run this in an online 6502 emulation and the carry was set by the time it got to the final sta V1. I also ran it in visual6502 and here is the trace output:

cycle ab    db  rw  Fetch   pc      a   x   y   s   p
0   0000    a9  1   LDA #   0000    aa  00  00  fd  nv‑BdIZc
0   0000    a9  1   LDA #   0000    aa  00  00  fd  nv‑BdIZc
2   0002    85  1   STA zp  0002    00  00  00  fd  nv‑BdIZc
4   0090    00  0           0004    00  00  00  fd  nv‑BdIZc
5   0004    a9  1   LDA #   0004    00  00  00  fd  nv‑BdIZc
7   0006    85  1   STA zp  0006    14  00  00  fd  nv‑BdIzc
9   0091    14  0           0008    14  00  00  fd  nv‑BdIzc
10  0008    38  1   SEC     0008    14  00  00  fd  nv‑BdIzc
12  0009    a5  1   LDA zp  0009    14  00  00  fd  nv‑BdIzC
15  000b    e9  1   SBC #   000b    00  00  00  fd  nv‑BdIZC
17  000d    85  1   STA zp  000d    00  00  00  fd  nv‑BdIZC
19  0090    fe  0           000f    fe  00  00  fd  Nv‑BdIzc
20  000f    a5  1   LDA zp  000f    fe  00  00  fd  Nv‑BdIzc
23  0011    e9  1   SBC #   0011    14  00  00  fd  nv‑BdIzc
25  0013    85  1   STA zp  0013    14  00  00  fd  nv‑BdIzc
27  0091    09  0           0015    09  00  00  fd  nv‑BdIzC

As you can see at the end, the carry is set (denoted by a capital C).

There is another problem with your code, by the way. If you have 2000 (decimal), then to load it into two locations, you need to convert it to hex before you slice it into two bytes. If you load 0 into a zero page location and 20 decimal into its successor, you've actually loaded 20 * 256 = 5120. The hex for 2000 is $07d0.

---

Following the latest edit to the question. Here is a simplified bit of code that subtracts $0a from $90 with the carry clear.

clc
lda #$90
sbc #$0a

And here is the Visual 6502 trace

cycle ab    db  rw  Fetch   pc      a   x   y   s   p
0   0000    18  1   CLC     0000    aa  00  00  fd  nv‑BdIZc
0   0000    18  1   CLC     0000    aa  00  00  fd  nv‑BdIZc
2   0001    a9  1   LDA #   0001    aa  00  00  fd  nv‑BdIZc
4   0003    e9  1   SBC #   0003    90  00  00  fd  Nv‑BdIzc
6   0005    ea  1   NOP     0005    90  00  00  fd  Nv‑BdIzc
8   0006    ea  1   NOP     0006    85  00  00  fd  Nv‑BdIzC

If your emulator leaves the carry unset in that situation, your emulator has a bug.

Answer 2

loop through a 16 bit subtraction until the result is negative

"Branch" to Label if result is >0,

Do you see that these descriptions contradict each other?
The 1st one continues on 0, the 2nd one stops on 0.
Only you can decide which one is correct!

---

From a comment:

This code is part of a Bin to Ascii conversion, made by power of ten subtraction. The bin value could be >$8000, so it is 'negative' but this does not matter. In the first iteration I sub 10000 each cycle until the result is 'below 0', then I restore the previous value and continue with the remainder. The problem is how to detect the 'below 0' condition as said in the post

Do ... Loop While GE 0

Next example subtracts 10000 ($2710) from the unsigned word stored at zero page address $90. The low byte is at $90, the high byte is at $91 (little endian).

Lo equ $90       ; The 16-bit bin is stored at zero page address $90
Hi equ $91
      sec        ; Because SBC subtracts the complement of C
      ldx #-1
Label inx
      lda Lo     ; Load from a zero page address
      sbc #$10   ; Subtracting immediate $10
      sta Lo     ; Store to a zero page address
      lda Hi     ; Load from a zero page address
      sbc #$27   ; Subtracting immediate $27
      sta Hi     ; Store to a zero page address
      bcs Label  ; Result GE 0 (greater or equal)
      rts

The X register now contains how many times 10000 fitted in the original number.

---

Do ... Loop While GT 0

You can add an ora instruction to see if the resulting word has become negative. Then you branch based on the Z from the ora and the C from the (last) sbc.

Lo equ $90       ; The 16-bit bin is stored at zero page address $90
Hi equ $91
      sec        ; Because SBC subtracts the complement of C
Label lda Lo     ; Load from a zero page address
      sbc #$10   ; Subtracting immediate $10
      sta Lo     ; Store to a zero page address
      lda Hi     ; Load from a zero page address
      sbc #$27   ; Subtracting immediate $27
      sta Hi     ; Store to a zero page address
      ora Lo     ; To define Z for the whole word
      beq Done   ; Result EQ 0 (equal)
      bcs Label  ; Result GT 0 (greater)
Done  rts

My 6502 manual says: "Above all, remember that comparing is done with BCS and BCC (not BPL or BMI).

Answer 3

I found a solution, cumbersone and inelegant, but effective:

           LDY #0
_B2D161    INY  
           PHA  
           TXA  
           SEC  
           SBC  #$10
           TAX  
           PLA
;----------------------  
           BCS  _BD1  ;normal flow
           SEC  ;set carry for the next sub
           SBC  #$28  ;the carry=0 would have incremented the minuend
           BCS  _B2D161  ;loop again
           BCC  _BD11  ;exit and restore the previous value
;-----------------------
_BD1       SBC  #$27  ;normal jump comes here
           BCS  _B2D161

_BD11      PHA  
           TXA  
           CLC  
           ADC  #$10
           TAX  
           PLA  
           ADC  #$27
           DEY  
           STY  _L10K
           ... continue with next section

The isolated section shows the variant applied: if the firtst sub clears the carry then this is 'emulated' by subtracting a valude increased by 1 (#28 instead of #27) and restoring the carry for the next sub.
In this way I can again rely on Carry to decide where to branch.

I wish to thank Sep Roland for the suggested code (the same that I originally used) which ubfortunatly does not do the job.