Bregalad wrote:
Well I'll recommend to read this wiki article :
http://wiki.nesdev.com/w/index.php/Division_by_a_constant_integerIt is possible (and easy) to divide by 3 using only the accumulator, if the result don't exceed 8-bit that is. (the example code is for 4-bit, therefore there is 4 comparaisons, but if you need more bits in the result you need to do more comparaisons). If the result is 16-bit then you'd have to complicate the example code, splitting it into low and high 8-bits.
Caveat: none of this code is tested.
An alternative is to multiply by the reciprocal.
The reciprocal of 14 is (in binary) .0001001001001...
Since 14 has non power of 2 factors the reciprocal
is a repeating decimal which can be useful.
You need enough partial products to get your desired
accuracy, that is, if you want it accurate to the nearest
integer and the number you're dividing is a single byte
(max value ~256) your smallest partial product needs to be
<1/256 so that that partial product is less than 1
because you want it accurate to the nearest 1
So in that case (one byte divided by 14 accurate to the
nearest integer) you need to multiply by .0001001001
Defer the division of the partial products so that you
retain as much accuracy as possible.
Code:
sta temp
lsr
lsr
lsr ; A = number x .001
; don't clear the carry to get some rounding
adc temp ; C,A now contain 1.001 x number
ror ; ror not lsr, gotta keep C
lsr
lsr
adc temp ; C,A now contain 1.001001 x number
ror
lsr
lsr
lsr ; A= .0001001001 x number = number/14
Because it'a a repeating decimal you could roll
it up into a loop.
not so useful for a single byte divided by 14
but might be for 16 bits divided by 3
Also since it's a repeating decimal you can
Accumulate a partial product and save some adding.
1/3 (decimal) = .010101010101... (binary)
And in the case of 1/3 it repeats bytewise so you
can accumulate a byte's worth of partial product
and then shift by bytes.
so you might eg do a loop that accumulates four
of the partial products from the reciprocal and then
add the high byte of that in, shifted one byte,
to get the answer.
you'd generate number x .10101010
then shift that by a byte and add it in to get
Code:
.10101010
+ .000000001010101
= .101010101010101
and if you're only doing 16 bits accuracy, you only need
to add in the high byte (shifted by one byte)
some code (like I said, untested)
Code:
; A contains the number to be divided
; enter with
; A containing the hi byte of the number to be divided by 3
; Y containing the lo byte of the number to be divided by 3
; the hi byte of the partial product is kept in A or saved
; on the stack when neccessary
; save the number in lo_temp, hi_temp
sty lo_temp
sty lo_product
sta hi_temp
ldy #$03
clc
; each pass of the loop divides the partial product by 4
; and then adds number in lo_temp, hi_temp to that
LOOP
ror
ror lo_product
lsr
ror lo_product
pha
lda lo_product
adc lo_temp
sta lo_product
pla
adc hi_temp
dey
bne LOOP
; C,A and lo_product should now contain 1.010101 x number
ror ; get the high bit of the partial product
ror lo_product ; from C in to A so that A, lo_product now
; contain .1010101 x number
pha ; save the hi byte of the partial product
adc lo_product ; and add it back in shifted by one byte
sta lo_product
pla
adc #$00 ; propagate the carry from the lo byte
; A, lo_product now contain
; .101010101010101 x number
lsr
ror lo_product
edit: fixed the wrong way shifts jeez what a mistake to make!
edit: too many passes through the loop