@nabako As you may be able to tell by your post's weird formatting, "[sub]" is the forum's opening tag for subscript text. However, I believe you may have misread what actually said "[sup]", which is the forum's opening tag for superscript text.

Neither of these tags work in code boxes, though, which the author of the original post didn't seem to realize. So I'm guessing you're really wondering about "[sup]r[/sup]", which is supposed to represent a superscript "r". On the calculator, this is the radians token, found in the angle (2nd + apps) menu.

Axe can compile the application's code just fine, but it can't calculate the signature, which requires a relatively complicated cryptographic procedure. And calculators check this cryptographic signature when receiving an application and reject the application if the signature is wrong.

However, you can still send the application to a computer. As pimathbraniac mentioned, you need to sign the application on a computer. But (as long as you're on Windows) rather than grabbing the signing program and using it manually, you may find it easier to check out the "Tools\Application Signing" folder in your (extracted) Axe download. As the name of "Drag App Over Me.bat" suggests, just drag and drop the application (.8xk) file onto this to sign it.

And your loop should more or less get turned into that asm code, i'm not familiar with Axe but in your program try pressing [2nd]+[On]. You'll exit your program and the RAM your program occupied won't be freed (a massive RAM leak).

This should not happen, as Axe uses _GetKeyRetOff, which returns kOff rather than actually shutting off the calculator.

However, I agree that it's better to go with a _GetCSC loop in a case like this. Which, in Axe, simply translates to While 1 : EndIf getKey. If interrupt are enabled (which you can do with FnOn), put a Stop in the loop to save battery, too!

The ability to draw larger sprites such as 16 x 16 pixel sprites could be useful.

The Bitmap() command does this.

The option to run the program right after compile whithout having to go back to the home screen would be nice.

Sounds like a good idea.

Having Axe back up all files compiled (if multiple programs are included with the prgmNAME command) could be helpful.

Also a good idea, although it turns out to be a bit tricky to implement this. But I can look into it.

Axe could check if the program is the same before backing it up.

Another good idea.

If you attempt to run a source code file it could compile then run.

This would require a parser hook, which would clash with any other parser hook used to implement running programs from the home screen or hybrid BASIC libraries, and would make all BASIC programs slightly slower. So this isn't worth it. However, this functionality would fit well into any apps that already provide such hooks, like zStart or DoorsCS.

A global offset for all drawling commands would be nice (for scrolling games). Basically if the offset is 3x and 2y pxl-on(0,0) would turn on a pixel at 3,2

This shouldn't really be the job of a drawing comamnd, and it wouldn't really be any more optimal to include the functionality built-in. The user's code should make such adjustments.

The ability to write bytes directly to archive would be neat.

This is, for mostly all intents and purposes, not possible. Additionally, I'm not comfortable giving user code the ability to, whether intentionally or accidentally, destroy archived data or the OS— or if something went horribly wrong, the boot code, which would brick the calculator.

Add Memkit!!!

Yes, this should really be done. It could never fit before, but with all the optimizations that 1.3.0 brought, it might fit now.

Pause until something happens, like pause until the enter key is pressed.

Adding a built-in just for this would be entering the realm of feature creep. This can be done very easily in user code: Repeat <something> : End.

A command like Stop that makes the program quit rather than overflow an array.

I don't understand what the "overflow an array" bit has to do with this, but if I'm understanding correctly otherwise, the Return^r command does this.

The ability to make Axioms and to compile to appvar (possibly by having the first line .appvNAME instead of .NAME)

Libraries coded in Axe should be just that: coded in Axe. This provides many benefits, including the ability to easily see/modify the source if necessary and receiving the benefit of future compiler optimizations. If you're interested in particular features of the axiom system that are unavailable to Axe programs, you should request those directly.

As for compiling as an appvar, I can probably make an appvar compile target.

Maybe more areas of free RAM?

There aren't really many sizable areas of "free" RAM remaining. The fact that there were 6 decent sections and that there are 6 numbered list variables was a rather happy outcome that will probably remain that way.

If you want to search for more RAM to use, consider checking out thepenguin77's list.

Larger apps?

Multi-page app development is hard enough in assembly when you have full control of paging. Coming up with a relatively painless way to provide multi-page app development to Axe code is even harder. I've brainstormed approaches in the past, but never came up with a satisfactory approach.

Draw text to different buffers.

The fact that text can only be drawn to the main buffer is a limitation of the OS's text drawing routines. Trying to replicate said routines would involve a number of obstacles that (from my perspective) simply aren't worth dealing with.

Make the Line( command show up even when one end is off the screen.

This request has been around for a long time, and it's definitely one that deserves to be implemented. But implementing it in a complete and relatively optimal manner is rather daunting and I haven't (nor has anyone else) been able to do so.

A feature for a 2-dimensional list (matrix) would also be useful.

Considering 1-dimensional lists don't even exist in Axe, this is a bit of a stretch. Implementing such constructs (properly) would really require a type system, which Axe doesn't have. Such features are the kind of things I'd imagine in an Axe 2.0, but I don't see that becoming reality right now.

These are just some ideas I don't know how may are possible or feasable.

I'm grateful for all your suggestions. It's nice to see that some people are still interested in making Axe better.

Hey Runner can I modify the Axe command list to make it a little clearer (like changing corrupts to modify in the free RAM section)

If you have suggestions to make the command list better, I can simply include them in the official version for whenever 1.3.0 is really released. But yes, I agree that the "corrupt" wording is weird, and I'll fix it for 1.3.0.


EDIT: As a side note, if you have other suggestions like this, perhaps the general Axe Parser thread would be the place to make them.

Is there a way to re-size an appvar? I was hoping to just use x -> {ptr-2}r but that didn't work.
(I know about making a new one and copying, but My appvar can get bigger than half of max RAM)
Thanks!

In pure Axe, not really.

I may wind up using memkit...

Probably a good idea. MemKit's functions like should really be Axe built-ins, but for whatever reason, it's always hung around as an axiom.

Considering the developer is still active, he definitely seems like the person to approach with ideas, not me.