Oh wait... do you actually have a plain TI-84+? If so, that's totally fine for using Axe. The TI-84+SE is just a TI-84+ with more storage, which is mostly unnecessary.

If anything, you could sell the TI-84+CSE. For hobbyist usage, it's actually less useful than the older monochrome calculators (but the newer TI-84+CE is probably better than both).

Reading the included Documentation.pdf, although it's somewhat outdated and certainly doesn't cover every language feature, is probably the best introduction to the language. I'd also recommend reading Changes.pdf, which can be found in the Axe 1.0.0 release (but don't actually use Axe 1.0.0), as it details some important language features added with that release that aren't covered in the main documentation.

After reading both of these, I would finally recommend looking through Commands.html, which is the exhaustive language feature/command list, and pick out and play with commands that interest you. This document is by far the most useful language reference, and I recommend always having it on hand while using and still learning the language. Some people just view it in their browser, some people print it out, and now, thanks to @E37, you can even view it right on your calculator (get it via the first attachment to that post, AxeDoc.zip).

There's also one excellent, very comprehensive Axe tutorial, but there's a slight caveat: it is written in French. Although there will be some annoying translation errors, I believe that running through it with a browser-based translation service is still the best comprehensive Axe tutorialization experience there is.

Ok. I think I have found another. (I'm not sure what's causing it)
I have found that recompiling a certain app causes flash corruption. I'm not 100% sure but it has happened 2 times in a row.
It does use hooks and inline assembly but I have used similar programs without mishap.

Since I need to reset my calc anyway I figured I will try to figure out what is causing it. (I'm sure it is Axe since I haven't been using assembly recently and I have been using the same apps for a year and they never showed any problems)
Oh, and it is 1.2.2a as always.

Nothing immediately comes to mind as a possible reason for this. I think the only way I'd be able to reliably track down a bug like this would be if I could reproduce the bug in an emulator and actively debug it. However, it seems likely that your specific code and/or calculator environment may have something to do with it, as I haven't heard other reports, so reproducing it from scratch would be difficult.

Which ROM did you guys use? I tried different GBA and GBC ROMS from different websites, and every single one doesn't work can someone suggest a ROM website to use? Many thanks 

As the first post and the readme both mention, this emulator supports only original Game Boy games. Game Boy Color and Game Boy Advance games are not supported (and due to significantly higher emulation requirements and the fact that this project and calculator model is mostly dead, likely never will be).

A suggestion of a my two favorite original Game Boy games that should work: Pokemon Red/Blue (maybe Yellow?) and Link's Awakening (not DX).

This is because of Axe's weirdness of all functions sharing the same argument variables, r₁-r₆. Often you can fix the problem by using the "recursive" syntax that you initially tried using, but that turns out not to even help in this case. That's because argument values are saved to their respective variables immediately after they're evaluated, making code like this:

Lbl DrawChar
  Mask({r₁},{1+r₁},256*{3+r₁}+({2+r₁}-1*64)+r₂)
Return

Really act like this:

Lbl DrawChar
  {r₁}→r₁
  {1+r₁}→r₂
  256*{3+r₁}+({2+r₁}-1*64)+r₂→r₃
  Mask()
Return

As you can see, r₁ is overwritten after evaulating the first argument and r₂ is overwritten after evaluating the second argument to the Mask() call, resulting in their uses in the second and third arguments producing bad values.

Although it's rather annoying/silly, a simple way to fix this is to assign the argument variables manually like demonstrated in the code block above, but in the reverse order, so none are overwritten before their old values are done being referenced (if there were cyclical dependencies, you'd have to introduce temporary stores as well):

Lbl DrawChar
  256*{3+r₁}+({2+r₁}-1*64)+r₂→r₃
  {1+r₁}→r₂
  {r₁}→r₁
  Mask()
Return

Also, because Axe is really dumb and doesn't (yet) know about the commutative properties of mathematical operators and how to optimize by switching operand order, I would recommend that you get in the habit of doing this yourself. It is almost always best to make constants the second operand, or if neither operand is a constant, try to make a simple variable the second operand. Here's the fixed code from above with this optimization applied in a couple places:

Lbl DrawChar
  {r₁+3}*256+({r₁+2}-1*64)+r₂→r₃
  {r₁+1}→r₂
  {r₁}→r₁
  Mask()
Return


It seems that only happens for app bcalls (an app calling to its other pages), but I've added the information to the table in the first post.

Looks pretty neat. However, I should point out that you've somehow lost all the plus signs (not just here, on git as well).

Are floats not part of the plan? I'd be slightly disappointed if that's the case. I recognize the pain of supporting them on hardware without an FPU (or even a good ALU), but any programs involving serious math or graphics really need them.