Please, read my post one more time. Don't worry about decimals just yet. They can be strange at first. Just display a point in between the decimal and the whole number, sort of like a pseudo-decimal number. This will make math many times easier if that is what you are planning, and you will be able to understand what is happening better. Look at the BEST link for bcalls, but remember, bcalls are just locations that the program jumps too. You can pretty much create your own versions as well.

EDIT: If you want to move in between each place value, just multiply by 10 each time you move left. For example, to change 4.99 to 5.09, I could add 10 to the number. From 5.09 to 4.09, I could subtract 100.

By the way, before it might happen, a register cannot hold a decimal.

Can someone please make me understand this better?

Sign
This byte determines if the number evaluates as positive or negative, and also if it is real or complex. For the uninitiated, a complex number is one of the form a+bi, where i is the square root of -1.
%00000000 — Positive and real.
%10000000 — Negative and real.
%00001100 — Positive and complex.
%10001100 — Negative and complex.
Exponent
The exponent field reports the power of ten that the mantissa is to be raised. The number format is not the usual two's complement, but rather biased to $80. A value of $80 translates as 10^0. $81 is 10^1. $7F is 10^-1.

Since links don't appear to be your strong suit, I give you this:



There is no two decimal places idea, rather, it is based on exponents. To use decimals you could change the Fix flag, but then your program is mostly just long list of bcalls.

You're on the right track, but missing some pieces:

Code:


Look at the second byte and subtract $7F from it. This will give you a number in hexadecimal. Convert it to decimal, and count that many digits over to see where the decimal is placed. So for example, $81 - $7F = $02, which is still 2 in decimal. So $10,$07 can be interpreted as 10.07. If you had $80 instead of $81, it would be 1.007, and if you had $82 instead, it would be 100.7.

Okay, so to work with floating point numbers, rather than direct assembly, which does tend to be slower, but I guess it really doesn't matter, this is how you would do that:


Code:


Notice how instead of _FPMult, you can call a whole variety of bcalls. Please note however, that my earlier suggestion would also work in the same idea, but now it might be easier. Does this code make sense?

Okay, without a buffer:


Code:

EDIT: Whoops, read those wrong. Yes, those should work in theory, but generally you would want to write them like this:


Code:



Code: