That could be made more generic
Perhaps something like EXPR!#, where EXPR is any expression, ! is the factorial symbol, and # is a constant or variable between 0 and 3 indicating what nibble.

You could always use ^ and /

But it might be a good idea to make things clearer. Maybe [PTR].[NUM], since periods aren't really used right now? It would make sense, anyway, since it kinda means a part of the number.

And even if it were a variable, / and ^ are pretty easy to use. For the high nibble, it's [EXP]^16, and for the low one, it's [EXP]/16. I think the original idea, though, was to make one that would be easier for two-byte numbers, since to get the low nibble of the high byte of A, it would be A^256/16 now. The only reason I can see of adding such a command would be to make things easier to figure out

What about an alternative half byte referencing command?  I imagine that's what it would generally be used for anyway, so just take out the middle man.

Say I call this command nib{} which uses angle brackets like int{} since it's a referencing command.

[C0FFEE123456]->Str1
nib{Str1*2}   .returns C (12 in decimal)
nib{Str1*2+1} .returns 0
nib{Str1*2+2} .returns F (15 in decimal)
nib{Str1*2+N} .returns the Nth nibble in memory

The only strange thing you might notice about this is that the pointer has to be multiplied by 2.  That's because wherever it points to is in bytes so if the pointer is at the 100th byte, it is actually at the 200th nibble.  That's done during compile time in this case so its not going to increase program size or anything.  But now there are 131,072 (2^17) possible addresses, and so that means you can only use this command for half of the memory.  Ram is in $8000-$FFFF which is exactly the range needed.  However that would suck for apps because they need the other half from $0000-$7FFF.  To remedy this, there would be 2 commands, one for programs/ram/archive and one for apps.  So nib{} and nib{}^r would work.

Would this be suitable?

EDIT: Oh, there could also be a store-to version for ram, like 5->nib{Str1*2+2} for instance.

Yep, that'd be great. What token will this replace?

What about iPart(? It's in the math menu near float{ and whatnot.

@Runner, yes, I fixed that now.  I decided to keep the grayscale routine unchanged since that is most critical and just change the interrupt routine to push and pop the af register pair instead of saving it to a shadow register.  Its exactly the same size as before now and unnoticeably slower.

Just an fyi to all you asm programmers, I was able to save one byte from each call to Copy(), Fill() and Exch() using an optimization I hadn't considered before.
this:
  ld   b,h
  ld   c,l
  pop  hl

can become:
  ex   (sp),hl
  pop  bc

Its slightly slower, but its one byte less.

Oh, and I finally took care of another request: dereferencing.  The routine actually already existed so I only had to add about 6 lines of code.  The new syntax for that is the degree sign followed by the variable and it will return the variable's address.  For those familiar with C, its identical to the &.

A        Returns the variable A
{A}^r     Returns what A points to
^oA       Returns the address of A
{^oA}^r    Identical to the first example

So I don't want to see anymore of that {L1-52} nonsense and no one has any excuse for being mad if I change where the variables are in the future.  This works with all variable types including files and the subroutine variables.  Also, don't forget that any dereferenced variable is a constant address just like the L1-L6 addresses so any math you do to it is done during compile time for extra optimization.

I am perfectly happy with the dereferencing as long as they stay in the same order and awesome on the optimization!

Addresses! That'll be useful. No more subtracting from L₁