Bug Reports

[Quigibo]

Hmm... it might be more convenient return the offset by default, considering that zStart is the only program really using the API right now anyway.  Other programs would probably like to handle errors themselves too.  The output will be something like the offset in hl and the name of that program in OP1, which might be a subprogram.

[Runer112]

I think just returning the offset would work well. And for programs that do want traditional error scrolling, perhaps you could add an API entry point for scrolling to the error? The program or application could clean itself up after the compile error and then give control back to Axe to handle the rest.

[thepenguin77]

I found an error in the way the token hook is handled. When you copy the text string to ram, I noticed that you don't actually configure the first byte of the string. Since most of the tokens end up being somewhere in the 01xx range, the first byte of the ram string is 1.

But here's the problem. On closer analysis of how this hook works, that first byte actually means something. The format looks like this:

[Key code][length of string][string]

Where key code is the actual key you press to signal the token. As you can see, the key codes you are returning are incorrect and then that leads to all sorts of problems. (01 translates to right, when you use axe tokens in a Recall queue, the calculator hangs because tokens aren't actually being inserted)

So the simple fix is just to put the proper key codes in. The quickest way to get the proper key code is to simply put the token in DE and call _GetKeyPress, that will return the proper key in A.


Edit:
    If you are going to call _GetKeyPress from within your hook, make sure you temporarily disable the hook. Otherwise you're going to have fun with recursion.

[Runer112]

I found an error in the way the token hook is handled. When you copy the text string to ram, I noticed that you don't actually configure the first byte of the string. Since most of the tokens end up being somewhere in the 01xx range, the first byte of the ram string is 1.

But here's the problem. On closer analysis of how this hook works, that first byte actually means something. The format looks like this:

[Key code][length of string][string]

Where key code is the actual key you press to signal the token. As you can see, the key codes you are returning are incorrect and then that leads to all sorts of problems. (01 translates to right, when you use axe tokens in a Recall queue, the calculator hangs because tokens aren't actually being inserted)

So the simple fix is just to put the proper key codes in. The quickest way to get the proper key code is to simply put the token in DE and call _GetKeyPress, that will return the proper key in A.


Edit:
    If you are going to call _GetKeyPress from within your hook, make sure you temporarily disable the hook. Otherwise you're going to have fun with recursion.

Can you elaborate on this problem? I haven't noticed any problems with the hook in my testing of it. And I can't seem to cause any problems by recalling strings that contain Axe tokens or by entering Axe tokens into the recall prompt.

[Darl181]

I'm not sure if wabbitemu's exactly accurate in emulating, but I tried Fusion in it and now the programs list is taking a full-second-plus to display two programs and all apps are throwing Err:Validation
Edit: fixed by ram clear.

[DrDnar]

The Copy() command seems to be bugging out; see this post which describes the bug.

[kindermoumoute]

Torio found what bugged with link port on 83+fr only : link. Sometimes Get return 255 instead of 65535.

[Quigibo]

Nope, I double checked the routine. It definitely returns -1 if it fails.  I'm guessing that either the link cable is faulty or the result is being stored to an 8-bit variable instead of a 16-bit variable.

Also, I forgot, but the Send() and Get routines disable interrupts automatically for you.

[kindermoumoute]

When I try this code with a link cable and a 83+, it display error when I put cable on port :

Code: Select All | Copy To Clipboard

1 2 3 4 5

:Repeat getKey(15) :!If Get-255 :Disp "ERROR :End :End

So you're probably right, it's due to cable or port of calcs.

[kindermoumoute]

I take back what I said, today I tested more carefully returned values, and I noticed it : wrong value are divided by 2.
I noted 10 wrong transfer :

Spoiler for Hidden:

Sended : Received
14 : 7
1 : 0
12 : 6
5 : 2
2 : 1
6 : 3
14 : 7
13 : 6
18 : 9
4 : 2

It show wrong bytes are shifted (divided by 2). I don't know how torio get the other bug, but excuse me if I disturb you again.

[calc84maniac]

It definitely sounds like the timing in the linking routine is very relevant. I think Axe should probably use a "safe" linking method just like everything else written for the TI seems to use.

[Freyaday]

Axe is still accepting A°

[Runer112]

Axe doesn't really accept A° as much as it simply doesn't reject it. It's not being parsed as one unit, it's being parsed as A followed by °.... Whether Axe throws an error depends if °... is valid. And this shouldn't/can't be changed because one of the (awesome) properties of Axe is its loose syntax that allows for "units" to be linked together without an operator between them.

For instance, just one thing that pops in my mind is that such a change would break subroutine calls with one argument like Asub(B).

Pretty much, every Axe program I have ever written would be broken, as well as probably at least 25% of others' programs.

[calc84maniac]

Asub(B) is equivalent to sub(B) because HL holds the value of B, not A!

[Builderboy]

Not if subroutine uses HL itself like so:

Code: Select All | Copy To Clipboard

1 2 3

Lbl B ->C Return