256 tiles is 2048 bytes.. so no. i think i'm capping it at about 60-65 since L2 will probably store them, and L2 is 531 bytes. also, i think 60 tiles is pretty crazy for one map. the tilesets are unique to each map, though you will be able to load other tilesets into different maps.

should i just make an input loop where you can specify height and width, but if the product of the two numbers exceeds 768

I think this would work.  And if it was over, then just cancel the last change.

they'll have to use CalcGS then. plus, i don't think editing a tilemap greater than 768 bytes on-calc is the easiest way.

I tried openign such data once, when I made a map editor that I couldn't figure out how to get editing to work, I had no issues looking through the data except that i had to archive other things before running my prog

I really had serious troubles before reading data from appvars. Idk why but it seems to be a major hassle

mhmm Idk if it was intended to use or not in appvars. Could you maybe post this in bug reports?

I can't wait for beta!

quigibo, aren't  
Copy(L3,I,384
Copy(L1,I+384,256

and
For(A,0,383
{L3+A}->{I+A}
End
For(A,0,255
{L1+A}->{384+A+I}
End

equivalent lines of code? only the latter works in my program. however, i'll experiment later today to see if having GetCalc(Str1)->I before the copy statements will make a difference.

edit: using getcalc(str1)->I before the copy statements makes it work, although the data at pointer I isn't modified anywhere in my code. if i have a Lbl I and call it as a subroutine, would this perhaps modify the pointer?