Maybe try to assimilate a key to a power of two (since one key has two states (pressed or not), binary seems the way to go). The problem I see with that is that the player will never press up and down at the same time, so there is a bit of waste.

Anyway, I give you an example with orders I chose, but you are free to choose your orders after all.
1-down
2-left
4-right
8-up
So if you press down and left, you have 1+2=3.

Now draw your eight sprites and put them in a specific order (that you can choose too), for example this (random) one :
    []->°Sprites
    [ no key pressed ]
    [ up ]
    [ up-left ]
    [ up-right ]
    [ left ]
    [ right ]
    [ down ]
    [ down-left ]
    [ down-right ]

Now we need to bind the keypresses to the sprites. Remember that there are keypresses that "never" happen, like up+down, so you might want to choose a specific sprite for them or say that up+down gives down for example.
So you need to make this kind of data : You get 0 when presseing nothing, so the first sprite is the sprite "no key pressed", which is the 0th (I started counting at zero of course). You get one when you only press down (according to what I said). So the second sprite is the sprite facing down, which is the 6th one in my list. You get two when pressing left, so the next sprite is the sprite facing left, which is the 4th one. You get three with down+left, so the next sprite is 7th one. Etc. So your data will look like this :
     Data(0,6,4,7,...)->°Corr
Remember that you get nine when pressing up+down for example, so you don't necessarily have a sprite for that case but you still need to assign one. And I was too lazy to do the 16 cases here, but you actually have 16 bytes to put in this data.

Now, how do we actually get one when pressing down, two when pressing left, etc ? with that calculation :
     getKey(4)*2+getKey(3)*2+getKey(2)*2+getKey(1)->D

Now you guess what you just have to do to get the right pointer :
     {D+°Corr}*8+°Sprites

Note, all of that is untested, I am under Linux right now and don't have Wabbitemu on it.

edit messed up with the counting, please read again if you felt like it meant nothing.

edit 2 I made a complete program. Here is the source, in attachement and in spoiler.

Optimizers would tell me that D is useless. Yes it is, but it improves readability, thing that I don't care about in my progs but that I care about when explaining.

I'd suggest to just go with 4 sprites, and make the sprite point in the direction of the key you held down last, or just make it default to values (for example point left when left is pressed, even when the up or down key is held at the same time). It might not look as good than with full 8-directional sprites, but for a calc game, it is fine. Many gbc and gba games even did it like this.

Thats a pretty good idea of refrencing them with another set of data, I'll have to try that later.
I was wondering also why you use ° when you store the data, because ° returns the memory location of the variable apparently but I don't see why you would want to store it to that or something. Also Is a while loop with a conditional end more efficient than a repeat or are you just doing that so the code is executed before it checks if it exited.

- ° returns the pointer to data but you can also use it for custom pointers and even constants, which is pretty awesome.
- While and Repeat in Axe both check the condition first. The difference is essentially the same as If vs !If. While continues if the condition is non-zero whereas Repeat continues if it's zero. Now While 1/Repeat 0 are automatically optimized to a mere jump in the output ASM code. Checking the condition first requires to go back to the beginning of the loop and then appropriately skipping it. Using While 1/Repeat 0 and a conditional End is both faster and smaller. See it as a Do ... While in C.