I tried this:
.ATEST
ClrHome
For(A,0,5)
    A->{L1+A}/16
    A+5->{L1+A}^16
    Disp {L1+A}/16->Dec,{L1+A}^16->Dec,i       .imaginary i for newline
End

Repeat getKey
End

and expected this:

   0    5
    1    6
    2    7
    3    8
    4    9
    5   10

but got this:

   0    5
    0    6
    0    7
    0    8
    0    9
    0   10

And I don't like that result.
Help?

Also, what are bitmaps and how do I use them (and the bitmap command(s))?

Edit: added a '->Dec'

Thanks, but it still doesn't work...

I'll have to look at that code in a little bit, but here's some knowledge on bitmaps.

You have to define the first two bytes of the sprite as the size.

.BITMAP
[181000000070009803641E6430127FD254B1192919251035F1DE5E242528DCD6B7F54C5B3ECE1DFC23664E32D42BF81F0000→Pic1
Bitmap(X,Y,Pic1)
The first two bytes are hexadecimal for the height and the width of what you want to display in that order.
The width that you define does not have to be a multiple of 8, but you do have to pad all the rows in your bitmap to the nearest byte.

Be aware that if you use bitmaps in an App, you'll have to copy the bitmap you want to display to saferam or an appvar, then use a pointer to that location to display it.
.Bitmap
[181000000070009803641E6430127FD254B1192919251035F1DE5E242528DCD6B7F54C5B3ECE1DFC23664E32D42BF81F0000→Pic1
"appvBITMAP→Str1
GetCalc(Str1,50)→P
Bitmap(X,Y,P)

The examples I posted will display a 16x24 sprite at X,Y.

The problem exists in this code:

   A->{L1+A}/16
    A+5->{L1+A}^16
Although {L₁+A}/16 and {L₁+A}^16 would correctly retrieve the high and low nibbles of a byte if they were on the left side of a value→pointer statement, there is currently no built-in support for storing to nibbles. As of now, you can only store one or two whole bytes at a time. As soon as the parser reads the closing brace around the pointer and sees that the next character is not the ^r modifier, it would encode this as storing the value to the full byte at L₁+A. The calculation would then carry on to /16 or ^16, but as there are no more storing statements after this, these would just be do-nothing calculations. And because the A+5 line operates second, it overwrites any value the previous line wrote to L₁+A. A+5 is stored to the byte L₁+A, resulting in the first nibble always being 0 because A+5/16 is (for the current domain of A) always 0.

To store two nibbles to a byte at the same time, you could do the following:
A*16+A+5→{L₁+A}
Or to store two nibbles to a byte separately, you could do this:
.Store high nibble
{L₁+A}^16+(A*16)→{L₁+A}
.Store low nibble
{L₁+A}/16+A+5→{L₁+A}

Or, wait for Axe 0.4.5, which will have built-in nibble support.

Or, wait for Axe 0.4.5, which will have built-in nibble support.

I wonder if that'll save us some effort on half-byte tilemapping tile calling? It's not that hard to display a tilemap but I had serious issues making a map editor that fits my needs.