Lucky for you, that routine has already been made. With just a little tweaking you can have it do exactly what you want.

I code like this:

clearScreen
 putS 34, 75, 11, deck.load.logo
 update
SPASM macros make this possible. No more thinking of loading the right registers .

#macro putsmall(_putsmall_down, _putsmall_right, _putsmall_size, _putsmall_address)
#ifndef _putsmall_down
call putsprite
#else
ld a, _putsmall_down
ld l, a
ld a, _putsmall_right
ld b, _putsmall_size
ld ix, _putsmall_address
call putsprite
#endif
#endmacro

#define putS putsmall(
#define update call fastcopy
#define clearScreen call clrgbuf
(The open bracket above is intended.)

I code like this:

That's... definitely an interesting way of coding. You managed to code asm like basic in a way. Of course the obvious drawback with that technique is that you have a lot less flexibility with what you can do and your actual code size will be enormous. (For instance, if you want to display something with d = x and e = y, that's an entirely different macro you'll have to code for.)

The macro doesnt really help until you have the actual routine, though.

My guess is that he's using the ION routines or something similar.

My guess is that he's using the ION routines or something similar.

Yes, I think those are pretty standard.

That's... definitely an interesting way of coding. You managed to code asm like basic in a way. Of course the obvious drawback with that technique is that you have a lot less flexibility with what you can do and your actual code size will be enormous. (For instance, if you want to display something with d = x and e = y, that's an entirely different macro you'll have to code for.)

But from my experience the advantage of being able to code a lot faster outweights that drawback. When you code a big program and it's maybe an APP that has access to 32KB, the time you need to adjust every appearance of a routine you just changed does matter compared to the few bytes you lose. In ASM it's mostly degree of abstraction and ease of use versus code size and speed. In a graphics-heavy game you would go for optimization, but really, who understands these rolled-out parallax scrolling routines I saw from JimE.

If you use a macro twice, you already get a benefit in actual size of written code, since my putsmall macro from above is just a text-replacing one.

Providing a language on top of ASM that is highly optimized for z80 is THE goal of the TI community these days. Failed BasicToAsm and CToAsm compilers, FastRPL or the successful AXE all underline this. Macros are somewhere in the middle I think. Like Timendus appoach of an AsmApi.

For beginners, something like this isn't bad:
#include ti83plus.inc
#include asmMacros.inc

.asmprog
clearScreen
echo "Hello World!"
exit _NoDoneFlag