Haha but this isn't a PC game, and (practically) every Gameboy game uses it. Also, the majority of games are written for shells, and if you have an 83+ games written for shells will be smaller since they can reuse (probably Ion's) sprite code. It's also not much code to implement yourself. And using SMC here would be smaller than using an AppVar, as the AppVar takes up 9 bytes in RAM (for the VAT entry) and 3 bytes in archive (plus all the code to handle the AppVar). I guess it's not really a big deal, i just prefer having everything in one program when it's possible/convenient.

@JWinslow23: I just loaded this up on my calc, it looks and works great, i was proud of myself for getting to 512

Wow this looks great! I also have to admit that i'm excited you've made the switch to assembly

Oops, i was looking at the decimal version  Thanks for catching that (and that it actually saves two bytes), though i'm pretty sure it wouldn't have been an issue for Xeda

I modified the sources for it to compile under (64-bit) Linux, see if this works better for you:
http://www.mirari.fr/wo0H

I made a patch and sent it to Buckeye Dude, they said they'd put it in. There are a couple parts that tried to use Windows functions that needed to be commented out/#if'd around and you need to add some includes:

You'll need to add #include <functional> and #include <unordered_map> at the top (under #include "list.h"). [In hash.h]
You'll also need to add the flag:
-std=c++11
..to g++ in the makefile:
CXXFLAGS+= -I. -DUSE_REUSABLES -DUSE_GMP -DUNIXVER -DUSE_BUILTIN_FCREATE -std=c++11

Impressive as always, James! You keep putting the rest of us to shame, but i'm not complaining!

So [Alpha] is essentially a "strafe" button?

That sounds pretty much like what we were talking about before, only the other way didn't require a special stack as it's processed on the fly. That sounds like a fine method to me, personally i would start working on converting something like "3+2(4-1)" into "3 + 2*4 + 2*-1". Once you get to that point, adding X shouldn't be too difficult.

I'm not sure, if that's how you're planning on doing it, you might want to reconsider your algorithm. I'm not sure what the best way to do that might be, maybe working one "group" at a time? For example "3+x(2x-3(1+x))-3x(x^2+2)+2x", you would first work "x(2x-3(1+x))" then "3x(x^2+2)" and finally you'd put it all together and try to simplify it.

That seems a good deal more complicated, i'm not really sure how i'd go about it.

Support for other variables is just  find and replace. You would probably do that when you parse the numbers to convert them into whatever format you plan on using, just replace the variable with the value it holds.

Step 2 and 4 will use  the same code to parse, since there won't be any parentheses to evaluate in step 2 (you've found the innermost parenthesis), so you should just need one last call to the parse routine (that handles the multiplication, division, etc.). I think step 3 is unnecessary.

EDIT: Also, there are more possible errors than just the parentheses, for example you need to make sure there is a number/expression before and after every operator (2+3* is invalid, as is +2+3*4) and ideally you'd have something in between the parentheses (not "2+3*( )" ), but i would set that aside for now. I wrote a little parsing routine last night just to see how difficult this project would be, currently it just converts the numbers into a 2-byte number (that fits inside hl/de/bc/etc.) and finds the first parenthesis.