Unless the file is a subprogram.

request: For(var)

I know it wouldn't be anywhere near as optimized as For(const), but it would be faster than for(var, #, #) right?

Regarding that get-sprite routine, it's cool and all, but wouldn't it be better as part of some axiom filled with optimized sprite things.  The commands list is already pretty clogged up IMHO and I don't see the point of axioms if every other suggested routine will be made into a standard-supported one, especially if they're not staple ones needed.

Frankly, I've found a get-sprite routine wanting multiple times. I'd vote for removing rotCC() if you really think the number of commands should be minimized.

Meh, probably true, but perhaps an axiom for holding both the rotate commands, this new one, and perhaps a few others seldom used? 

How about, when the compiler hits an error, it displays the name of the source program the error is in?  It's really fun when there's like 10 source programs/libraries and they're all archived

What would GetSprite return?
Also, what's getPixel again?

Ah, ok. That would make sprite editors a lot easer, methinks. Oh, the fun things I could do with cloning...Hey wait, couldn't that be used to replicate the functionality of Pt-Off()?

This is less of a feature request and more of a feature no-brainer. I don't know how I forgot about this for so long.

As we all know, TI can be quite idiotic sometimes. And they were very idiotic when they decided to add ports 29h-2Eh. These ports don't do anything on an 83+. But on the 15MHz calculators, they inject an extra cycle into some memory access instructions. The affected instructions are opcode reads from flash and all memory writes. Apparently TI thought certain memory operations required a small delay, but as far as I and other experienced assembly programmers know, these delays aren't necessary. This means that on a 15MHz calc, any applications and OS calls will run about 5-25% slower and routines that write to memory will run perhaps 1-3% slower for no reason.

You may think, why not just have users permanently disable this delay? That sounds like a good idea at first, but you have to take into account all pre-existing programs. They were designed without knowledge of this port, so many of them may actually unknowingly rely on the delay for their program to run at the programmer's desired speed. For compatibility with all existing programs, this port needs to stay at it's original delay-inducing value. If you want your program to run faster on a 15MHz calculator though, ideally you would want to do is (if the calculator isn't an 83+) save the value of [wikiti]83Plus:Ports:2E[/wikiti], set it to 0 for the duration of the program, and then restore it to its original value when returning. This is done easily enough by reading the port, pushing it's value, outputting 0, calling the program, and then restoring the original port value before returning for good.


I guess the only question is how you would want to implement this. I see a few possibilities:

• Include this as a standard command, but instruct programmers to only call it once at the start of the program and not to use an instant return.
• Include an option inside the Axe application to automatically add this wrapper to all compiled programs. If the option is enabled, an alternate instant return routine would be used.
• Give programs the ability to define this option like metadata. If the option is enabled, an alternate instant return routine would be used.
• Automatically add this wrapper to all compiled programs. The instant return routine would be changed.

My favorite option would be the third one. It would be a good idea to enforce that this command exist before any code.