Just some random input from me in response to chickendude: if your program doesn't need to do anything while waiting for a key press, _GetKey is actually pretty great. And if you want to avoid the ON issue, you can thankfully get around it pretty easily. Just change the call to _GetKeyRetOff (you won't find it in TI's include file, I recommend using BrandonW's much more complete file) which returns kOff instead of actually turning the calculator off.

Are you sure you're actually using the new ROM? It seems that actually running the setup wizard doesn't necessarily make the new ROM the default ROM.

Hex editing is really only feasible for really small changes, like changing an internal setting or a small snippet of code to adjust an existing behavior to be slightly different. You can't really expect someone to be able to completely add a feature with fully-functional GUI and everything via a hex edit, unfortuantely

For some reason, it seems that at some point in wabbitemu's version history, it developed the habit of forcibly injecting the alternative/third-party boot code called bootfree into ROM files you used. The issue with bootfree is that flash unlocks designed for the real boot code do not work with it. I would suggest making sure you have the lastest version of wabbitemu, going to the Help menu, and re-running the setup wizard to re-copy the ROM from your calculator. If you remember where you saved the appvar(s) from your original dump, you can just skip through the actual ROM copying until you get to the appvar selection point and re-use the old files.

How long does Pause 1 actually last?

This is one of the reasons I took it upon myself to start documenting the size and speed of Axe commands. If you open up Commands.html, select one of the "Show size and speed for" buttons, and find Pause, you will see that it takes approximately 3349*n cycles. The calculator normally runs at 6MHz, so you can figure out the time if you like.

However, that formula is not quite accurate, especially for small values of n. If (on a desktop browser) you hover your mouse over the speed information, you'll get a messy formula that exactly describes the number of cycles Pause takes. In the case of Pause 1, it's actually very hard to determine. Pause basically runs a loop inside of a loop, with the outer loop running the number of times you specify. But Paues was really designed for larger values where a small difference of one or two thousand cycles wouldn't matter, so for the sake of size optimization, on the first outer loop iteration, the inner loop iterates a number of times according to whatever value happened to be sitting in one of the CPU registers at the time. This first outer loop iteration, which in the case of Pause 1 is the only outer loop iteration, can run anywhere from 8 to 3349 cycles; all the following outer loop iterations will run at exactly 3349 cycles. You'd need to look at the disassembly of the code leading up to the Pause command and determine what value will be held in the b register (and sometimes it cannot even be determined) to know how long the first iteration will take, but that's probably overkill for now.

If you want to pause for a very small, precise amount of time, I would suggest something like the following:
For(N)
End
This block of code just executes an empty loop N times, and it will do so at about 13 cycles per iteration.

Oh silly me, I see the problem. The issue is that your interrupt takes longer to execute than the amount of time between interrupt timer requests, so as soon as one interrupt call finishes, another is made. To fix this, you probably want to add some code to your interrupt that results in the body of the interrupt, in this case the DispGraph^r, only being executed on some interrupt calls. One simple way to do this is with a counter that only executes the actual body of the interrupt every fixed number of interrupt calls. Here's a common way to do it:

..
1→I         .The counter
fnInt(A,0)  .I increased the interrupt speed for more counter precision
..
Lbl A
DS<(I,4)    .Only execute the body every 4 interrupt calls; play with this amount
DispGraphʳ
End
Return      .Axe automatically adds a final return if you don't, but it's still good practice to include it


No reason whatsoever. Good catch.