Well, for an assembly language export, just having the pattern data like this:
DATA >0123,>4567,>89AB,>CDEF
Maybe a label or comment to identify the 4 DATA statements with a sprite:
SP1 DATA >0123,>4567,>89AB,>CDEF
DATA >0123,>4567,>89AB,>CDEF
DATA >0123,>4567,>89AB,>CDEF
DATA >0123,>4567,>89AB,>CDEF
SP2 DATA >0123,>4567,>89AB,>CDEF
DATA >0123,>4567,>89AB,>CDEF
DATA >0123,>4567,>89AB,>CDEF
DATA >0123,>4567,>89AB,>CDEF
Anything like that would be fine, I'm not real picky. :-) Right now it is no big deal since you provide the pattern hex data in a text control, it is just a lot of copy and paste into my code.
For sprite color it would just be the single color, so just let the programmer deal with that manually. For tile colors, it sounds like the CV uses the Graphics 2 mode, which the TI can do too, i.e. 2-colors per 1x8 pixel row, however that mode is not supported by XB.
As for saving, I guess what ever it easy. ASCII hex patterns, 1 tile per line, start with sprite 1 and fill them up. Something like this maybe:
* sprite 1
0123456789ABCDEF
0000000000000000
1010101010101010
5500550055005500
* sprite 2
6C6C6C6C6C7FB267
In this case sprite 1 and the 1st tile of sprite 2 would be loaded, the rest could be set to all 0 or left as is. Also, if your load functions also absorbs the > and , characters, and possibly the word DATA, then assembly pattern statements could be used directly as a load file. :-) Does this make sense or am I talking in circles?
Ah, very nice how you can paste an assembly style string into those pattern fields! Nice touch.
If you want to publish the source, that would be cool, but it is totally up to you.
Matthew