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?

[Dr_Acula]

It is lack of a TV display. I get into trouble with the family if I commandeer the family TV(s). And the little 7" DVD player screen I have won't quite synch properly on the propeller (I recall this got discussed recently on another thread).

Anyway, the dracblade can be configured for TV or VGA. I'll send you a freebie board which you can keep - call it a 'hardware for software' swap?! Can you PM me your postal address?

I don't think memory will be an issue with an sd card and the ability to pre-load cogs and then to reload with the main program, as catalina does.

If you can get a tile with all the colors I think many of the other problems can be/have already been solved.

If speed is a problem, can you go multi-cog? 3 might be the max given other essential things but there are combos eg mouse/keyboard in one cog that can save cogs. So anything up to and including 3 cogs would be ok.

[potatohead]

Well, you should try this one on your little DVD. I'll bet it syncs, because it's a full interlace signal. That's one of the reasons I want to further develop this TV COG. With a coupla more options, like S-video added, it should display on anything.

I've attached one that has a simple set tile method, and that does 320 pixels at 80Mhz.

And a couple of really boring screenies.

...more when I get back from my "honey do" list. I'll PM the address in a bit. I really gotta get some good tile data. I'm willing to try the VGA. The two screenies are 320 pixels and 80 pixels, just to show the tile nature, and give some idea of screen density possible.

[Dr_Acula]

What format would you like the tile data in? Would a hex listing in groups of longs work? (I could do this but not for another 24h due to work)

[jazzed]

Wow. I take a 15 minute nap and you guys have 85% of a full page thread, and another demo

After struggling with HWpins for my platform ... again, I have a display on my dinky DVD TV LCD.

The screen is a thatch pattern and a small 2 tile yellow overlay rectangle. The driver is small Thanks for posting pics with the new .zip - I'll try that soon.

[Kye]

I'm sorry, but how do you achieve more than 4 colors using waitvid? Are you simply outputing smaller waitvid frames? One processor can't really handle frames smaller than 32/16 pixels...

Just interested...

[Cluso99]

Drac: You could try placing a 191R across the TV connector on your DracBlade. If you do not have 191R, try 180R or 220R or anything close and see if that helps. IIRC Phil also had a 330pF across also. Just cannot seem to locate my dwg at the moment.

potatohead: Yes, I will just wait till your ready.

jazzed: No rest for the wicked! This forum keeps taking my design time!

[Dr_Acula]

@kye, I don't understand any of the magic potatohead is doing. There is an explanation here http://propeller.wikispaces.com/Palette+Mode#the down the bottom talking about 'hi color mode' and the highlighted link takes you to here http://propeller.wikispaces.com/Colors where there is a reference to someone called .... potatohead, who has pushed it out to 400 colors.

[potatohead]

Kye, yes. You have to do a smaller waitvid frame. I was not the one that figured this out, but I'll go ahead and explain it. (One of the original HYDRA Demo coders ran the waitvid in reverse, opening the door for tricks!)

Basically, a waitvid has pixels and colors. 4 Colors are possible, and can be distributed among the pixels. The frame size is basically what you want, up to the limits of 16 and 32 pixels, depending on 2 or 4 color. This you know, and it's in the documentation.

It's common to run smaller than optimal frame sizes to make the video loops operate efficiently. A great example is the 8x8 text drivers. Those run 2 or 4 color, with just 8 pixels in the frame, which eliminates some shuffling around of bits in the COG at video signal draw time. That's costly --very costly. A big part of making Propeller video work is finding those things that a COG can just index with a simple add, or shift. Anything else, and combinations of those must either be pre-computed, or the video loop slows down, and that cuts resolution.

What I did, and have done in the past, is run the waitvid backwards. The frame is always just 4 pixels, never more, never less. The pixel data is fixed too. It's either #%%3210, or #%%0123, depending on the order of pixel output desired. In this configuration, a waitvid can reverse the data as part of the normal processing --a nice bonus in return for the small frame size.

Once you've fixed the pixel data, the colors data then simply becomes pixels!! There still is a 4 color limit, but since the frame is 4 pixels, there is basically no limit at all, making it possible to just assign any pixel to any color.

Clearly, this impacts two things: One is the video loop just got a lot shorter, meaning it's gotta run very lean, or bad things happen, like inability to feed the waitvid fast enough, and two, the amount of data that has to move goes up a lot, because we are talking whole bytes now, not just bits. On the other hand, dealing with bytes in a COG is a whole lot more efficient than bits are, so that's a net gain, combined with the "auto reverse" on the pixels, makes full color possible, although at a generally lower resolution than is possible otherwise.

TV is most favorable to this technique because of it's slower horizontal sweep frequency. I've not really got to run the VGA stuff to see what may be possible, but I do know it's got a faster sweep. That probably means in-line, unrolled video loops. No big deal on those. I think Linus did it for his demo, because I captured a post he had here with exactly that kind of thing going on. (that post is gone now, and I never did know why)

Because this really constrains the video loop, it's highly likely multi-cog will be needed. That means a scan line buffer, and the TV COG + Graphics COG approach I ended up using. The sprite drivers do this kind of thing, meaning there is code out there to learn from, which is what I've done, mostly because I kind of like this stuff.

Your driver is really clean Kye! I'm thinking it probably can be made to fetch from a scan line buffer pretty easy, and from there, add the signals to talk to a graphics COG. We shall see! It's always good to have a clean driver to learn from. Personally, I found the Parallax ones difficult because they do a lot! I started with a simple TV driver, written by CardboardGuru, and later on, used the Templates Eric did.

IMHO, your VGA bitmap is nice to build and learn off of. Thanks for writing it

Re: 400+ colors.

That's a NTSC trick. Basically, if you operate at a resolution of 160 pixels (2560 PLLA), and run the waitvid at 320 pixels, everything mixes together. I put a screen capture in the wiki, showing the mixing. There are a lot more colors possible. 1 or 2K is the max I think is doable. Needs to be NTSC and needs to be 160 pixels, period though. Thought it would be great for games. And a scan-line buffer driver conversion is needed to really exploit that. Hasn't been done.

This TV COG outputs a nice signal, sharp, and full interlaced, so the colors will show up very well on most TV's, making 320 pixels reasonable. One of these days, I need to build the S-video port, and run it that way. Bet that 512 - 640 looks pretty great.

[Sapieha]

Hi potatohead.


It function on my little LCD TV but have some horizontal line problems in periods of 2-3 second that are some 0.5 seconds long

Well, you should try this one on your little DVD. I'll bet it syncs, because it's a full interlace signal. That's one of the reasons I want to further develop this TV COG. With a coupla more options, like S-video added, it should display on anything.

I've attached one that has a simple set tile method, and that does 320 pixels at 80Mhz.

And a couple of really boring screenies.

...more when I get back from my "honey do" list. I'll PM the address in a bit. I really gotta get some good tile data. I'm willing to try the VGA. The two screenies are 320 pixels and 80 pixels, just to show the tile nature, and give some idea of screen density possible.

[potatohead]

@Dr_A: A hex listing would work for now. I'll just paste them into the working demo for the driver.

@Sapieha: What clock? What pixel rate? Which data? Which signal settings?

Mine displays steady for long periods of time. I've run it on 80Mhz Demoboard, and 96Mhz HYBRID. In fact, it's been running @ 320 pixels on the Demoboard, since the post above.

[Dr_Acula]

I think we will need some way of translating bitmaps to the color table. Probably a little program - I might take a look at doing something in vb.net

I did all my calculations for VGA mode but TV will be different. The bitmap will come out of paint shop pro having been decreased to 64 colors, then increased again when saved as a bitmap. So each pixel will be three bytes, and the bytes will have one of four values, 0, 85, 170 and 255.

Translating that to single byte values for vga will be easy.

But for TV, I see a table in the code that has 6 intensities and 16 hues.

So that is a palatte of 96 colors. Indeed, decreasing to 64 colors like for vga and then increasing to the best match of 96 is going to lose color information.

Better to start with the original bitmap data of 3 bytes per pixel and translate that to 96 colors in code rather than processing it through paint shop.

I'm greatly encouraged by the comments that vga will be possible. But for the moment with TV, what we probably need is a little bit of code that translates bitmaps into the nearest color in this table?

byte byte    $02, $03, $04, $05, $06, $07, $07, $07            'Six intensities
byte byte    $09, $0a, $0b, $0c, $0d, $0e, $88, $9f
byte byte    $19, $1a, $1b, $1c, $1d, $1e, $98, $af            '16 Hues
byte byte    $29, $2a, $2b, $2c, $2d, $2e, $a8, $bf
byte byte    $39, $3a, $3b, $3c, $3d, $3e, $b8, $cf
byte byte    $49, $4a, $4b, $4c, $4d, $4e, $c8, $df
byte byte    $59, $5a, $5b, $5c, $5d, $5e, $d8, $ef            'High saturation colors, placed
byte byte    $69, $6a, $6b, $6c, $6d, $6e, $e8, $ff            'in table by closest hue match.
byte byte    $79, $7a, $7b, $7c, $7d, $7e, $f8, $0f
byte byte    $89, $8a, $8b, $8c, $8d, $8e, $08, $1f            'Hues are presented in this table
byte byte    $99, $9a, $9b, $9c, $9d, $9e, $18, $2f            'vertically, in sequence as shown
byte byte    $a9, $aa, $ab, $ac, $ad, $ae, $28, $3f            'in screenie below.
byte byte    $b9, $ba, $bb, $bc, $bd, $be, $38, $4f
byte byte    $c9, $ca, $cb, $cc, $cd, $ce, $48, $5f            'Start with intensity on left, and
byte byte    $d9, $da, $db, $dc, $dd, $de, $58, $6f            'work to the right, starting at
byte byte    $e9, $ea, $eb, $ec, $ed, $ee, $68, $7f            'top of table.
byte byte    $f9, $fa, $fb, $fc, $fd, $fe, $78, $8f

[Kye]

Mmm, sorry to bust your bubble. But... doing that means that your video loop will need to run atleast 4 times faster.

So, for VGA... I would say you'll probably need a 100Mhz propeller to pull this off.

... But if you unrolled the loop and used a counter module to provide indexing for the video memory then something may be possible. Getting the counter to count up at the same speed though will be tricky.

The problem is that:

rdlong  screenPixels,         buffer                        ' Download new pixels.
                        add     buffer,               #4                            '
                        waitvid screenColors,         screenPixels                  ' Update display scanline.

These 3 lines must be run per waitvid. So, I think you can do an 8 pixel waitvid without problems... but a four pixel one will require an unrolled loop or a faster processor. If we could remove the "add buffer, #4" line with a counter module then it may be possible.

...

One more thing, since the prop has very little memory the resolution will be so low with this system that it will not be useable. So, what's the point?