:λ(EXPR)→A
Is shorthand for:

:ʟTEMP→A
:
:Lbl TEMP
:Return EXPR
With the added convenience that you don't need to create a new label name, thus you can think of lambdas as creators of unnamed functions.  This is mainly useful when you have a high order subroutine (one that takes another subroutine as an argument) that you want to pass a simple function inline instead of having to create one somewhere far away in your code and pass the reference.

For instance here is a useful high order subroutine I thought of:

:Lbl Merge
:r₁→r₆
:L₆→A
:For(768)
: (r₆)({A},{A+L₃-L₆})→{A}+1→A
:End
:Return

This subroutine "Merge" takes only one argument: A function of 2 variables.  It then applies this function to corresponding bytes of the front and back buffers and writes the result to the front buffer.  So here are some things we can pass to it:

:Merge(λ(r₁ or r₂))    ."or" the buffers together.
:Merge(λ(r₁ xor r₂))    ."xor" the buffers together.
:Merge(λ(r₁ and r₂))    ."and" the buffers together.
:Merge(λ(not(r₁) and r₂))  .some other logic
:Merge(λ(0))         .Clear the buffer
:Merge(λ(255))       .Fill the buffer with black
:Merge(λ(r₂))         .Replace front buffer with back buffer
:Merge(λ(not(r₂)))    .Replace front buffer with the inverse of the back buffer

And so on... Notice how we were able to do all these similar functions without having to re-type a ton of code with tons of separate subroutines.  Also notice how easy this was using lambdas.  The high order function are really great for repetitive code and can be used to reduce code size with only a small overhead cost in speed.

Yes.  If you're using 'e' it will ignore the high byte of a 16-bit variable.  However, if you use 'ee' you can pick from the entire 16 bits.

By the way, I had to make a correction to the buffer xoring routine earlier.  The value returned after storing a 2 byte number to an address is the address plus one.  So only one a +1 is required to get to the next byte.

I cannot make the repeater loop (one argument for loop) work with a variable.  The reason is that the registers that are used as counters in the loop change depending on the the number of times to loop for maximum optimization.  If you don't know the value ahead of time, the parser can't know which method to use, and you end up forcing a more unoptimized one to account for this.  Also, you wouldn't be able to bring in a value into the loop, like in my example, unless I add some extra code to it.  Lastly, the format of the loop counter's register is NOT the same as the number of loops that need to be made.  I would have to include code to convert the value into the right format.  This is done at compile time for constants so conversions aren't needed at runtime.  Add all of these extra bytes together, and you get code that is just as big as a regular for loop.

I could add it anyway because it would still be slightly faster than a typical for loop, but you certainly lose any size optimization.

Brandonw has a semi-commented full disassembly on his website, but I'm not supposed to share the link.  Its not too hard to find it if you know where to look

The sin and cos routines are very fast, about the speed of doing one multiplication (because that's essentially what it does).  It uses the fact that sin(x) when x is in the range [0 to 180 degrees] has a hump that is approximately a parabola.  For the domain and range that I'm using in Axe, sin(x) is approximately: x*(128 - x)/32.  This is then just replicated with alternating sign periodically.

A look-up table is always faster, they are even faster than regular multiplication.  If you have 16 values, then done right it could be slightly faster and about the same size to use a look-up table, but you have to be good at Axe optimization to achieve this.  However, unless you are computing sin and cos more than 1000 times per second, I wouldn't even bother because it won't make a difference.

Good news everybody!  I'm almost done with the new Bitmap() command!

I've been working on it for nearly 2 weeks and it now handles all of my test cases and just needs some optimizing.  At just over 200 bytes, its definitely the largest and most complex piece of assembly I have ever written.  It uses no shadow registers or iy so its interrupt safe and compatible with any buffer.

You can draw sprites as small as 1x1 and as large as 224x192 which means you can move larger-than-buffer images across the screen for cut-scenes and stuff like that with ease.  Its not super fast though, its probably only slightly faster than drawing the 8x8 spites individually, but I'll benchmark it once I finish optimizing.

As far as optimizations, I found one byte for the all models case:

        ld de,pagedBuf+1
        ld bc,49 ;so lucky VV
push bc
        ldir
        ld hl,(iMathPtr5)
push hl
        ld de,9A00h
        ld bc,50

        ld de,pagedBuf+1
        ld bc,49 ;so lucky VV
push bc
        ldir ;bc is now zero
        ld hl,(iMathPtr5)
push hl
        ld de,9A00h
        ld c,50 ;since b is already zero...
By the way, if you need absolute addressing in the $0000 to $3FFF range, I can add a new prefix to ignore the automatic replacements if that's convenient.  I didn't think anyone would ever need to jump or call addresses there, but I guess for hacks like this that could be important.

Are you using the latest Axe version?  Some older versions referenced floats incorrectly due to overcompensating for the size field.