@builderboy: what do you mean you would have to relly on other asm programs?? You would just recall the tokenized string/program into te source and then axe would parse it.

Well that's true, but you would usually have a shell or something on your calc. Or Quigibo could include something in axe that would let you do that.
I wouldn't like to use binary, it takes way too much room. But if you could let us have the option of with hex or binary that would work. 

ah ok, well that is good

I was thinking something along the lines of this.  I whipped it up in about an hour:

Yep, that would be pretty useful. A lot of people use Paint/Photoshop to create their sprite sheets or they do them on calc and store as pics, so an editor like this would make it much easier for them to draw sprites, cuz creating sprites in hex can be quite hectic

Could they be written in binary for readability and the have axe convert them to hex when the program is being compiled?

I like that idea, but I think it would be compiled to the format the calc uses for storing assembly programs. (I think it's internal-binary.  Am I right?)

So these are the currently wanted formats to store the source data in if i cam correct:

Pics: Easy to edit and easy to view/preview sprites.  Take up a lot of space however and source will not be in one file.  Pics may or may not be archived to save memory, and storage is efficient with 8 pixels per byte)

Binary: Just 1s and 0s in the program, easy to type and edit, and easy to preview, however this is VERY memory inefficient, at 1 byte per pixel.  Cannot be archived either, as it resides in the source program.

Hex: Similar to Binary but every 4 bytes is represented as a char from 0-F.  More memory efficient but harder to see what the sprite is supposed to look like, and harder to edit.  Cannot be archives. 4 pixels per Byte.

Tokenised: Taking Hex a step further, each 2 hex codes is tokenized by a program or the OS and recalled into the program.  Twice as efficient, but even harder to edit/preview.  Cannot be archived.  8 pixels per byte.  Same storage capacity as a pic, but can change size according to how many sprites you need.

Appvar: Data is stored in an appvar by some sort of sprite editing program and can be archived for memory uses.  This is memory efficient but makes for difficult previewing and multiple files for the source.  8 pixels per byte.

I personally am for Pics and Binary, if only because Hex/Tokens/Appvars are difficult to edit quickly and preview without external programs.  Also for making large amounts of sprites, like for huge tilemaps, it would be nice not to have a bunch of hex/tokens in your program, and be able to view the whole sprite map in one pic.  It also helps for sprites that are greater than 8x8, as they will have to combine multiple 8x8 sprites, which might be difficult to do/visualize with hex/tokens.

I never heard of tokenized sprite before

Don't forget, no matter what method you use to define sprites in the source, the assembled program will be the EXACT SAME SIZE.  And since you can archive your source files, and you can have more than one source file in the same project, efficiency is really a non-issue; they're just for the programmer's convenience.  Editing a sprite on-calc and then doing [rcl] [str1] or something for hex code seems, for me personally, to be the fastest and easiest way other than strait binary.  And also, I've already written code to read hex code used in the Asm() feature.  So only a slight modification will be necessary.  I can also modify my helper program so that 16x16 sprites can also be made easily.

The only advantages I see in using picture vars is that you can edit them on the computer and its easy to change an entire sprite set by just swapping a picture.  But I don't know how useful those features really are for most people.

By the way, I'm going to be very busy the next couple of days so the next update probably won't come until later in the week.