Your code looks decent, just changing the tilemapper from pixel to whole-byte would speed everything up quite nicely. Basically the idea is that instead of using a pic and using pxl-test, you use a series of bytes to define your data.

So if your tilemap was a big box say, 8x8 in size the data might look like this:
0101010101010101
0100000000000001
0100000000000001
0100000000000001
0100000000000001
0100000000000001
0100000000000001
0101010101010101where 1 is a wall and 0 is empty space. Then to draw it, you use something similar to what you had, only simplified for full byte tiles (and unoptimized for readability)
for(a,0,11)
for(b,0,7)
pt-on(a*8+s,v*8,{b+y*w+x+b+gdb1}*8+Pic0
end
end
where gdb1 points to your tilemap data, pic0 are your tiles, and w is your tilemap width. What you're doing, in essence, is modeling a 2d matrix.

Thanks guys! I've been hard at work on this project; I'm surprised it's come so far so quickly

Small updates for now, nothing huge yet. I'm mainly thinking more about content and spriting. Optimizations have been made, and work on the NPC engine has started up. I've improved the scripting language a fair bit since it's last incarnation-- choosing it to model its control structure on asm rather than anything else. That's right guys, my npc scripting language's only command is an abstracted jpnz that's been built on memory locations instead of registers, lol. Anyway I've got most of the commands implemented, and a few left planned. For now:

Implemented:
-Print active player name
-Check if event flag n set, then jpnz. (arguments flag #, address to jump to)
-Set flag n (arguments flag #)
-Reset flag n (arguments flag #)
-Check if item held, then jpnz (args item ID, addr to jump)
-New line
-Pause conversation
-Jump to address

Planned
-Shop
-Get Item
-Warp character
-Initiate battle

Optimizing constant address calls?
Anyway, 5->^oVAR : (^oVAR)() compiles to ld hl, 5
push hl
call $9D9D
when it could just compile to
call $0005

Right now the only way to call an address that's not a label is using asm(CDXXXX), and that way makes assigning r1-r6 arguments extremely annoying (manual store)

Yeah, those would also work. They're just less direct, and I feel like it'd be useful for all kinds of interfacing with asm code, although I guess if you're adding the ability to inline constants in Asm() then it's not really needed.

Feature request: ouput symbol table? It's a little obscure, but I don't think it'd be too hard to implement; right? (One use could be for calling app routines from an external program.) As an option, the compiler could (after compilation) output as axe source named constants/variables all the label address offsets and static pointer locations. I know there's not a lot of room left in the app but...

Thanks

Mini-update; just finished converting the code to be compiled as an app took way longer than I thought it would...lol

Now on to finish up the battle engine and work on content some more!

Axe already has some pretty good routines to work with archive, I don't think you'll need custom asm for that. Also axioms don't make you need another shell to run.