Actually, the grayscale tiles are only double the size, not quadruple.  In 4 level grayscale, you only need 16 bytes because there are 4 combinations you can make with the 2 layers of bits.  In 3 level, you can 3 of the combinations be colors and the last combination be a transparency or simply unused.

But I agree, this is just for generating a general idea of how the map is going to be layed out and I think the extra gray layer is an unnecessary complexity just for a preview of the map.

new release! i basically just added hex exporting.

Str4 will contain your tilemap, Str5 contains your tileset. there's nothing new except a few more self-explanatory menu's, so i won't bother reposting which keys do what. however, it's worth noting the different compressions available.
the first is where 1 byte is equivalent to one tile. the second is half-byte compression, where two tiles are fit into one byte. the next is titled "RLE" and uses my own run length encoding algorithm. the decompression algorithm can be found here. lastly, there's another RLE compression as explained by calcdude84se. the corresponding decompression algorithm for this type of RLE is found here.

and a quick checklist of features i should implement...

Tileset.
[] fix looping bug. use the max() command. add some bytes in the appvar.
[] load tiles from within the tileset to another tile to make slight variations.
[] set specific tiles as corresponding keys for the tilemap editor
[] allow editing of 16x16 tiles.

*note: allowing more than 15 tiles isn't on here because that's really easy to implement. i'm keeping it basic for now.

Tilemap.
[] placing tiles via pressing specific keys (such as 1-9, though it may be sin, cos, tan, ",", "(", and ")".)
[] tilemaps greater in size than the screen.
[] 16x16 tile placement.

edit: as for grayscale, i don't think it's necessary for getting a layout of the tilemap, so i'm going to keep it monochrome.