AAA Ascii adjust after addition instruction

[weevilofdoom]

How would one say use this function to add say 10 ascii "numbers" together? (I'm assuming that you don't have to do any conversions of the numbers, just get them from the keyboard, but I can't get this to work, is there some sort of loop? I am boggled) The weevil of doooooooooom
-The eagle may soar, but the weasel never gets sucked up by a jet engine (Anonymous)

 

[straiph]

i think you find that this small collection of functions use unpacked bcd. that means each byte contains only 1 nyble value can be 0 to 9. if its packed then each byte contains 2 nybles. its been a while since i used them - why dont you have a play around and see what results you get.

straiph (im back! for a while a least, ive been away polishing my spanker of an OS)
"There are 10 types of people in this world, those who know binary and those who don't!"

 

[weevilofdoom]

I have messed around with this quite a bit, always get weird answers:
>aaafunc
First: 1023948692
Second: 1039683920
Sum: 20239486921039683920

after adding two 10 digit Ascii "numbers", this is what I get, and I'm kind of stumped, tried it several different ways, can't even come close, here is some code:

addstuff:
cmp [bx], 00h
je newLines
cmp [di], 00h
je newLines
mov ah, 0
mov al, [bx]
add al, [di]
aaa

mov stringOne, al
inc bx
inc di
jmp addstuff

this is a loop to go through "10" times on a null terminated string and add together the respected values, but it just isn't working out The weevil of doooooooooom
-The eagle may soar, but the weasel never gets sucked up by a jet engine (Anonymous)

 

[straiph]

are you using ASCII or BCD ?

AAA works only with unpacked BCD - that means each byte can only have a value from zero to nine. once the sum and adjustment has been completed you can then add 030h (i think) to get the correct ASCII code.
"There are 10 types of people in this world, those who know binary and those who don't!"

 

[lionelhill]

straiph is right.
... and some of the decimal adjust instructions assume you're holding 0..9 in a single byte, others 0..9 in the low nibble and another 0..9 in the high nibble.
The problem is that if you hold the number 89 in a byte as a binary-coded-decimal (BCD) then it looks like:
10001001 (binary)
(=099h, which is NOT 99 decimal normally!)
Now if you add BCD 1 (=00000001 binary)
answer (binary) is 10001010 (=09Ah, not the right answer, and illegal in BCD).
Therefore you need something to pick up on this illegal state, and make an unusual carry from bottom nibble to top nibble, to correct the answer, which should become
10010000 (=90h, the correct answer).
Note that in BCD the hexadecimal answer actually looks just like a decimal, which is the point of the excercise.
(But frankly I'd imagine lots of programmers get through their whole life blissfully ignoring BCD, and your average programme probably doesn't use it either).