At a savings of seven bytes! Very nice algorithm there; thanks, calc84.

The only potential problem would be in it destroying A, but that can be saved with a push/pop.

I don't think that works, because the top byte needs to take into account the carry from the middle byte, and you're just subtracting it from -1 unconditionally.

Dang, you are right. Zero won't work with that method as it returns FF000 which is not 0. :[ Does this fix it?

Code:

(12 bytes, again)
EDIT: Also, this is designed not to harm any other registers.

Yeah, I think that would work, though if you have a free register it would be much faster to back up A into it rather than using the stack. And if the register still needs to be preserved, pushing/popping it is still faster since you don't have an ex (sp),hl.

Ah, that is a much better idea. This saves 15 cycles, I believe:

Code:

(and still 12 bytes)

Thank you for your routines and optimizations.

Now I need a 16.8 division routine. I'll make it signed myself. I also searched for an algorithm on wikipedia and google, but I didn't really understand it...

I still need a fixed point 16.8bit square root routine. Does anyone know how this works?

Check out:
http://wikiti.brandonw.net/index.php?title=Z80_Routines:Math:Square_root

The one from z80 bits is pretty fast and small, i have no idea how it works though.

Thank you. I found an algorithm that will probably work.

I coded a square root routine, but it causes a crash (after 30 secounds of freeze), and I can't find out why.

This is my code:

Code:

Ok, this was really strange. I commented out the code of that routine by placing a #comment tag at the start and an #endcomment tag at the end, and kept moving the #comment tag down, testing it every time too see if the crash happened. After a while of testing, I could remove the #comment and #endcomment tags altogether witouth it crashing again, and I didn't make any modifications to the code.

I really don't understand this, but anyway, it works now.

Maybe it was a leftover bug from a previous test or program? That happens to me on occasion :/

I actually had this exact same problem with, of all things, TI-BASIC code. A for loop to do a math function was working incorrectly, so I added in a Pause command followed by an argument to check what the relevant values were equal to...and they were correct. The code ran fine. So I got rid of the pause, and it ran fine...then I ran the exact same program again...and that time, it messed up again!