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.

I'll be adding it soon, I'm still looking for a good token for it...

DJ, I was at first thinking of making the revised drawing commands draw to both buffers, but I think it will be more flexible to do it separately.

Yeah, I'm definitely going to be working on the grayscale commands this version.  What that means, is that every drawing command will eventually be able to draw to either buffer.  So if you want to draw a grayscale sprite, you first draw the black part to the first buffer and then the gray part to the second buffer.  Like this:

:Pt-On(X,Y,Pic1)
:Pt-On(X,Y,Pic2)^r

However, just to save space, I am going to have the grayscale drawing and the regular drawing use the same routine, but just jump into the code with a different buffer.  This will unfortunately make the current drawing routines about 5 bytes larger even when you don't use grayscale, but it makes it much smaller when you do need it.  BUT, I might also share all the different sprite drawing routines with each other so that might actually reduce the size if you use different drawing methods in the same program.  I'm not 100% sure what is going to happen, but I will try to make them take the least amount of space possible.

I am also going to test a very limited and special case of look-ahead parsing for pointers.  I am estimating it will reduce executable size by about 2-5% in programs that use pointers frequently.

Yeah, all other areas are safe from mirage, but may not be safe for other things.  All of those specifics are documented in the commands list.

I'll put a note in the readme, that's a good idea.  But I won't block its usage because it might be useful for programs that need to change MOS variables as part of the program.

I'd say maybe 6.  There are a few places I pull some messy tricks, and not everything is templated yet, but its much better than before for sure.

LOL! The bug was exactly the same as last time!  I found another place I was checking for a bracket instead of a brace.  I have to memorize which one is which .  I'm re-uploading right now.  You'll have to re-download it again.  I'm sorry guys!

EDIT: Okay, try it now.

Well, I couldn't find a way to do it with high and low comparisons separately.  Here is what I'm using now.  I might be able to optimize it using the parity flag, but I'm avoiding absolute jumps at the moment.

p_SIntGt:
ex de,hl
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
and 1
ld l,a
p_SIntGe:
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
sbc a,a
inc a
ld l,a
p_SIntLt:
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
and 1
ld l,a
p_SIntLe:
ex de,hl
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
sbc a,a
inc a
ld l,a
BuckeyeDude, do you have a routine smaller than this?  These are 12 and 13 bytes depending on if they need the exchange.