Oh, Disp ►Tok and Text ►Tok call for different arguments. That's a little confusing. But I see how printing the token pointed to would generally be more useful. Maybe Disp ►Tok should be changed to accept a pointer to a token as well for consistency? I think it would only need to be two bytes bigger; ld e,(hl) \ inc hl \ ld d,(hl) instead of ex de,hl. And this would actually be saving two bytes for printing tokens from a pointer.

Some things I'm particularly curious about:
- The token numbers are difficult for developers to type in manually, any ideas of how I could generate a list of equates?

After searching around and not having found any existing list of token hook equates, I figured I should compile one myself, and I did. Feel free to include it in the next release of Axe.

http://www.ticalc.org/archives/files/fileinfo/445/44517.html

Not sure if this is a bug report or a feature request, but it appears that Axe will not "nest" peephole optimizations. I put "nest" in quotation marks because that's not a very accurate description of what I mean. This code example should hopefully better illustrate what I'm trying to say:

Source		Compiled
If <96-1 .Blah End		ld  de,-96 add hl,de sbc hl,hl ld  a,h or  l jp  z,End

As you can see, the inc hl \ dec hl optimization was applied, but the sbc hl,hl \ ld a,h \ or l optimization was not applied.

Don't use Bitmap() unless you absolutely need it, which you don't for just displaying full-screen pictures. The Bitmap() routine adds over 200 bytes to your program.

.Draw a byte of top border (88-95,1)
.Draw a byte of left border (0-7,2)
ᴇC0FF→{L₆+23}ʳ

.Copy byte (88-95,1) of top border to draw rest of top border (0-87,1) and (0-95,0)
Copy(L₆+23,-1,23)ʳ

.Copy byte (0-7,0) of top border to draw bottom border (0-95,62) and (0-95,63)
Copy(,L₆+744,24)

.Draw byte of right border (94-95,2)
.Draw byte of middle (80-93,2)
ᴇ0300→{L₆+34}ʳ

.Copy byte (80-87,2) of middle to rest of third row middle (8-79,2)
Copy(L₆+34,-1,9)ʳ

.Copy third row (0-95,2) to fourth through sixty-second rows (0-95,3-61)
Copy(-1,+12,59*12)

You started out pretty good with 68,006 cycles

Rect(0,0,96,64)
RectI(1,1,94,62)

Then you went way in the wrong direction with 2,614,503 cycles

Rect(0,0,96,64)
For(J,1,94)
For(K,1,62)
Pxl-Off(J,K)
End
End

And here's my Runer-optimized™ speed/size blend, coming in at 16,303 cycles; that's faster than ClrDraw!

ᴇ80FF→{L₆+11}ʳ
Copy(L₆+11,-1,11)ʳ
Copy(,L₆+756,12)
ᴇ0100→{L₆+22}ʳ
Copy(L₆+22,-1,9)ʳ
Copy(-1,+12,61*12)

I just realized that the token hook has a very minor bug in it. I was relying on the indicator $00 to signal that there are no more tokens to be compared, but I seemed to forget that a couple of tokens actually have $00 as the low byte of the compare value. I suggest fixing this by making $FF signal the end of token comparisons, as this is an odd number and is thus not a valid low byte for the compare value. Fixing the code itself for this change is actually quite easy, and will only cost 1 byte and 4 cycles. Add an inc e before the comparison loop and change or a at the end of the comparison loop to inc a.

EDIT: Let me think this through a bit, this makes my Axiom token replacement cache generator less optimized...