Hikaru wrote: ↑Sun Dec 31, 2017 4:40 pm

IIRC division by 3 is the same as multiplication by #55. Then you can shift the result right once to get division by 6. Not sure if that helps?

Edit: seems like it's actually #55+1 for more accurate rounding, or something.

This seems to work:

Code: Select all

```
;In: C = dividend
;Out: H = quotient
ld l,c
ld h,0
ld b,h
add hl,hl
add hl,hl
add hl,bc
add hl,hl
add hl,hl
add hl,bc
add hl,hl
add hl,bc
add hl,hl
add hl,bc
srl h
```

Actually I found this for divisions by 10

http://z80-heaven.wikidot.com/math#toc25
10 bytes (and 81 t-states). It divides E by 10, returning the result in H :

e_div_10:

;returns result in H

ld d,0

ld h,d \ ld l,e

add hl,hl

add hl,de

add hl,hl

add hl,hl

add hl,de

add hl,hl

From by understanding of it, It actually mutiplies by 26 (=~256/10)), and gets the high part only.

So it's basically, multiplying by a value that will get you the required division, once we divide by 256 (which is just to get the high part).

This can probably be done with other division values.

Probably if multiplying by 42 (=~256/6) it will probably work.

Going to make some calcs on Excell next

UPDATE:

It almost works, until 60, it works for all values, except when dividign exact multiples of 6.

There is the factor that the error (fractional part of division 256/6), keeps adding up.

If mutiplying by 43 (42+1), it works flawlessly until a dividend of 130, where it starts to fail after 131, due to rounding error again.

For my own purposes, I only need something that works between 0 and 77.

This is to detected a condition, when a player starts to add up combos.

130 is enough for my case, since playfield is 07x11, so, at most a usar can make a combo of 77 items.