Thanks for writing that out, jacobly. z80 arithmetic has always been a bit confusing for me (and i'm not very good at math to boot).

Like others have said, I use cpl for a quicker/smaller xor $FF, for example in my tilemapper to get the mask  when  rotating the screen:
updateRotation:
    ld a,(xOff)         ;what is the xOffset?
    and 7               ;we're only interested in the lower three bits (essentially xOff % 8)
    ld hl,gbufMask
    ld e,a
    ld d,0
    add hl,de           ;pointer to the rotation mask
    ld a,(hl)
    ld hl,maskLeft
    ld (hl),a
    ld hl,maskRight
    cpl                 ;xor $FF
    ld (hl),a
;...
    ret
gbufMask:
.db %11111111   ;0 display all of the first byte, none of the second
.db %11111110   ;1 after rotating left once, we only want the 7 leftern most bits of byte 1, and rightmost bit of byte 2
.db %11111100   ;2
.db %11111000   ;3
.db %11110000   ;4
.db %11100000   ;5
.db %11000000   ;6
.db %10000000   ;7...which, btw, is based off an idea calc84maniac mentioned on IRC a few years ago of doing the rotation in the fastcopy routine, though i remember you saying that your main fastcopy loop was much faster than mine

ldir increments both hl AND de, so you'd need to reset de (ld de,plotsscreen or push de then pop de).

EDIT: ldir also decrements bc, so you'll need to reset bc as well.

And to answer your other question, an asm program is first compiled to its hex statements. Later it is compressed into it's "one-byte" values (like the AsmComp( oncalc command). But if you want to program on a computer, you can, and just copy the hex values. But it'd be much easier (and safer) to send it. There are also programs you can send to your calc to program in actual assembly, if ever get the chance to borrow a USB cable.

Also, check this part here:
Game:
BCALL ClrLCDFull
LD A,Xpos ; This gets my variable Xpos.
LD (penRow),A ; This makes it in the penRow
LD A,Ypos
LD (penCol),ATwo things, first: penRow is the row, aka the y position. penCol is the X position. Next, you forgot the parenthesis again. It works initially because you have them defined as equates, so it essentially converts Xpos into the number equated as Xpos. Try making the change Hot_dog proposed (changing the equates into .db statements) and adding in the parenthesis.

This has so far been very helpful, thanks! I wonder what my first program should be... maybe a bouncing thing or pong? Thank you much for your help so far!

What? No Hello World?! And what about the little dot that moves around the screen? Also, the 89's LCD is like the 86's, right? In that you don't have to send data to a port to update, just an address in memory? You could make a grayscale pong

Btw, what do people use to emulate the 89? TiEmu?

EDIT: Oh, and i've also learned quite a bit, so thanks for bringing this discussion up. There's a few boards at yAronet which have (well, had ) a lot of discussion on 68k asm programming, it might be fun to look through their old programming help archives. A lot of really knowledgeable people post(ed) there, you'll probably recognize a few of their names from games you've played.

EDIT2: If you don't have it already, you might want to check out TIGCC. I've read that all the ROM CALLS are documented there.

Wow! Just today i was asking about resources for 68k assembly programming. I think you might be interested in this:
http://www.cs.tcu.edu/people/professors/nute/systems/68K_Instr.pdf
movem means MOVEMultiple (registers). I think the .l and .w mean longword and word respectively.
So maybe "movem.l d4/a5,-(a7)" would load the d4 register at (a7), decrement, then load a5 register at (a7-4
The next part:
move.l         $C8,a5
move.l         HeapAllocPtr*4(a5),a0
jsr              (a0)
...is essentially a 68k B_CALL (ROM_CALL). I suppose $C8 is the address of the rom call table, and the what the second command does is store the longword (i guess each romcall pointer takes up 4 bytes, hence the *4), using the value in a5 as an offset, then stores it into a0. Jsr (Jump to SubRoutine) jumps to the address held in a0.

pea = push effective address. So pea.l pushes the address that follows onto the stack.

tst: Yep, this is TeST. I think it basically is like an "or a" in z80, or cp 0, it tests if the register = 0.

beq.s nomem: bra is branch (jr), bXX are the conditions. BEQ is Branch on EQual, aka jr z. The .s means short, i think the default is 16 bits, not 8.

"move.l        #3840,(a7) Does this push an immediate value to the stack?"
Yep.

lea.l 12(a7),a7: Load Effective Address. a7+12 to a7. The (a7) is an offset, though i'm not sure if it uses the value of the register or the value of the address pointed to by the register. It looks like this might clear up the stack?

clr = clear, set register to 0.

A lot of the information i've found (TI specific, that is) is in French, but none of it too comprehensive and don't really explain things in much detail. A lot of old tutorials appear to have disappeared due to offline sites. I'd be interested in trying to learn 68k asm together, if you're interested in changing thoughts/ideas/etc. Anyway, good luck!

EDIT: So yea, the $ROM_CALL(a5) takes the address pointed to by a5 as the offset (so the address that $C8 points to). AaronTheGreat recommended technoplaza to me, which is the first tutorial i've found which really explains things well for someone who is just starting and has no idea about the entirely different syntax from the z80. It's not very long, but maybe worthwhile checking out.

Another possibility would be to create a smaller Axe shell (or something xLib-style, containing the necessary routines) for people who don't program with Axe or even talk to Kerm about including support for Axe routines in DoorsCS (are there any other shells currently still in development? Ion comes with the source...).