Base 10 would be 0123456789
Base 16 would be 0123456789ABCDEF
Base 37 would be 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ and Theta.
Else maybe an higher base, where after Theta, we use Sin(, Cos(, Tan(, Ln(, log(, etc. (as long as those tokens are 1 bytes)

Also I think there was a misunderstood. People including me thought you meant an ASM hex string stored into compressed appvar (where each tile takes 1 bytes), not BASIC strings where one tile is made of two hex chars (due to not being squished with the AsmPrgm command) and thus, takes twice as much space. And I myself have never ever agreed with entirely string data, since I thought it was too massive (twice larger than ASM hex). Since you seemed relunctant about letting us dynamically change tiles such as obstacles in Flash ROM data, I thought it meant the map data would be stored in ASM and that for obstacles we would simply use a second copy of the map or hard-code some stuff.

Anyway, since it seems like you are going with the old school way of storing maps, I think we should stick to it now (Basic strings, that is). But still, if one map can have up to 256 different tiles, then each tile ends up taking two bytes, because they are made of two chars (eg 4B). Hence why I suggested Base 37 (I doubt someone would need more than 37 tiles in a single map). Not sure how hard it would make it to convert maps, though, plus it would not let the user use the entire sprite sheet at once .

Anyway you haven't been very clear in general so far during explaining of xLIB features and how they work (no offense), so it might be best to wait until it's out then write a good readme explaining the syntax and what each arguments are, like the old xLIB readme did. Else there will just be too many misunderstoods and confusion (or maybe false hopes).

Unsquish/squish would definitively be a great addition.

Yeah pretty much, plus i hope i have coded things a little better this time around anyway .

I have also added a 'replaceTile' function which will search a tilemap string and replace the specified tileID with another. Can be useful for easy 2-frame tile animations.

At this stage its the whole map. You can still modify individual tiles with 'setTile' if you need to replace only specific tiles i guess.

I making a small proof of concept demo to try and demonstrate the features thus far ... (and to see if xLIB on the 84C is even feasible for games!).

I hope it's feasible for games lol. That said, having seen how fast the Zelda screens are, I bet it will. For an RPG, you need at least 2 FPS during character movement in a map engine, including collision detection and stuff

Here is a small tilemap test. There is 8-directional movement (arrows+combos) and tile collision checking, the sprite is moving 8-pixels at a time.

The animated tiles are 2 frames and take advantage of the way xLIB uses GRAM, meaning that they dont require any extra processing once drawn.

Im working on making some more routines to speed things up if possible.

I apologize for the crappiness of the video and the fact that i did it on my phone just before leaving for work.

Here are some screenshots of the map:

Wow I didn't realize that animated tiles would be possible with the swapping between buffers, since I thought that the character would keep flickering or something when walking around. I assume that makes any HUD slower to display, right?

Anyway this really looks great and fast. Btw how does the code look like? I am curious how large it is with this version of xLIB, especially collision detection.

Also nice sprites