Its actually 153 now.  Its because they fit conveniently onto one of the buffers since each entry is 5 bytes.  768/5 = 153.  I'm already using compression so it really isn't possible to compress anymore.  Of the 5 bytes, 2 are a pointer, and the last 3 hold 4 6-bit entries for the name and type of symbol.

I'm surprised you're getting this error, that's A LOT of symbols.  You can reduce the count by relative referencing.  Like instead of:
[1234]->Str1
[5678]->Str2
[9ABC]->Str3

Disp Str1,Str2,Str3

You can do:
[1234]->Str1
[5678]
[9ABC]

Disp Str1,Str1+2,Str1+4

Also, getting rid of Lbl's that you never actually use.

Yeah, maybe I'll upload a patched version since it might still be another week before the stable release.  Not much new, mostly just working on axioms.  They are much much more sophisticated now.  When it reads your assembly command, it knows each z80 instruction opcode in order to advance through it and make auto-replacements for absolute jumps, calls, and even loads under the right circumstances.

Ok, I've fixed all the problems mentioned so far.

Scanning the keys yourself is actually much faster than GetCSC.  But obviously scanning all the keys is always going to be slower than scanning a single key.

:Lbl KEY
:For(A,1,56)
:ReturnIf getkey(A)
:End
:Return 0
Calling this subroutine will give A the value of the current key being pressed or 0 if nothing is pressed.

Oh, and the actual slowdown for variable key detection is so small compared to Dispgraph or sprite drawing that I would consider it negligible.  It isn't much bigger either since it only needs to add the subroutine to the program once.

Hmm... I still have a strange problem.  The .db and .dw directives don't seem to be working.  It compiles with no errors, but I go to open the .lst file and even though the program counter is advancing correctly for the data, nothing is being outputted to the binary.  Here is an example:

   93 00:000A -  -  -  - 
   94 00:000A -  -  -  -
   95 00:000A -  -  -  -  .dw $6DBB
   96 00:000C -  -  -  - 
   97 00:000C -  -  -  -
   98 00:000C F3 -  -  -  di
   99 00:000D -  -  -  - 
  100 00:000D -  -  -  -  Loop:
  101 00:000D 3E -  -  -      ld a,1
  102 00:000F D3 -  -  -      out ($20),a
  103 00:0011 FD 21 -  -      ld iy,plotsScreen+384
  104 00:0015 21 -  -  -      ld hl,Length

The data directives aren't being added to the binary like the instructions are, I even checked the binary to make sure it wasn't just an output error with the list file, but they're not there either.

Ok, I'm trying out SPASM, but every time I try to compile, the entire "ti83plus.inc" file is highlighted in red but with no error message and the code and data sizes say 0.  What do I need to do to make my TASM z80 file SPASM compatible?

  How do you do this? You're a madman!

So I've never really used or knew what the rrd and rld instructions did.  I though thought they were some of those obscure instructions like daa, which they are, but I guess there are situations where you can use them, like with daa in the hex routine.  Awesome job there!  I can't believe I missed the push pop thing in the sprite rotation ones, that was embarrassing...  I really do like the getcalc ones, but it uses an inline self-reference.  I think because there's only one, I can easily replace it, but I'll have to make sure.   The inversion one is excellent as well.  I could have sworn I tried that same method before but couldn't get it the same size.

However, these are the concerns I have:  First, the sprite rotation commands, why did you move the ret to the middle of the routine?  It looks like that's just going to add more cycles since a conditional jr takes the same amount of cycles as a regular jr anyway.  Next, is it really a safe assumption that all ROM pages are between $7F and $FF for all current models and potentially future models?  And lastly, are you sure trying to modifying rom (unsuccessfully) has no potential side effects to things like flags and registers?