133794m3r,

In Axe, the ONLY data type there is is the 16 bit (and sometimes 8 bit) integer. Why? It's the hardware. The biggest register is 16 bits...so yeah. There are different ways of reading this number (signed, unsigned, char, etc.) but it is still only a number. Fixed point notation is just that- notation. It is a different way of representing a 16 bit integer. As such, all the limitations that come with dividing and multiplying integers still exist.

Let's take a look at the example 1.0/*10.0. Runer explained it up above, but I'll attempt to explain a little differently since you didn't seem to get it the first time.

First, understand that that all that the decimal point does, is convert the value from fixed point notation to an integer. Remember fixed point notation means this: high byte is the integer portion, low byte is a fraction of 256. So, 0.5 in fixed point will become 128 (because 128/256 = 0.5). Similarly, 1.0's integer representation is just 256. 10.0's is 2560.

Anyway, the fixed point division returns 1/10, which is actually the integer 25. Why? Because 1/10 of 256 is 25.6, but that's a no no because everything is still integers really, so you just get 25. Then it goes on to **10.0 which just takes your 25 and fixedpoint multiplies by 2560. Which is the same thing as regular multiplying by 10, which is why you get 250.

So basically, what you have to keep in mind when doing math in Axe are two things: one, divisions will always truncate the decimal part. That's just the way it is, you can ask around and explore the ins and outs of writing an integer division routine. Using fixed point can lessen the impact of this  phenomenon, but it won't eliminate it, especially as you work with smaller and smaller numbers (like 1/10). Second, all Axe operations move left to right. The only order of operations cue there is are parentheses. That might be why you were having trouble with 2/10*65535; Axe saw 2/10, which is 0, and then multiplied 0 by 65535, which is still 0.

Depending on your numbers, you should (mostly) be able to play around with the way you write your statements to achieve a respectable degree of accuracy. Typically you want to try to get as large a number as you can before performing a division. For example, you can get 1.0/*10.0**10.0 to return 256 if you do 1.0**10.0/*10.0. Unfortunately, you have to be careful not to get a number larger than 65535, otherwise everything will break. So, 2/10*65535 becomes a little trickier. But you can still do it; while 2*65535/10 is not going to help us (because 2*65535 goes over 65535), 2*32767/5+1 gives you 13107. You can play around with the numerator and denominator a bit to try to get optimal results. This is the down and dirty truth of Axe and z80 asm in general. If you want something more accurate and/or larger range than 65535 (or -128 to 128 with x256 accuracy), get ready to write some really complicated routines.

I have been working on a fun rpg game with an advanced movement system for two months, when I tried compiling it passed the first run then it stopped the second run with a battery low error, it deleted my source and corrupted my backup!

this morning I was compilating a programme
when I get

UNKNOW ERROR
99% compilating at second pass
 

-I try to see my source but it doesn't respond to any keys except [alpha] and [seconde] (the icon at right top corner was visible)
-some weird stuff with screen : blacks rects appear and dissapear quickly.

So I pull over batteries, have a clear RAM.
Then I check the memory (to see if anything was corrupt), and I see the axe appv in RAM
size 16280 octets !!!!!!!!!!
I deleted it and then I have an other clear RAM
now everything is ok.


CALC STATE :
-Ti-84+
-hardware rev B
-OS 2.43

AXE STATE :
-ion compilating
-alpha on
-safety off
-ver 1.2.1a

I saddely lost the source but maybe I can rewrite it.

I succed to reapet this error 6 or 7 time on an emu. 

It's look like it's a problem with a low memory situation. (RAM=10000 octets, ROM=12000 o and compiling a 5000 o prog)

And when it start to compile and there will be this error,  press ON during the comp will throw the error. 

This really a strange bug....

Bump,

It seems that compilation as App is completely broken with Axe 1.2.1a ... I can't even compile an empty program as an app, it always says "UNKNOWN ERROR" and then send me at the end of the source.

Error code :009DB900B3AB3FB4
B3ABB3AB55D48AA7
1F00000040018478
8B8068CB
EDIT : I re-sent Axe 1.2.1a to my calc (exactly the same version) and compilation as app worked

Just checking, you know that it displays the token pointed to, right?

http://axe.eeems.ca/Commands.html#textCommands

In what scenario are you trying to display this token? Usually tokens are displayed as part of a program or OS string, in which case you should have a pointer to the token. There isn't really much reason to be displaying a constant token, which I think should be the only time when you wouldn't have a pointer to it.

(If you're wondering why the command is like this, it's because there is a B_CALL to easily draw a token pointed to, but not one to draw a token itself.)

Oh, well in that case you should still be able to display the token fairly simply. Instead of using the variable itself, use the pointer of the variable holding the value, perhaps like:

Disp °T►Tok


And just to clarify, this behavior of ►Tok is not a bug, it does exactly what Commands.html says it should.