I have a neat optimization idea you can use for "byte mode". Make the IX register point to the A-Z variable area and use indexing. Should save quite a bit of space since you won't have to load into a register before operating on the variables. The only problem is that the sprite routine and such would have to restore IX afterward.

hmm... but its the same size to do:
ld a,(var)
and
ld a,(ix+var)
So I don't think it makes a difference.  Don't forget, the byte commands need to use the "a" register, not "hl".

By the way, I don't think my original plan to use flags for the conditionals is going to work, but at least the "and" "or" and "xor" commands are half of what they were.

It does make a difference if you do
add a,(ix+var)
as opposed to something like
ld b,a
ld a,(var)
add a,b

Oh yeah.  The only problem is like you said, I have to initialize it at the beginning and then preserve it throughout the code.  Its doable, but I'm not sure how easy it will be.  I'll just wait until I get to that part and then decide if it is simple enough to do it that way.  It would be 4 bytes to initialize it and then 2 bytes to preserve it each drawing command that uses it.  And since this is a very advanced feature anyway, I'm not sure how much it would be used and I don't want to add too much baggage on the normal code size.

Also, I noticed that there is a built-in bcall for division, so that should reduce the size a lot.  Even though the bcalls are generally slower, its using an 16/8 bit routine for smaller numbers instead of the standard 16/16 bit division, so it comes out to the same speed anyway.  I can also generalize this to modulus.

calc84, I have a question.  Do you know if the _HomeUp bcall is supported on all of the 83+ OS's?  I remember it used to not be in the include file or something so I don't know if it was only added after a certain point.  Maybe I'm just crazy and imagining this.

As you can tell, I've been going though the bcall list and I've found a lot of good ones.  However, I don't ever want to compromise speed so most of them won't cut it.

Yeah, its the lowercase b.  I added the lowercase toggle to the parser options menu for this reason and I think lowercase letters will be used in the future.  There just simply aren't enough tokens available, let alone ones that make sense in most situations.  I also hate having the lowercase alpha on by default, but I don't mind toggling it while writing a program.  Is there another reason you're against it?

I would recommend getting used to it becasue one of my future plans include variable aliases, which is a way to name variables like instead of S, you can call it "Score" but all letters after the first one have to be lowercase to avoid ambiguity.

Or you can be like me and just keep it off by default and only turn it on when you need a lowercase character.

Honestly, I don't really care how big the source is (within reason) since it will generally be smaller than the executable and it can be archived during parsing.  You would never have a 10000 byte source since the compiled program would likely be around the 16kb limit anyway.

Also, I do have finals coming up soon.  Don't expect much over the next month.  I'll still try to update every week, but there'll probably just be 2 or 3 new things in each version from now on until school ends.  Once summer hits, there will be rapid progress again and 1.0.0 will be finished before the end of summer.

I'm having a little grayscale crisis.

First of all, it needs to have constant pause times or else it looks really crappy so I can't use the screen delay timer.  If I make the pauses short enough, its speedy fast for 6MHz mode but fails on 15MHz mode.  If its too long, it looks great on 15MHz mode, but really lags in 6MHz mode.  That means, it has to pause a different amount of time depending on if its in 6MHz mode or 15MHz mode.  I can add a check to pause a different amount of time for each mode.  The check is too much code to look good on 6MHz mode unless I fix a few things.  If I use some undocumented instructions, I can speed it up fast enough to look good, but then I lose compatibility with the NSpire.  I could also skip one of the checks to speed it up, but then it still pauses the longer 15MHz pause time when using a regular 83+ thus losing compatibility with the original 83+.

So it seems like a lose-lose-lose situation right now.  I can't seem to find a way to make the routine fast enough yet still compatible with every model at every speed.  I might have to either make separate routines for each speed or just settle with the ugly "checkered" grayscale.  I don't know what to do.

And don't say I'm being too picky about quality.  If perfect gray is not reproducible, it defeats the purpose of the command since then you might as well just flash the images on and off since that flickering would be less annoying than the checkered flickering.

Use HALT for delays?