Alright, so I've been working on what I would consider to be a standard RPG game. I'm using Zelda Links Awakening graphics, cause I'm not the most creative! lol. I'm more into learning how to structure a game and programming techniques. It's been fun so far! I've been using Axe as the programming language.
I'm gonna be fairly open about how I program different things, and I'll be asking for a lot of help. I'll try to keep screenshots on it, cause people like to see what's going on. Who knows, maybe I'll get it to a point that I can consider it finished!

I got some help from Sorunome on how to draw a tilemap to the back buffer and copy it to the front buffer...he's a brilliant guy. When I move the map, i shift the back buffer using the horizontal and vertical commands.  I've been able to get a masked sprite drawn on the front buffer. I do this by copying the back buffer to the front, and then masking the sprites onto the front buffer.  That's the first screenshot.

The Link sprite has his data arranged as Data("X coordinate","Y Coordinate","Direction","State")

The Directional multiplier in the third slot helps make Link's sprite face the correct direction. Basically when I press the directional keypad, it stores the numbers 1 - 4 into the third slot. When I call for Link to be drawn, the sprite pointer is offset to the correct directional sprite...if that makes sense. You can see that in screenshot 2...and don't worry about the random background map

In screenshot 3 I was able to get Link to alternate between states: standing and stepping. It's just another multiplier, just like the direction slot. I have a little routine that helps alternate between the two when moving, and resets to stand when Link's not moving.

Screenshot 4 is my little test arena for collision. I rearranged the tilemap so the fences are in different configurations for Link to approach. I feel like the collision is super basic. Depending on which direction Link goes, I check the type of tile Link would move into. If the tile is less than a certain number, its a walking tile, and Link can walk freely. If it is above a certain number, it wont let Link pass forward. I hope this explanation isn't too vague...

So, the next thing's I have in mind are;
animated tiles (like the moving flowers tile) - I'll need help on brainstorming
Link swinging sword animation
Health bar

...just one step at a time, i guess. What do ya'll think?

Looking good so far! 

I've been working on this the last little bit...sorry, no screenshots quite yet. But some quick questions.

I'm wanting to make my drawing routine for Link more general for all 16x16 bit masked objects, like enemies, npc's, etc. 
It'd be called: DrawChar(GDB0Character,Pic0Pointer). However, it doesnt seem to like me sending pointers to the routine...

DrawChar would look like this:

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

And Mask would look like this:

Lbl Mask
  Pt-Mask(r₁,r₂,r₃)ʳ
  Ptq-Mask(r₁+8,r₂,r₃+16)ʳ
  Pt-Mask(r₁+8,r₂+8,r₃+32)ʳ
  Pt-Mask(r₁,r₂+8,r₃+48)ʳ
Return

I have a feeling that it's confusing the r1, r2, etc between the two routines. Or, maybe I'm not referencing the pointers right, idk. Any thoughts?

Also, any idea on how to do animated tiles? I'm thinking of doing an interrupt routine that first checks for visible animated tiles on screen. If if finds one, it draws over it with the appropriate tile...idk..I've never done interrupts before..

Could you please provide an example usage of DrawChar, including the data the pointers you pass it point to?

As to animated tiles, there is no need for an interrupt!
The basic idea is that you re-draw the entire tilemap every single frame (that would make the code you wrote for scrolling obsolete (believe me, the calc is powerful enough to easily handle that)) and have a frame counter, and then change for the animated tiles every like 8 frames the pointer of where the sprite data lies, resulting it a different frame being drawn.

This is currently looking correct to me, could you please give us screenshot examples of your sprite routines? (And, if possible, a thing of how the sprite should look like)

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


To not requiring every tile to be a 4-frame animation you could maybe make that only tiles above a certain ID are animated, below they are static

You can have it like this then:
(for example)
0-7 : walkable, static
8-10 : walkable, animated
11-42 : wall, static
43-99 : wall, animated