hi jez,

this is a brute approach, but is definately faster than the compare and increment algo
i use a lookup table to store the square roots. since i consider only 256 number the total table length is 256 bytes. And again it is an approximation of the square root, for example the square root of 80 would be farther away from 8 than 9, but neither of the two. this approach needs 256 bytes for the lookup table and 6 bytes for the table accessing code.

In "Division Algorithms and Implementations",IEEE Transactions on Computers Vol 46, No.8 , August 1997, S.F.Oberman and M.J.Flynn state
"It is shown in [3] that square root operations occur nearly 10 times less frequently than division in typical scientific applications, suggesting that fast square root implementations are not crucial to achieving high system performance."

This paper was ment for hardware implementation of FP Divison Alogrithms, but assuming the same probability could apply to the software implementation, i wouldn't think wasting 262 bytes of program code for inaccurate square root calculations is worth the trouble, but then this could another approach to the problem. I hope this is of help.

cheers,

sushil
;-------code-------------
mov a,#4eh
mov dptr, #sqrtlookup
movc a,@a+dptr


org 300h
sqrtlookup:
DB 0 ; 0
DB 1 ; 1
DB 1 ; 2
DB 1 ; 3
DB 2 ; 4
DB 2 ; 5
DB 2 ; 6
DB 2 ; 7
DB 2 ; 8
DB 3 ; 9
. .
. .
. .
DB 15 ; ff
DB 15 ; ff