But what causes it to not be usable at 15MHz?

I know it's assembly. I understand that some optimization makes it impossible with 15MHz. But what's different at 15MHz than 6MHz?

The screen needs a delay of about 10microseconds between inputs, otherwise it shows garbage (not the band, sadly). @6MHz the processor is slow enough that this isn't a problem, but @ the higher speed it's faster than that.

Yeah. Basically there is a delay included in the routine, and it's long enough in 6 MHz mode, but the 15 MHz processor goes through the delay too quickly.

In the next version of Axe, Quigibo will releasing a fix that puts the calculator in 6MHz mode before running the DispGraph routine and then returns it to the CPU speed it was previously running at when it finishes.

Updated for Axe 0.5.2. As usual, the updated file is attached to the first post. I'm also going to start a more detailed changelog, in case people are interested in knowing what exactly changed between versions of Axe. [NEW] denotes new Axe commands, [CHG] denotes changed Axe commands, and [FIX] denotes commands that haven't changed but have corrected information.

Changes:

• [FIX] Header size information
• [FIX] Added notes specifying that most 2-byte backwards loading commands are broken
• [CHG] Negative 8-bit constant equality checking (e.g. =⁻42) now works
• [NEW] Trivial comparisons ≥0, >65535, ≤65535, and <0
• [CHG] Constant unsigned comparisons (≥ > ≤ <) are smaller and faster  —  ~2 bytes smaller, ~8 cycles faster
• [CHG] >VAR and <EXPR optimized for size  —  1 byte smaller, 5 cycles slower
• [NEW] Optimizations for bitwise logic operations with constant operands
• [NEW] Optimized For() loops if the upper bound is a constant  —  1 byte smaller, 17 cycles faster
• [CHG] Nibble reading commands changed as a result of a bug fix and are now big-endian
• [NEW] Routine for preserving CPU speed and interrupt status before display commands
• [CHG] Adjusted all buffer display commands for the addition above
• [FIX] Speed estimates for commands that access the LCD
• [CHG] Full is smaller and faster  —  1 byte smaller, 3 cycles faster
• [CHG] All GetCalc() routines properly handle pointers to real and complex float variables
• [CHG] Archived variable locating routine optimized for size  —  5 bytes smaller
• [CHG] Pt-Mask() bug fix to work properly for aligned sprites

Just wanted to mention one other thing to add to the list; I turned the DispStrApp and TextStrApp inline routines into subroutines.

Updated for Axe 0.5.3. As usual, the updated command information document is attached to the first post.


Changelog:
[NEW] denotes new Axe commands, [CHG] denotes changed Axe commands, and [FIX] denotes Axe commands that haven't changed but have corrected information. Red denotes a bug. Green denotes a change that I deem to be awesome.

• [CHG] All 2-byte big-endian loading and storing commands now work
• [FIX/0.5.2 CHG] Added trivial math operations +0, -0, *0, *1, *65535, /0, /1, //0, //1, ^1, ^65535        (If you're reading this Quigibo, did I miss any?)
• [FIX/0.5.2 CHG] Added notes specifying that //0 and ^65535 are mathematically incorrect
• [CHG] Any of the trivial math operations listed above that result in no compiled code cause a crash during compiling
• [NEW] Increment and decrement operators ++ and --
• [CHG] Nibble storing routine adjusted to access nibbles in big-endian format, like the nibble reading routines
• [FIX/0.5.2 CHG] The routines to draw strings in applications converted into subroutines
• [FIX] Adjusted the cycle estimates for p_NewLine, p_ClearScreen, and p_SaveToBuffer
• [CHG] Optimized p_FastCopy  —  1 byte smaller, 1548 cycles faster
• [CHG] Optimized p_DrawAndClr  —  2 bytes smaller, 1548 cycles faster
• [CHG] Optimized p_DispGS  —  ~5000 cycles faster
• [CHG] Speed-optimized p_Disp4Lvl and improved grayscale quality  —  3 bytes larger, ~7500 cycles faster
• [FIX] Adjusted the cycle estimate for p_DKeyExpr
• [FIX] Adjusted the cycle estimate for p_Div
• [FIX] Adjusted the cycle estimate and notes for p_SDiv
• [NEW] 8.8 fixed point reciprocal command ^-1  —  29 bytes, ~1349 cycles
• [CHG] Division and signed division have a bug that will cause them to always return 0 if the divisor is greater than 255
• [CHG] Speed-optimized p_Sqrt  —  15 bytes larger, ~5500 cycles faster
• [FIX] Added a note mentioning that p_FlipH can produce a garbage sprite

If Quigibo wanted to release this with Axe, he'd either have to keep it up to date himself or give me new versions of Axe about a day in advance so I can update the file and give it back to him. Supposedly we're very close to Axe 1.0.0 though, for which he may or may not want a file like this being packaged into the sort of "final" version.