Yeah, I've been putting them in subroutines. But it just seemed like the kind of optimization that would be quite helpful to not have to manually do for every program.

I didn't knew DispGraph was this large o.o

But again I only really used it 3 times per program at most

Well, I don't want to do too many of those.  Even though it reduces the size, it also slows down the program a little each time it has to call a subroutine.  Normally, you don't notice this, but sometimes when you're doing very heavy math (like checking if any objects on one list collide with objects on another list) you can actually notice it.

That's an interesting optimization though.  It would be very difficult to figure out what to group though.  Like if you did _*2+1/8+L1 a bunch of times for instance, its convenient to group that whole operation into a single subroutine.  But unlike a computer compiler, Axe doesn't have large memory or fast speed, unless I use the extra ram pages maybe but it would still be super slow for larger programs, so its really not practical to keep track of all that.  Its going to have to be up to the programmer to do a majority of these optimizations.  There's always the computer compiler idea though...

Yeah, at the moment I'm making as many optimizations by putting mathematical or logical expressions used more than once (as long as it's size efficient to do so) into subroutines, because my program is at about 7.5k and I don't mind sacrificing some speed for space (it's a sprite editor after all, no need for speed)

Not sure if that was suggested before (I might even have suggested them myself ):

Horizontal +^r
Horizontal -^r
Vertical +^r
Vertical -^r
ANOVA(666)^r
Line(X1,Y1,X2,Y2)^r

I couldn,t find those in the command list. It would let you scroll the back buffer, ANOVA(666)^r would delete the entire calc OS certificate+OS the next time you recall the back buffer and you could display lines on the back buffer. White lines would also be nice, but I'M not sure if it's necessary. I simply do DrawInv, display my line then DrawInv again.

yeah maybe. I was just saying in case he never adds them that they could be done that way too.

Thanks!  So I'd do {_E8447}->A to store the current contrast into A, right?

Note that you cannot actually update the screen itself with the new contrast value, though. You need a bit of ASM code for that.