Full Color Tile Driver Thread

[potatohead]

Here is the latest, stable, release: http://forums.parallax.com/attachmen...3&d=1293501693

Tiles are 4x8. I know that is a tiny tile, but the trade-off is very good screen positioning. Groups of tiles can be handled in SPIN.

Pulled bad code archives from thread.

[Dr_Acula]

This is going to be fun!

Pictures showing what this is about are at the bottom of the page on this thread http://forums.parallax.com/showthrea...=126936&page=2

I've been thinking about ways of creating tiles from pictures. It is a number of steps using paint shop but not that hard. Resize to 64x64, (possibly round off corners) and decrease color depth to the custom propeller palatte. And I have code buried away somewhere that can take a bitmap and turn it into numbers. (I found some code http://www.rayslogic.com/propeller/p...rogramming.htm that can do a 'printscreen' from vga to a bitmap on an sd card, so it would be the reverse of that).

For an operating system, you could have a .bin file for the compiled binary, and a .ico file for the icon.

Meanwhile though, a demo that simply has numbers 0-63 to display all the colors would be fine. So a single 8x8 tile with numbers in it will suffice for testing. That could be a DAT or created with a few lines of spin.

Big question - do you think this can be done on VGA as well?

[potatohead]

I think so, but I really don't know about the VGA timing. I've built mine as a two COG solution. The TV cog can be used for other things, and modes. The signal is really good off of this one too.

Lots of stuff can drive the TV COG, which currently just renders from a scan line buffer. To see this in action, just don't start the graphics COG.

In the "start" Cog, just comment out this line to see the color bars.

TX.start(@tx_cog_init) 'Launch the text cog

With out the render COG, the TV cog will just draw what's in the buffer over and over. Others can do their own graphics COG.

I did this to illustrate the merits of developing very robust TV and or VGA cogs, as the prototype time was very short. Basically, I did not have to worry about the signal AT ALL, just the graphics logic, counters and such.

Time to build the (*^*&%* TV COG was LONG. Time to build a new graphics COG = very short!

Anyway, have a play with this bit. It's enough, and we can talk about where it goes.

We can also clean this up, and test the whole, load a COG from the SD card bit, to change modes and such... Like going from the menu to a text display, just by killing off a graphics COG, then firing off another one!

IMHO, the best way to build this stuff up, is to just make a bitmap, that's X tiles by Y tiles in size. 256 x 32 bitmap, for example, could hold all the tiles. The graphics cog can be tinkered with to use the image data directly. I've not yet done that.

Right now, the tile addressing is linear, meaning you should break the image up into strips, 4 pixels wide, encode your tile data, numbering the tiles sequentially from the top. Pack each strip in to a file, one after the other, and replace the tile pointer I've included, with the address of the top of the file.

Then put the tile numbers on the screen where you want the strips to appear.

That can all be adjusted, if this makes sense to do. IMHO, simple SPIN programs could also be written to just slice and dice a image it finds on SD card as well.

[Cluso99]

I noticed that the screen is defined as 80*24 whereas the colors are defined as 80*25 in 10_high_color_start.spin

You could save code space in loading the parameters but of course this will not speed things up.

Whereabouts do you need the code sped up?

[potatohead]

Good catch Cluso. The screen is actually 200 pixels high, so that's a gaffe.

This is a first pass, prototype to see whether or not it's worth it... And, of course I don't have VGA, so I'm a TV kind of guy, but I'll argue we could do S-video, and be looking very sweet. EDIT: I do have VGA now, just haven't for a long time.

Anyway, the graphics COG needs out of order instructions, like Potatotext did. I'm not doing it yet, because there needs to be cleanup, and some capabilities added, and the stripping out of some potatotext guts still in there. Just wanted to post something these guys could tinker with, sooner rather than later.

And I really wanted to give the, "just write a graphics cog" approach a try, with the work done to create the Potatotext TV COG. It just didn't take that long to get to this stage. Few hours, which given how long it normally takes me when futzing with the signal, is just excellent!!

Probably hold off for a moment or two, until the graphics cog intent is sorted out. Some thought needs to happen on tiles, and optimal code. Some tile sizes work out to simple bit masks and adds, others don't, and where that's true, the loop slows down a lot.

Oh, I just saw what you were referring to. Ignore colors. It's not used at all, and is one of the things to clean up. It's a left over.

[Dr_Acula]

The tile size probably does not matter that much - whatever you find works easiest in code and we can build icons to suit that.

Re vga vs TV - I don't have TV and you don't have vga. Do you have a vga monitor - I could send you a dracblade board if you do.

[potatohead]

I would love to borrow a board. Can always return it. All I've got is a HYBRID, Demoboard, and PPDB.

I've a VGA, but until recently, I've almost never been where I can code against it. Got a little workspace now! (kid left house, whee!!) So that, and the scope are usable now, with far less hassle. For the last few years, I've literally just packed the Prop around, with a video capture, for lack of any other place to do it.

Then there is learning the VGA... Should do it, maybe start with Kye's excellent work. I don't know all the timing details. Big task there is to build / convert something that does the right signal into a scan-line cog like this one, so that graphics cogs can connect. That might be a while... Who else knows VGA, and can we share tips?? Maybe it's easier than dealing with PAL is.

Re: Sizes. Yep, I was thinking that too, but this method only allows for 8K of tile data. It's less than optimal. Need words for the tile number. It's just wasteful, that's all. We are already wasting a few bits just doing a byte / pixel. Word addressing would waste a bunch more. That's why Chip packed so much into his TV COG, so that colors could be mixed with addresses...

Need to think on this, all comments welcome.

Kye's bitmap driver looks pretty sweet. I'm going to fire it up and tinker some. IMHO, it's a candidate for doing this stuff. Clean. Just don't know about speed in full-color mode. He's using full waitvid frames. That's 16 or 32 pixels. Full color requires 4 pixel frames, which will add complexity...

Edit: I've got his driver up. I'll do some speed tests to see what can happen, once I get it converted to full color.

[potatohead]

Dr_A, is it lack of TV display, or lack of pins?

[Bill Henning]

Interesting driver... I'll keep an eye on this thread

Ok, I've reached a first pass.

Tiles are 4x8. I know that is a tiny tile, but the trade-off is very good screen positioning. Groups of tiles can be handled in SPIN.

Resolutions are: 40, 80, 160, 256, 320. Right now, 320 pixels requires 96Mhz. Probably that restriction can go away with some more Cluso out of order instruction mo-jo, like we did on Potatotext.

Edit: BTW, if somebody has a fast board, the thing will probably do 512. If you try it, let me know the clock

I'm thinking the way to go here is a tile file, where the binary values are just in the file, with up to 256 tiles possible. Any pixel may be any color within a tile. No restrictions, but for the number of tiles possible.

This archive can be tinkered with. There is more to do, but 8K of full color tile data is possible with this one. Maybe try the SD card tricks with two of the menu tiles?? More to come, I'm sure, but this is enough to prototype with.

**I need some sexy tile data, for screen shots.

No screen SPIN routines are written yet. I've just written a few sample tiles, and put their values on the screen manually to verify the display driver is actually working as given.

I would suggest taking a image, and encoding it in tiles. The tile format is simple. Starting from the base address of where tiles are stored, each tile is 8 longs, stored sequentially, up to 256 tiles.

Tiles can be stacked on the screen such:

1,4,7
2,5,8
3,6,9

That block of tile numbers would equal a 12x24 pixel image on screen. To place the image, just put the tile numbers in the screen array where you want the image to appear, multiple places, if desired.

Stored in the RAM such:

Tile one longs
0
1
2
3
4
5
6
7
Tile two longs
0
1
2
3
4
5
.
.
.

Each long is 4 pixels on screen. The screen is the number of pixels / 4, with one byte indexing the tile for each screen cell. 320 pixels = 80 screen cells horizontal, 25 screen cells vertical.

Vertical resolution is 200 pixels.

I'll try to build some some tiles to illustrate where it is so far. I'm also seriously thinking about trying it the Parallax tile way, because it might be more flexible. Deffo want a bigger tile, or larger number of tiles too.

This is just barely enough to prototype reading some tiles from SD to see what might could happen.