1

I need to do division with fixed point. The Dev Kit has a lot of fixed point functions but there is no division function. It says the 68000 is too limited to include one!

But what if I need to calculate the gradient of a slope and get a fractional answer? Is there a way I can do this? Or maybe there is a faster way to find the gradient without division?

I am using C for this part of my program although I could write a function in assembler. My C and assembler knowledge is fairly basic. I've never used fixed point numbers before

Thank you for any help

2

You can always write your own (there are algos out there) but it's going to take a lot of time, depending on the bit width, perhaps around 500-1000 cycles.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

3

the 68000 can do 32bits/16bits division, with a result in 16.16bits format (16 bits remainder)
let's say you want do to 1.75/0.25 (result 7), you have those numbers in 8.8 fixed point, so you have 448/64
all you need to do is shift 448 by 8 (448 << 8 in C), you get 114688, and divide it by 64. you get 1792 which is the fixed point for the result 7.

quick C code:
int fixed_a = (int)(1.75 * 256.0); // 448
int fixed_b = (int)(0.25 * 256.0); // 64
int fixed_result = (a << 8) / b;
float float_result = fixed_result / 256.0; (don't use float, of course, if you want speed)

4

Brunni - wow that really takes a long time. I think one screen line on Neo Geo is 768 cycles!

Artemis - that is great! I like that idea of multiplying and then dividing when finished. Really appreciate the help. I am going to try to use that method for my gradient

5

if you want to get the final "float" result, don't divide by 256.0 it's too slow, shift right by 8, the idea is to keep integer number at all times (except for the init maybe)
int float_result = fixed_result >> 8; // you loose the floating point, but you have the closest integer value of your result

6

Artemis (./5) :
if you want to get the final "float" result, don't divide by 256.0 it's too slow, shift right by 8, the idea is to keep integer number at all times (except for the init maybe)
int float_result = fixed_result >> 8; // you loose the floating point, but you have the closest integer value of your result

Thanks Artemis. Yes i was planning to do a shift. I think I can keep it *all* integer (like you say) now I am doing the multiply/shift (by 256). I don't need the fixed point numbers any more as far as I can see. The multiply gives me the extra precision I needed

I looked around the net and saw the ultimate way to do gradients is with a look-up table.

You can store all the reciprocals : 1/2,1/3,1/4,1/5 etc and then multiply to get your gradient

or for even more speed store all the gradients up to a certain length of slope. It doesn't take up that much memory - especially for Neo Geo which has some space to spare on cart