You are calling DelVar correctly. If nothing is happening, then either it doesn't exist or you have memory corruption going on. And since I assume that it exists for you to know the deletion doesn't work it may be memory corruption.

As for your GetCalc issues, try displaying the value it returns when you first create it and when you have to call it again a second time. They should be the same. If they differ, something you are doing is moving memory around and there isn't anything you can do besides call GetCalc again a second time like you do.

As for custom variables holding variables to hold function labels, that is perfectly fine.
:L Label->Variable .Store the address of the function to the 2-byte variable Variable
:(Variable)(1, 2) .Call the function pointed to by Variable, passing 1, 2 as arguments. No arguments is valid
:(L Label)() .The same as doing :Label()
The L followed by the space is the little uppercase L used for getting the address of a label. I can't put subscripts in code. It should be _LLabel

I don't have my calculator on me at the moment as I left it at work. I will bring it back with me on Monday and check out your A* bug then. What is your shift functions supposed to do? It looks like you are placing a node in a sorted list. Is that correct?

Does Axe not allow you to manipulate more than one appvar at a time? I'm getting some really strange bugs when I do. I have 2 appvars that I create in RAM. One is the appvar for the current generated floor in my game. The second appvar is supposed to be another map that I am going to use in my AI calculation that I call DistMap. I running across several strange bugs with Axe when I do this. If I create both appvars at the same time, I am no longer able to manipulate the DistMap appvar if I do anything with the Floor appvar. In this case all I am trying to do is fill it with some value for now. If I instead create the DistMap appvar whenever I press a button (down in this case), the tilemap gets corrupted somehow. Or rather, it seems as if the 2 pointers are getting mixed up somehow. Because when I try to move down a bunch of corrupted tiles are scrolled in instead. Any ideas?

Some code to see exactly what is going on would be helpful. Here is a summary of what GetCalc( does which may be helpful.

Everything in ram is stored between 0x9D95 and the VAT which is at the top couple hundred bytes of memory. The VAT (Variable Allocation Table I believe) holds information about everything in RAM that isn't locked down to a fixed address. It also holds information on where archived stuff is in flash is but that doesn't matter for your problem. When you use GetCalc() to open an existing program/appvar/other that is in ram, what it is actually doing is going to the VAT to look up where in memory the file is and returning that pointer. Since the file is in memory, ti-os may move the file whenever needed. Any time you create or destroy a file, you should assume any pointers you got from GetCalc() are outdated and that you need to get them again. There are rules as to what moves when, but unless you are really, really hurting for speed, just do it anyway. I don't think that existing files move when you make a new one but it doesn't hurt to make sure. Resizing almost always moves stuff around.
Since each file is nothing but a reserved space in memory, simply reading/writing to it is no different than manipulating a normal area in memory. From your description of the problem my guess would be that you are resizing or creating and deleting appvars which causes them to move in memory and throws off your pointers. If you are, remember that creation/deletion/resizing can be slow because it likely has to copy kilobytes of memory around. That shouldn't cause slowdowns if you do it once or twice a second, but I would avoid it in a loop. I would suggest using existing memory areas before resorting to appvars. There is a lot of built in memory if you look. Take a look at this if you want to to beyond what Axe's L1-L6 give you. It is pretty outdated in where it says Axe's variables are located so ignore those. For example 0x8000 gives you 256 bytes of memory and as long as you don't turn your calc off, it is perfectly free to use. (although it overlaps somewhat with the 756 byte buffer L4-512)

Here are some other fun facts that probably won't help you but may be interesting:
Appvars and programs are the same thing (as far as I know) and they only differ by one byte which tells what they are.
Pretty much any name is legal for a program/appvar as long as you don't intend on interacting with it through ti-os. You can make and edit programs with lower case names. Axe will even allow you to include and compile programs with lowercase names just like normal ones. Ti-os won't let you run a program with a lowercase name but as long as you compile to an uppercase program you will be fine. When transferring these programs to and from a computer, the ti-connect will irritatingly capitalize all the names.
"prgm#" and "prgm!" are special programs that hold recently entered stuff on the home screen. I don't remember exactly what each one does, but they exist. I'm not 100% sure on their names but I'm pretty sure those are it.
When you run a program, it gets moved to 0x9D95 (0x9D93 is the 2-byte size of the program) and then executed. So if you want to run a program from within an app, you can copy it there and just :Goto E9D95. Since there could be appvars there already, you should use some calls that aren't part of standard Axe to move anything that is there out of the way.

That is pretty neat! In all your dealing with floats did you come across a reason why ti-os uses 11 byte BCD floats? (with one whole byte for sign IIRC)
Is it just because BCD helps prevent any incremental errors?

Its a pity that I have (pretty much) finished my big z80 projects because there is several places I could have really used some floating points. I'm terrified by how close it's average of 1165 cycles is to a workaround I made a while ago using abs, min and max to calculate distance. I really need to set aside a weekend and add in floating points.

Testing gave me an average of 800 cycles for Axe's 16 bit integer square root. That's not much slower than your 32 bit floating point square root. Do floats just lend themselves to that kind of math?

_{Your link to GMP is broken...}

I googled and found this github page. I assume that is what you are using.

I'm not sure what the sdk is supposed to do, but I went ahead and just tried to get that file to run. I have a Debian partition and not Cygwin so any differences may of course be caused by the OS. I had a couple errors from libraries that weren't installed but after I installed them it got started for me. It errored out after ~30s of compiling due something or other. But it spit out a bunch of text.

I would suggest adding an echo to various lines so you can see how far it gets before exiting. That may give you an idea of what is causing the problem. Alternatively you can try setting up a virtual machine or using WSL and see if either gives better results. I haven't messed with Cygwin but I kinda doubt that it is the problem by itself but a fresh start may work if there is some system config that is causing the problem. If you give me a more detailed account of what you did I may be able to be more helpful. I don't know if @Vogtinator is still around...

Off topic, but why did you choose Cygwin over WSL?

hello
i just started using axe yesterday and wrote a simple program, and don't understand how "if" works. I've come here from Ti basic
here is my code
input"BRUH"->Str1
"BRUH"->Str2
GetCalc(Str2)->A
GetCalc(Str1)->P
If P=A
Disp"YAY"
End
!If P=A
Disp"NO"
End

I want it to only display "YAY" when "BRUH" is input, but for some reason it always outputs "YAY" no matter the input.
i am confused

@chucktheduck
Transitioning from BASIC to Axe is a pretty big jump. Although Axe's syntax looks like BASIC, it works in a completely different way. Very, very few segments of code work in both Axe and BASIC. You should be familiar with how pointers work. If you aren't, you should really spend 10-20 minutes reading about them because Axe uses them heavily. If you don't understand them, Axe will be one frustrating mess to use.


input"BRUH"->Str1 While this is valid syntax, it won't do what you think it does. It actually translates to:
:input
:"BRUH"->Str1Which means it gets the user's input, does nothing with it and then stores the pointer of the string "BRUH" to Str1. Names like Str1 or GDB1 are constants. Their value can't change once the program has compiled. (The data they point to can change) This means they can't hold any value that you can't figure out when the program is compiled. Use variables to do that instead. Doing input->Str1 won't work because the value input returns may change, instead you need to use a variable like A. So: input->A


input returns a pointer to tokens. Tokens are different than characters because they can be 1 or 2 bytes long. I won't explain how they work because it is a bit complex. But if you stick to uppercase letters and numbers you will be safe because they are all 1 byte.

When debugging it is always useful to print the values of variables. Even if you are sure what they are, it is never a bad idea. :Disp A will try to print a string so it will look like gibberish. Instead, use Disp A>Dec to display it as a number. In your case, no matter what you input A and P will both hold 0. GetCalc returns a pointer to a file if the file exists in RAM or 0 otherwise. GetCalc("YAY") or GetCalc("BRUH") both return 0 because there is no file with either of those names. (So P = A) Files are things like "prgmTEST" or "appvSOMEDATA" You can use GetCalc to read and write to programs and appvars. I'm not sure what you are trying to do with it, but the documentation for it isn't very clear so I assume you misunderstood what it does.


Here is some code that should do what you want. I haven't tested it but I'm pretty sure it will work.
:.Comments start with a period. You don't need to include them in your code
:input->A            .Get a pointer to the entered tokens
:"BRUH"->Str2        .Get the pointer to the characters B, R, U, H. This line can be put anywhere in the program and it will function the same. I like to put my data at the end but that is up to personal preference.
:                  .If you want to test if two strings are equal, you need to loop over them and compare every byte.
:0->X                  .X holds where we are in the string. To compare equality, you need to loop over every byte in the string and compare it. (This is what other languages do too, they just hide it from you)
:1->Y                 .Y holds 1 for true. If we find an inequality, we should set it to 0 because the strings aren't equal
:For(length(Str1))         .Loop for the 'length' of Str1 Since input returns tokens and not characters, this may not work correctly if you use anything besides uppercase letters and numbers. (I won't explain why now because tokens are pretty complex)
:                              .The single argument for loop just runs the given amount of times. For(5) will run the body of the loop 5 times.
:!If {A + X} = {Str1 + X} .If the characters aren't equal save the value 0 to Y so we know they aren't the same
:0->Y
:End
:X++            .Increment X to the next character
:End
:
:If Y            .If Y is not 0 then the strings are equal
:Disp "YAY"
:Else
:Disp "NO"
:End


Additionally you can use Equ>String(A, Str1) to do the same thing as the loop. It is a good idea to understand how the loop works. Note that Equ>String returns 0 if the strings ARE equal and non zero if they ARE NOT.


If you haven't already, install a shell like zStart or DoorsCS7 to allow you to edit your code from archive. (this isn't a recommendation, its practically a must) Messing up in Axe means your calculator resets RAM so any programs left there will be deleted. I recommend zStart because it lets you press ON+Zoom to compile and run your code from within the editor as well as use ON+Vars to show a list of all Lbl's that you can then teleport your cursor to. Much easier than Alpha scrolling for large programs.


That was a lot. Hopefully I explained it all clearly. (If not, I am happy to explain more - I get really excited talking about Axe!)

That's pretty cool. Writing a project that large in asm must be really time consuming. Less than 10 app pages? That seems kinda large. My biggest project comes out to almost 16 pages but that is because it was compiled in Axe and is in greyscale. Do text and sprites eat most of that?

11k is really small. Maybe I inflate my Axe source file sizes with long variable names and lowercase but I can't make anything near that functional in that size.
Is there a saving system?