Supporting Numbers > 255 and Fixed Numbers with greater precision

[M12]

Does 7800basic have any built-in mechanic to support numbers larger than 255? And does it have support for fixed numbers with greater precision?

 

I've implemented my own multiplication function for fixed numbers, but the division function relies on iterations of the multiplication function, which leads to errors, so I believe I need to be more precise with my calculations and then round at the end.

 

Thanks

[+RevEng]

 

score0 and score1 are 24-bit numbers, but they only support addition and subtraction. You can use CARRY to add to larger numbers. The fixed point numbers max out at 8.8 bits of precision.

 

Most games won't need more than that, so these are compromises to keep the routines relatively small and fast. If your game needs more than that, it would probably be best to look at special-case/tuned code rather than a slow, large, general purpose routine.

[+RevEng]

Last thought for now. Often the fast way to do complex math on the 6502 is to not do it at all, and to use look-up tables. ie. the data statement in 7800basic.

 

If you can reduce whatever math you need to pre-computed information, it will be lightning fast compared to complex math. When you get into multibyte multiplication and division, the 6502 tends to get bogged down.

[M12]

If your game needs more than that, it would probably be best to look at special-case/tuned code rather than a slow, large, general purpose routine.

Yup, I am attempting to write my special-case code. It's rather tedious. Thanks.

 

Last thought for now. Often the fast way to do complex math on the 6502 is to not do it at all, and to use look-up tables. ie. the data statement in 7800basic.

 

If you can reduce whatever math you need to pre-computed information, it will be lightning fast compared to complex math. When you get into multibyte multiplication and division, the 6502 tends to get bogged down.

And this is definitely helpful. I was using an algorithm known as CORDIC to implement some trigonometry functions. ... But as long as I have the space, I ought to just make a large lookup table for my sine, cosine, and cotangent functions.

[M12]

The fixed point numbers max out at 8.8 bits of precision.

What do you mean by this?

[+RevEng]

What do you mean by this?

I meant that 8-bits of whole number precision, and 8-bits of fractional precision, is all the most precision you'll get from the built-in fixed number routines.

 

Thinking a bit more, you could eek out a bit more precision if your whole number portion doesn't ever exceed 127. Then you could just work with numbers 2 times their current value, as a sort of kludge to get 7.9 precision.

 

But your original post indicates you need larger whole numbers and more precision, so that's probably not helpful in your case.

[M12]

I meant that 8-bits of whole number precision, and 8-bits of fractional precision, is all the most precision you'll get from the built-in fixed number routines.

 

Thinking a bit more, you could eek out a bit more precision if your whole number portion doesn't ever exceed 127. Then you could just work with numbers 2 times their current value, as a sort of kludge to get 7.9 precision.

 

But your original post indicates you need larger whole numbers and more precision, so that's probably not helpful in your case.

Ah yup. I see. I read that x.y notation within the last few days and already forgot about it. Thanks! And your extra precision makes sense, but then I'd have to interpret the numbers in an odd way. I am getting around to not using fixed numbers at all in my program. Take 1.23 for instance. I just store that as the whole number as 123 and interpret it as 1.23.

 

In other words, forget about precision. Instead, I'm focused on making large numbers!

Edited August 28, 2015 by M12

[CPUWIZ]

Off topic, 1:1:6 format might be cool to have, for people who only care about values between -1 and 1.

[+RevEng]

Off topic, 1:1:6 format might be cool to have, for people who only care about values between -1 and 1.

I see some use. But then it gets complicated by people wanting the various formats to interoperate, and then I'm writing NxN multiply routines.

[CPUWIZ]

True enough.