Quote from: c4ooo on December 08, 2015, 08:37:43 am

Quote

[8:31:56 AM]   c4ooo   @runer do you think it will be possible to add #org() command specifying the call ofset?
[8:34:17 AM]   c4ooo   #org() - change org to default #org(int) - change org to int #rel(0/1) to force relative addresses to be used (1) / not used (0)[and give an error if needed]

It may be possible to allow changing of the code origin. Out of curiosity, what did you want this feature for?

However, I don't think a position-independent mode would be feasible. The CPU doesn't provide any instructions to support relative calls or memory accesses, and the only instructions that support relative jumps have a limited distance.

This would be helpfull for modular programs. What i would do is disallow data creation in rel(1) mode (so no inline data and stuff); and error if the jump is over the 127 byte limit.

In what context might a "modular program" be useful? Note that you'd also lose the ability to call functions, including all of Axe's built-in functions, which would really restrict what useful things one could do. You could possibly do more useful things with assembly, which seems to me like the more appropriate langauge in which to do tricky things like this anyways.

My idea was to load the code into ram by sections, so that the program could be bigger. (But have some of its data in appvars)

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.

Don't really know why you would not archive it. Saving programs might be a bit longer, but it's still a lot better than duplicating the program in memory, which is what the backup does. Archiving just gives it a double failsafe. Plus, you can use it as a temporary version control (though with only 2 versions) since axe doesn't backup archived programs.

I have a couple more ideas!
The a function like the += command in Java would be really cool! (5 +-> x instead of x+5->x)
Setting to zoom compile by default
The ability to treat lists like matrices (like # -> {L1}{row}{col} instead of # -> {rows # col + row + L1}) would save SO many headaches
Again, I don't know how easy to add any of these are. (but the matrices one would be really nice)

Add a line per line debug function

While that would be awesome, I don't think that would be very practical on calc.
If you want a debugger your best shot is wabbitemu.