PDA

View Full Version : Full Color Tile Driver Thread



potatohead
11-14-2010, 10:49 PM
Here is the latest, stable, release: http://forums.parallax.com/attachment.php?attachmentid=76703&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
11-14-2010, 11:01 PM
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/showthread.php?t=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/programming/Programming.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
11-14-2010, 11:09 PM
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
11-14-2010, 11:18 PM
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
11-14-2010, 11:23 PM
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
11-14-2010, 11:26 PM
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
11-14-2010, 11:29 PM
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
11-14-2010, 11:45 PM
Dr_A, is it lack of TV display, or lack of pins?

Dr_Acula
11-15-2010, 12:36 AM
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
11-15-2010, 12:53 AM
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
11-15-2010, 01:00 AM
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
11-15-2010, 01:36 AM
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
11-15-2010, 01:38 AM
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
11-15-2010, 01:49 AM
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
11-15-2010, 02:17 AM
@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
11-15-2010, 02:51 AM
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
11-15-2010, 03:01 AM
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
11-15-2010, 03:06 AM
@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
11-15-2010, 03:29 AM
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
11-15-2010, 04:20 AM
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?

potatohead
11-15-2010, 04:41 AM
What's the lowest sweep frequency most VGA monitors will display?

And can't the pixels be stretched to fit? That's something I've not had a chance to learn yet. On a TV, one just makes a longer pixel, and have it be a factor of the optimal number of pixels.

Can't that happen on VGA? So then, maybe it's good for 300 pixels, or so, right?

As for usability, that's a matter of what one wants the display for. Sprites are usable in low RAM situations. Tiles are too, which is how the nice text displays are done.

The idea being explored here is to present a graphical set of choices. Since the prop has software video, one can simply load what it takes to make that happen, stop it, then load something else from storage. That changes the usability game considerably, which is why I bothered with the tile display in the first place.

Baggers has a full on Raycaster running on the thing. A few tiles isn't out of the realm of what can be done. Besides, it's fun! :)

Oldbitcollector (Jeff)
11-15-2010, 04:43 AM
Wow.. Very cool indeed!

Had to make a run to Cleveland today and missed this thread..
Will definitely be playing catch-up!

OBC

Dr_Acula
11-15-2010, 04:47 AM
100Mhz prop? Guess I'd better get some faster xtals.

Sounds like we do TV first?

Re the use, well, lots of uses. I'm thinking a black screen with six hi-color 64x64 buttons (approx ipad size), and each of those brings up menus of other buttons, or runs binary programs. But you can do other things too - eg have primitive tiles for things like the corners of buttons, and the lines on the side and top, and the fill. Tiles for a check box that is checked, and one that is unchecked.

Sure, you are not going to fill a screen with these due to hub ram limitations, but if you have a gray screen with a couple of check boxes and a button, and then you refresh off the sd card with brand new tiles and redraw another screen, it would have an 'eye candy' appeal that text based operating systems will never have.

Of course, it still might be something like Kyedos behind the scenes. Or Catalina (which gives you about 30k of hub ram to play with).

Oldbitcollector (Jeff)
11-15-2010, 05:23 AM
Would some external SRAM allow for more colors here?

I can picture all kinds of interesting uses for something like this..

OBC

Dr_Acula
11-15-2010, 05:26 AM
Re external ram, I think potatohead is going to do it all from hub ram.

External ram may be useful though as it could be faster to load tiles from sram than from an sd card. For flexibility, one would probably have the option to load tiles from either source.

I'm not sure it would be possible to load external ram on the fly for each frame. Possibly with cluso's ram but the aim would be to design screens that don't require this. Lots of simple screens that you click through rather than putting everything on one screen.

potatohead
11-15-2010, 05:32 AM
Pretty much needs to be HUB RAM.

OBC: From here, the paths to more colors involve new video circuits, as in what Coley and Baggers did, or multi-cog tricks, and in all cases, the HUB RAM gets consumed. Using all the Prop colors has always been possible. What changes the game is being able to run programs from external RAM, and SD card, followed by the idea of BLOB style drivers. Kye-DOS means being able to make a fairly large program, fetching things, doing something, then fetching something else. It's like early computers now!

So, some driver work now makes sense. Before, it was a curio, like for the wiki display, and the fractals, where only a tiny program is needed, or possible.

Dr_Acula
11-15-2010, 05:41 AM
Potatohead, can you briefly describe how the hex codes for colors map to colors? Eg, for TV, you have three pins, right, and a DAC with three resistors, so isn't that only 7 values?

Looking at the palatte for TV, it seems different to the vga palatte I calculated - eg there seem to be a lot less red and yellows. Is there a mathematical formula to convert RGB values to the single byte hex code you use?

potatohead
11-15-2010, 05:51 AM
There is, but I don't understand it that well.

VGA uses RGB values directly. So it's just levels of red, blue, green.

TV uses a phase angle for the HUES, and there are 16 of those. Google the color wheel, and dividing the wheel into 16 slices gets you the kind of formula you need to work out the hues. Edit: And how the signals add together limit things some. Just for extra fun, we can shift these some in the TV cog, by altering the reference signal, improving reds and yellows, at the expense of greens and probably blues... TV's are messy.

Intensities range from 02 to 07, and are just added to a hue. If you broke the RGB down to HSV, those values would map over more easily.

Lower order bits are intensity, higher order bits are hue, some unused with TV.

Color = hue(0-17) + intensity(2-7) is the space I use, with the CLUT table you found.

Another oddity is any hue + intensity 7, is outta spec, and shows up as a higher saturation color. That's the top row in graphics_palette.spin

If you look at the wiki page I did, ALL the propeller colors are in that table on the page, and there are two high-saturation color sets, and they are hue shifted from the ordinary colors. Look at the strip along the bottom, and up the right hand side. Those are all "pure" Propeller TV colors. About 96 of those will display well on all devices. Some devices reject the low intensity colors, and some reject the brightest, out of spec colors too.

potatohead
11-15-2010, 06:39 AM
Re: 8 pixel waitvid, could be: waitvid colors, pixels

where "pixels" = %%00112233, for the same 320 pixel resolution found on TV. That's the thing to try on my next session.

So, scratch the 4 pixel frame, never more, never less. It can vary. It might have to on the higher sweep rates.

Dr_Acula
11-15-2010, 11:26 AM
I looked up NTSC and it makes more sense now.

Ok, the color wheel http://en.wikipedia.org/wiki/Color_wheel is great for colors but it doesn't show shades of gray, nor shades of gray with slight color added (gray with a tinge of blue). I think you need three axes to describe all the colors? (hue/saturation/lightness or red/green/blue).

So "Lower order bits are intensity, higher order bits are hue" - what does lightness? http://en.wikipedia.org/wiki/HSL_and_HSV

So say we take the first two lines of the data

byte byte $02, $03, $04, $05, $06, $07, $07, $07 'Six intensities
byte byte $09, $0a, $0b, $0c, $0d, $0e, $88, $9f

Is the first line the shades of gray?

And is the second line a combination of intensity and color, or do you pass these as two separate bytes?

I'm just thinking if we are going to preprocess a bitmap, may as well process it so the cog does the absolute minimum. Eg if it is easier to pass a long to a value rather than a byte, then pre combine pixels into a long.

Kye
11-15-2010, 01:46 PM
So, I looked back at my calculations and its actually very possible to do this.

By strenching the pixels across the screen by setting the vscl register you will have plenty of time to get the next four pixels.

So, I think 160x120 at 1 byte per pixel will be very much doable. The only problem I see is that you won't be able to double buffer...

So, now the real question is: Would this driver be usable if you can't do that. 160x120 = 19200 pixels... That's alot of elements to clear and change at 60 FPS. Changing them any slower will result in screen crawl.

... So, unless the resolution gets even smaller the screen will never be able to be updated nicely.

ericball
11-15-2010, 02:19 PM
Dr_Acula

Translating from Propeller luma+hue to 24 bit RGB is easy, just start with the CCIR 601 YCrCb to RGB formulas. RGB to Propeller luma+hue is more problematic as there are only 102 colors and they aren't arranged nicely in the RGB color cube. It might be possible to try to do the remapping as the image is loaded into HUB RAM, but I don't think it would be possible to do it on the fly as part of the video driver.

Bill Henning
11-15-2010, 02:20 PM
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.

potatohead
11-15-2010, 03:15 PM
Thanks for looking Kye. I won't have a shot until later today. All I did was run your driver and look the really clean code over. Again, nice!

Pretend the solution is not clean for a moment. Do you think a unrolled loop would do 320? Maybe just stuff 80 waitvids in there along with the add, required for the index!

And the final product will only need to read from a HUB buffer, for a single scan line. Another COG will build from the "screen" tilemap, writing the product of that into the buffer, as the VGA COG is drawing it. What I do, is start the graphics building, right after the VGA cog enters the front porch. That gives the graphics COG a head start writing the buffer. It tends to run a bit more slowly at higher resolutions, just finishing as the VGA COG fetches the last visible waitvid frame.

If any more speed is needed, multi-COG is needed, or the buffer needs to be a double buffer, which I'm considering anyway. A single buffer is lean, but causes a timing problem, if multiple COGs are all combining data for the buffer. Double makes that easier.

Another thing that could be done is to adjust the porches, so that a different primary resolution is drawn, making something between 160 and 320, worst case, a factor, so that the highest possible at 80Mhz can be done, or we just do 96 or 100Mhz. I've xtals for both. It's possible to make a "remainder" waitvid frame too, so that non-factor resolutions work. If those things are done, the graphics COG gets a longer porch time for it's run up ahead of the VGA COG, and the display narrows by some small percentage. What I don't know here is whether or not digital monitors will sync to stuff like that. Analog is no problem. I've seen other PC applications do tricks like that, and TV's don't care what you do after the sync, happy to display a mess, if you code one. :) My VGA is a analog one, BTW, though I could test finished code on various digital ones at work.

The end product will be a tile driver. It's by nature, double buffered, in that the tile can be written, while off screen. The "screen" memory, unlike a bitmap, is simply a index of tile numbers, where each tile can be positioned anywhere on the screen grid.

A small stack of tiles acts very much like a bitmap too. That's actually almost how the Parallax drivers work, the difference being "the screeen" is a list of tile addresses, but same concept applies.

Screen manupulation can happen two ways. One is to build the tiles off screen, then "pop" them on the screen by writing a few values to the "screen" array. They will appear on the next scan of the monitor. The other, is to write some tile values, so the tiles are seen, then operate as one would a bitmap driver, and that can be seen while drawing, and is basically single buffered.

Finally, since the tiles are indexed, common graphic tiles can be used in multiple places on the screen. Unlike the Parallax driver, which has color redirection, this one works in absolute color, so the common graphics would need to have the same color, not true of the Parallax tile drivers, because they also have a colors array to address that.

This particular driver allows 8K of unique tile data. That's going to get expanded on the next pass. This was a proto, "is it worth it?" pass, basically done at Dr_A's request, because I had code that was close.

For what it's worth, the Parallax driver, can run single buffered, and use a small pool of tiles off screen to render things, popping that onto the screen, exchanging it for another small region, in a sense, double buffering a fractional screen, trading flicker for tearing in the image during changes. Doing that round robin style for a whole screen is something I've always called "ripple draw", because the tearing can be seen, as can image change errors over time, but it doesn't flicker much, if any at all. For some things, like perhaps a aircraft flight simulation, or instrument panel, it can work well. Partial buffered I guess is the right way to describe doing that with tiles.

I'll have to code this as a demo one day, also doing common tiles with different colors and using color redirection to "pop" things onto the screen with no flicker. Tiles are very useful that way, and were used in older computers that had limited fill rates. Color can be used to hide a image already drawn. When a visible color is assigned, the entire thing will be displayed next frame. On the Parallax driver, progress bars, check boxes and other things could be on the screen, shared, and just made visible or not, kind of like those stereo displays with the elements just needing to light up, depending on state, using very little HUB RAM, and no requirement for a double buffer.

Lots of great graphics, Propeller relevant, mo-jo is to be had by looking at the very late 70's through late 80's. That's when graphics really started to take off, and there were a lot of trade-offs in speed, and overall screen color / resolution capability. The Apple ][ is where I first saw "ripple draw" being used to manage a whole frame. It was possible to draw a smaller region quickly enough to avoid major flicker, and so that was done, dividing the frame into a few regions. Effective frame rate for the entire image to change was, like 15Hz, but there was no flicker, and detail regions could change much quicker than that. Apples had no color redirection though. Saw that used on many other computers, often to great effect. Best thing since sliced bread, if your fill rate is low, IMHO.

Finally, there is dynamic drawing. Baggers has many examples posted here. With dynamic drawing, the screen does not exist as a static entity, like a bitmap. It's just created on the fly, as the beam is drawn. Best example of this is the old Atari VCS, which had NO frame buffer, and only 128 bytes of system RAM, yet was capable of drawing "Space Invaders" nicely. In that scenario, one draws only what is needed just in front of the monitor beam, doing it again, each frame.

Props are well suited to that, and single buffer tricks because they are actually quite fast compared to their ~320 - 640 pixel resolution. (I know they go higher, but those two are the ones where the chip shines, IMHO) Props also can do stuff in parallel, which helps considerably. For example, on a bitmap, there could be multiple regions, where each is managed by a COG, contributing to one single buffer display, no flicker. That's difficult to do anyway, but way more difficult on a interrupt based CPU. Props just make it a management problem. Sweet!

Anyway, in the end, the simple bitmap is the hardest one to deal with. It's very demanding of RAM, and requires the most operations to fill, but it's the easiest to code for. On a Prop, because of the HUB RAM, other display tricks are often needed to get a significant display. Honestly, that's one of the big attractions of the Prop for me. It's software defined video means pretty much all of those things are on the table, and that's fun for me, so here I am.



So, I looked back at my calculations and its actually very possible to do this.

By strenching the pixels across the screen by setting the vscl register you will have plenty of time to get the next four pixels.

So, I think 160x120 at 1 byte per pixel will be very much doable. The only problem I see is that you won't be able to double buffer...

So, now the real question is: Would this driver be usable if you can't do that. 160x120 = 19200 pixels... That's alot of elements to clear and change at 60 FPS. Changing them any slower will result in screen crawl.

... So, unless the resolution gets even smaller the screen will never be able to be updated nicely.

potatohead
11-15-2010, 03:21 PM
The second line is a combination of hue and intensity. Only one byte is used for color definition, and it has a intensity bit-field, and a hue bit field.

Yes, a third axis is needed, however the Propeller saturation is fixed at two levels. There is the faded one, common to most of the colors, and the overly intense one, common to a few of them. The color wheel idea was just to communicate how hue ends up on the screen. Sorry about that.


I looked up NTSC and it makes more sense now.

Ok, the color wheel http://en.wikipedia.org/wiki/Color_wheel is great for colors but it doesn't show shades of gray, nor shades of gray with slight color added (gray with a tinge of blue). I think you need three axes to describe all the colors? (hue/saturation/lightness or red/green/blue).

So "Lower order bits are intensity, higher order bits are hue" - what does lightness? http://en.wikipedia.org/wiki/HSL_and_HSV

So say we take the first two lines of the data

byte byte $02, $03, $04, $05, $06, $07, $07, $07 'Six intensities
byte byte $09, $0a, $0b, $0c, $0d, $0e, $88, $9f

Is the first line the shades of gray?

And is the second line a combination of intensity and color, or do you pass these as two separate bytes?

I'm just thinking if we are going to preprocess a bitmap, may as well process it so the cog does the absolute minimum. Eg if it is easier to pass a long to a value rather than a byte, then pre combine pixels into a long.

ericball
11-15-2010, 03:49 PM
For a first pass RGB lookup table I took the screenshot potatohead made http://forums.parallax.com/showthread.php?t=126099 and generated the attached file for the 134 colors (6 grey + 8 * 16 colors).

jazzed
11-15-2010, 03:57 PM
Ok. Silly question time.

How do we add text to the screen?

We can't have 80+ tiles just for text.
There must be a way switch modes (per-tile?) for low resolution text.

@ericball, I've been looking for that table. Thanks.

It does map to the clut right?
And the clut is used in this. Right?

http://obex.parallax.com/media/thumbnails/potato_thumb_01.jpg

ericball
11-15-2010, 04:28 PM
@ericball, I've been looking for that table. Thanks. It does map to the clut right?
It's a simple list of color number to 8R 8G 8B value translations. The RGB values are not authoritative, but should be "close enough" if someone wanted to try to work out how to perform the reverse translation.

Note: due to how the Propeller generates color, colors $x8 and $xF are the same hue and luma as $xB and $xC (respectively) but with triple the saturation.

potatohead
11-15-2010, 04:31 PM
Right now, on this one, it's tiles = text.

I've not had good luck mode switching waitvids mid-display. The decisions required in the video COG consume time, and will on occasion miss the waitvid data latch window, resulting in extra pixels, or snow. That said, modes per tile would be a excellent use for the unused bits present, if tile definitions were to move to a word per tile. Maybe that's worth another play. We know more about the waitvid now compared to the last time I personally tried that.

Coupla ways this could go:

Add a COG to overlay a text screen, right on top of the tile screen, crunching bits to fill the buffer. (maybe)

Multi-mode tiles. (maybe) Divide screen into vertical regions, where a given region could be text tiles(2 or 4 color), or graphics tiles (all colors). (possible)

Add to the number of possible tiles and just draw text, or define enough text to suit the display. (possible, and easiest) Probably costs 4-6K though.

One last method would be to just fire off a monochrome text COG for TV, and output to the same pins. Works for text on black, but not text on white. Same for VGA, only that could be color. (maybe) Linus showed how to really sync COGs.

Other??? Any and all comments welcome here.

That's one of the "is it worth it?" task questions! :) Everything costs something.

evanh
11-15-2010, 05:07 PM
What's the lowest sweep frequency most VGA monitors will display?
Line-rate of CRT's bottomed out at 28 kHz. It was frustrating trying to find monitors that would be happy with the 18-24 kHz range. And even specialist scan-converter units were never spec'd for it either. It was always boring old video to VGA or VGA(+) to video. :(

As far as I know that hasn't improved with modern LCD's even though they all have the fancy scan-converters built right in that, theoretically, wouldn't have any problem at all handling pretty much any lower frequency.


And can't the pixels be stretched to fit? That's something I've not had a chance to learn yet. On a TV, one just makes a longer pixel, and have it be a factor of the optimal number of pixels.

Can't that happen on VGA? So then, maybe it's good for 300 pixels, or so, right?
Yep, just the same for VGA signaling. Tweak the pixel clock to suit.

Kye
11-15-2010, 05:42 PM
@potatohead - Hmm, a double cog solution seems akward. Its doable but such a driver will instantly not be easy to use and ... requires two cogs.

I much prefer the bitmap idea, but the memory requirement is too much.

Maybe there is another way? I can code the bitmap driver in a few hours... not like I have a few hours in the coming days but I can post a 160x120 6 bit RGB bitmap driver in a couple of weeks if you would like.

But, without some sort of trick to fix the buffering the image will look bad when being updated.

But, on the bright side. Since each pixel is a byte it should be really easy to fill the screen quickly.

... You know more about this than me, is there a way in which a single bitmap frame buffer can be used to hold the screen... but be updated nicely? We have vsync to use still, and memory access should be fast.

Having a scanline buffer means that the driver will not be user friendly.

jazzed
11-15-2010, 06:55 PM
Add a COG to overlay a text screen, right on top of the tile screen, crunching bits to fill the buffer. (maybe)

While not optimal, I think this is a fine short term solution. Do something else later.

potatohead
11-15-2010, 08:19 PM
Kye,

Yeah, I hear you on the usability. Call it a built in conflict. If the video is really easy, it doesn't do as much :)

A full color bitmap would be good. Saves a step in making a scan-line VGA COG. If you feel inclined, I'll put that effort to use for sure.

VBLANK is kind of good for some things, not so good for others. If a entire draw-erase cycle can exist in the VBLANK, then it's good. If not, then it doesn't help much, without either a small buffer, or dynamic drawing techniques (sprites, display lists, etc...), or tiles and such that change more or less instantly.

If we want more than 4 colors, it's just going to require some cruft, because the RAM isn't there.

One upside to a multi-COG technique is being able to very quickly build a graphics driver, without also having to manage a signal driver. Doing both is hard. Doing one or the other is considerably easier. Also, that does open the door for dynamically loading video kernels. So, have the prop do one thing well, then another thing well, instead of packing in lots of things, all done not so well. Ease of use goes down, capability goes up! It all costs something in Propeller land.

The only bitmap techniques I know of that help with buffering are:

1. Use XOR drawing, so that most of the screen pixels are visible at any one time.

2. Draw portions of the screen during the blank. (limited by fill rate)

3. Sort the drawing of things, largest to smallest, drawing larger things at 15Hz or so, smaller things faster. This can limit flicker, and manage what happens in the blank. Takes a lot of logic though. One has to build a draw manager, in addition to drawing, and a driver. You've really gotta want that, or it's better to surrender resolution, and or dynamically draw things, IMHO.

4. Software tiles. Use a small amount of off screen RAM to queue things to be drawn, draw them off screen, then blast them to the screen. Effective if there are smaller regions to be drawn, or the drawing can be spread out over time.

In all cases, the idea is to keep the number of lit pixels at max, never doing a full on erase that could exceed the blanking time. That flickers badly. Also keeping the changes to less than half the scan frame rate is good, particularly when there is no sync with the video device. 20Hz max for screen updates would be a good bitmap target, if the draw tasks exceed the blank. That way, draws can be spread out over three blanks, rippling the screen some, but not flickering, and there I've come around full circle to ripple draw again.

If those won't work, then a bitmap is not indicated, and tiles, sprites, etc... are, in my limited experience doing and watching these things get done. IMHO, tiles arranged as bitmaps have a lot of advantages, which is why the Parallax driver operates as it does.


@potatohead - Hmm, a double cog solution seems akward. Its doable but such a driver will instantly not be easy to use and ... requires two cogs.

I much prefer the bitmap idea, but the memory requirement is too much.

Maybe there is another way? I can code the bitmap driver in a few hours... not like I have a few hours in the coming days but I can post a 160x120 6 bit RGB bitmap driver in a couple of weeks if you would like.

But, without some sort of trick to fix the buffering the image will look bad when being updated.

But, on the bright side. Since each pixel is a byte it should be really easy to fill the screen quickly.

... You know more about this than me, is there a way in which a single bitmap frame buffer can be used to hold the screen... but be updated nicely? We have vsync to use still, and memory access should be fast.

Having a scanline buffer means that the driver will not be user friendly.

Dr_Acula
11-15-2010, 11:15 PM
For this particular thread/code, small full color tiles are much better than big tiles with less colors. If 90% of the screen is black or gray or white, the rest easily fits into hub ram without clever buffering techniques.

Given all the external ram solutions, including a very cheap/cheerful/slow spi sram with catalina, can we assume you have at least 30k of hub free? I think it will greatly simplify things to not have to worry about buffering on the fly nor bringing in data from elsewhere between frames. Or as Cluso says, devote an entire propeller just to this and do other processing on another propeller. Then you have all the hub free.

Re text, I'd be inclined to completely reload a text based binary from an sd card. Click on a picture with a big W for Word Processing, and then up comes a text based word processor.

Having read the Propeller TV LUT file, I am now completely confused about NTSC and colors!

I like the idea of a 3d cube with red/green/blue on the axis. From a simplistic point of view, I suspect one would want to sample points evenly in that cube. Doing that for a VGA driver with 2 bits per color gives the attached palatte.

Top left corner is black, bottom right corner is white, and there are two grays, row 2, column 6 and row 3 column 11.

But looking at the TV, there are more gray values. But, thinking simplistically about the 3d cube, this ought to come at the expense of other color values (even allowing for 96 vs 64 colors).

I found this formula but I last studied matrices a long time ago http://www.mathworks.com/help/toolbox/images/ref/rgb2ntsc.html

Then there is another way to look at it - you have TV values 0 to 256 and some map to colors and some don't but you determine where those colors are in the RGB space?

With some of the posts earlier, how is that being done? Are we talking a photo of a TV screen, or is there a more definitative way to determine the colors?

For example, in the TV table the first line is
color R G B
2 5 6 8

But I would have thought the RGB values would be 0,0,0.

Or at least, if you are building a table that you then go and map a RGB value to, you at least want to map it to the correct value. Were those values determined by taking a photo of a screen, then putting it into paintshop and seeing what the RGB value was?

Sorry to get hopelessly confused about this, but the simple task of taking a little bitmap picture and converting it into the TV byte values for a propeller is looking quite complex!

And just to throw another spanner in the works, I see on that other thread comments about using the 4th pin (the audio pin?) as part of the solution. So is this part of the 'standard' design?

Advice here would be most appreciated.

(Maybe it is as simple as taking a RGB value and searching that TV LUT table for the closest match?) Addit - no it can't be that, because with an RGB value of 0,0,0, would you choose a match with 2 (which is 5,6,8) or with 137 (5,2,8).

Cluso99
11-15-2010, 11:20 PM
potatohead: Keep going. In the end, it does not matter how much of the prop is used (cogs & hub) for this as long as the actual app doing the updating can also live in the prop.

If this all works well, then I see the prop as a cheap solution to the video section, and just as I have a RamBlade for emulation, I could see a VideoBlade for the video. Another prop would be fine for the remainder of the I/O and use a high speed link between props.

potatohead
11-16-2010, 05:02 AM
I think I'm going to move to a word per tile address. The current byte only tile definition isn't optimal.

After thinking text through, it's really only about 6K to get both the additional tile address space, and 96 characters, or so. Another choice people would have is to simply make a little bitmap, and draw text in there from SPIN.

The only real, for sure, cost is doubling the screen array. That's 1.5K, and in return, the max possible tiles. Tile data goes up from 8K max, to the limits of the HUB. No brainer.

This is really a graphics driver. If the BLOB idea works out, options can be done. One could load the graphics driver, do icons, load a 4 color text / tile driver, still do graphics, and text, or a bitmap, etc... IMHO, prototyping that is compelling, because it can see use in basically all the Prop dev environments. Fetching video and starting it from SD probably can happen on the order of a second or two. That's quick!

Coley and Baggers did PropGFX, using a Prop as a slave graphics device. That's actually a impressive device, but it comes with a lot of dependencies, like comms, API, etc... The idea of little, useful binary pieces appeals to me, largely because I can write them, and it's very Prop like. It takes a lot to just do a PropGFX, and that means limited use overall. On the other hand, little, useful pieces can see a lot more use, and on a single prop, maybe from any language that can read from storage and COGNEW. That's likely the more potent path.

This same TV COG can drive other things, like a bitmap, etc... The Potatotext TV COG is wired to the graphics cog in too complex of a way. I think I'm also going to just leave that one as it is, but for maybe making it binary loadable, just because.

So then, IMHO, the right thing to do here is make a fast, clean, hi-color graphics COG that can have text on it, but isn't specifically optimized for that purpose, then do some other drivers, modifying the TV COG slightly to support each one. Only takes a few options to then permit most things a Propeller can do!

I really want to see the SD card, external RAM program, binary object idea play out, and if some pieces get made, others here will probably do that. Of all the things I've seen video wise, doing this is the most portable, and if it's somewhat modular, maybe others can jump in, and we get a nice library. Toward that end, I'll get the TV COG cleaned up, so that graphics / text / tile / sprite COG BLOBS can be written over time.

Also a VGA cog needs to get done. Maybe the graphics COGs can just work with it.

potatohead
11-16-2010, 05:10 AM
I'm confused about the color problem. Can't we just take some good captures, blur those, sample those, and make a RGB to TV Byte table? From there, a simple closest RGB match works fine, right? So, it's just one table, no real math, and only a matter of just sampling all the TV colors possible.

Am I missing something?

On the color computer, I did 256 artifact colors, and another enthusiast arrived at that solution. All they did was take the capture, blur it (that computer had more noisy video than the prop does), index the byte values to the RGB, and make a palette for their graphics program. At that point, both a program can be written, and graphics manipulation are possible, arriving at the right byte value rather easily.

jazzed
11-16-2010, 05:23 AM
I don't have 6KB to spare ... ever.

Guess I'll diddle with the Text COG when I have a chance.

potatohead
11-16-2010, 05:31 AM
It's going to cost a fair amount of that to do text anyway. It all costs something. A text screen is 1K, and a COG needs to be written and loaded. That technically doesn't cost, once it's in the COG. Then there is the font. That's 2K more, or so...

Let's just say that's three. If you want colors on it, that's another K, so now it's 4, and a COG, and a very high degree of added complexity.

Basically, you don't have room to do text and tiles at that point, in a full color environment with that constraint in place. The difference in tile address space is less than 2K, with usability way up in terms of the tiles and graphics options, all of which are not doable right now, where text is --and doable very well, in a lot of different ways.

(which is a big part of why I'm going to take the next step by maxing out the tiles. I thought that part through already, not seeing the return)

If you want to do that, I encourage you to do so! The existing graphics cog can be modded to do it. One problem to solve is getting this done, in one scan lines worth of time:

convert font nibble %0101 to long for the buffer $00FF00FF, then mask it against a color, then write it to the buffer. That's after looking up the text value, indexing to the font scan line entry to get the byte, of which both nibbles need that conversion, from 2 to full color. IMHO, that's a tough call to get done with one COG. It's a lot of HUB fetches and COG lookups.

It may be that mode switching could work. I can't take that path right now and be productive with this project, because I want to see the VGA part of it go as well. IMHO, that's a significant diversion, and there still is the RAM cost, and the COG cost, because that effort would also require a COG.

Dr_Acula
11-16-2010, 05:37 AM
The challenge is to produce a little tile, say 12x8, with all the 96 colors in it. I am sure we can do color matching later, and text etc will be easy as we can do captures of existing fonts including fancy ones, and with catalina on exernal ram or with a dual prop solution, there will always be 30k hub ram free, but do you think the code is possible for a little 'all color' tile?

Ariba
11-16-2010, 05:45 AM
In this thread. you find my 128x96 bitmap VGA driver with 1 byte per pixel.
The code si very small, so maybe it is a good start to make a tile driver out of it.
http://forums.parallax.com/showthread.php?t=122473&highlight=128x96

Andy

potatohead
11-16-2010, 05:49 AM
Thanks Andy. I'll be looking. Eager to finally do some VGA.

Dr_A, If you just want all the colors, I can do that. Are you looking for swatches, to apply the techniques discussed? If so, no worries. Honestly, I'll just mash up some longs in EXCEL, cut, paste, and do a capture.

Not hard to put all the colors up there. That's what this driver is for!

Wait a minute... You want all the colors packed in, just one pixel per color?? Well, that's actually considerably easier than swatches. Only takes a coupla tiles, but on a TV, they are going to smear together, just FYI. A couple of tiles with all colors can just be quickly typed into a DAT statement, but they are hard to see.

Do you care, if they are big pixels? Could run the driver at 80 pixels, build the tiles, and capture that. Let me know which.

...or are you asking for 96 pixel tiles? That one is harder, because it doesn't match up to a power of two, complicating the COG, limiting resolution.

Dr_Acula
11-16-2010, 06:01 AM
Yes, random colors in a little tile is the challenge.

What I've be very interested in is the max resolution you can go to. Eg, you put a yellow pixel next to a gray pixel. Do they bleed together?

As you shrink the tiles down, yes they probably will bleed together. So that sets the minimum size you can go as pictures won't looks so good if the colors bleed. It would probably depend on the TV, eg on a big TV maybe you have what you call individual pixels (the concept is a bit vague on a TV, but ok, consider just lines, 525 lines, so one line is equivalent to one pixel), but maybe on a 7" LCD TV screen, you make the pixels bigger. Same ram requirements for each. Maybe you go two pixels per color. I guess that might take some testing. Put a yellow dot on a gray background and see if it looks like a yellow dot??

With VGA, individual pixels on the text drivers look crisp and clear so the propeller is capable of driving a clear signal (so long as another vga screen is not too close, or any radio transmitters!).

I just ran Ariba's file. Very nice! Random little squares filling the screen with random colors. I didn't know this was possible!

So - would it be possible to make those little squares smaller and leave most of the screen blank? Even to the point of a tiny 8x8 tile, right in the middle of the screen with 64 colors in it?

potatohead
11-16-2010, 06:44 AM
Ok, I get where you are headed now. Did your little TV sync?

re: VGA: Yes. I think it's possible to get smaller pixels, and not fill the screen, and that's what I'm going to do with one of those VGA drivers.

(this will be somewhat long, but it's good to know TV info --since I've done a lot with TV's, this is a topic close to my working experience)

Yes, VGA will just do pixels, right next to one another with almost no issues.

TV's don't generally do that at higher resolutions.

The driver runs at 40, 80, 160, 256, 320 pixels. At the 80 pixel size, any color may be shown next to any other color, and it's going to work well on all but the really crappy TV's. The TV signal is encoded in a way that has fairly low color bandwidth. On most images, there is a smooth blending of colors, and this all works out very well. Computer graphics are not that way, because of sharp transitions.

My general experience with most newer TV's is they will generally render unique colors at 160 pixels and below. Above that, the signal doesn't have enough bandwidth to clearly differentiate colors. That said, the newer the TV, the better it generally does.

I like to think of the color wheel when mentally gauging what might be possible. The greater the angle on the color wheel, the sharper the color transition is, the more blending and smearing of the color pixels there will be.

So, at 320 pixels, putting a red pixel, right next to a blue one will show some degrading of the pixels. A very nice TV will still resolve most of that, but it won't be perfect like a VGA is. Though, on your image icons, that blending actually helps smooth them some, giving them a higher resolution look than they actually are. Something to think about.

Also, the transitions from black to white, and white to black can produce bits of color as well. It's the same limit. TV's basically operate at the 160 pixel resolution, in terms of this driver. Less will look perfect, 160 solid, greater has trade-offs.

If a S-video connection is used, this improves significantly.

Also, whether or not the signal is interlaced helps define the pixels better. This driver will do a full interlaced signal, and it's sharper than most because of that. The Parallax TV driver can also be made to do that, with similar results. Most other TV drivers are non-interlaced, and they show artifacting on high contrast color and intensity areas.

Eric Ball posted up the S-video option, and Bill has had it running on his Propcade. I want to do one on the PPDB, just to see. If it's like my other devices, and I've no reason to believe it isn't, then the difference will be notable.

What can be done to illustrate this is some color patterns, and then run the driver at it's various resolutions, demonstrating what is optimal.

In general, with TV graphics, it's best to limit high resolution color transitions, and to use luma (intensity) to show detail. When this is done, color clash can be kept to a minimum, while still getting good use out of all the colors.

For this driver, the 256 pixel setting is probably the best overall balance. It's still kind of a square pixel, instead of long one horizontally, and it's not too far over the sweet spot. 320 pixels can have the most detail, but one needs to be careful about colors in use.

Some sample tiles are easy to create.

Also, no special code is required. Truth is, the tile driver operates at 320 pixels. So then, all that is needed is to just stack up some tiles with the patterns, and then vary the driver resolution.

On the VGA one, assuming we can get 320 pixels or so for the tiles, the same would be true, only the VGA would always show the intended color, as it has more than enough bandwidth to handle low pixel rates.

Instead of trying to pack it into one tile, just think pixels, then stack up the tiles to equal that many pixels. In this case, for the 12x8 pixel test, it's only necessary to just build up three sequential tiles.

The "max" resolution for TV's varies. The numbers I gave are good rules of thumb, though TV's really don't have pixels, I judge it by how much of the pixel I can see. If most of the pixel is rendered as intended, with only a small amount of not intended visual information present, that's a "pixel", and it counts toward "resolution". As that ratio changes, then it's exceeding the "resolution", and adjustments to the size of the image, or it's color / luma composition might be warranted.

A great example of this is your TV newscast. They operate with very well chosen color sets, so that the transitions are modest, making the graphics appear sharp, even though resolution is somewhat limited. You can see this in sports graphics often as well. Say there is a blue background. They might sprinkle in little bluish yellow, or white, or light blue pixels in there, or even text, and it will look sharp, where if they had put red text in there, it wouldn't, because of the color limits.

I'll do some captures that show off some of this stuff, and the signal options possible with this TV COG. It can run color, luma only (mono), interlaced, and not interlaced, and each has it's uses for graphics and overall screen quality trade-offs.

So the "max" resolution then, with a TV, is the native pixel resolution of the driver, minus the artifacts that occur with a composite signal. That's why S-video looks better. The signals are separated, kind of like VGA, but not as separate as VGA is.

If we were to do a component TV COG, then it would look about like a VGA does, because the signals would have a lot more bandwidth. That takes three COGs on a Prop though, which is why it's never been done. S-video can be done with one COG, because that's built into the Prop capability.

I think Bill has the only S-video board.

One other thing. If you want monochrome images, the composite TV output can be fed into the luma input of a TV with a S-video connection. This results in a very nice, up to 640 pixel, monochrome display! I often run my TV graphics this way, when I want detail. I'll capture that too.

The one thing I've not captured is S-video running right off the prop. My gear is composite (RCA) only, though my displays are S-video capable. None of my boards are, but it's easy to wire that up.

I think the Audio resistor, which is currently unused by all but Eric Ball's special sprite driver, goes unused. When the Prop is configured for S-Video, color is output on that pin. I think any board that has all four resistors can be modded for S-video output because of that, with only a code change in the driver to turn it on. That should go on the "to-do" list for the TV COG. I've always skipped it, because most of the Propeller displays are either at a low resolution, or are color limited, which largely avoids this whole discussion. Potatotext is the only thing I wrote, until now, that pushed it at all, and it's display was fine with the RCA, so I never built the S-video capable interface.

(done now, sorry... that topic is never short)

Re: VGA & tiny tiles. Probably. I think 320 pixels can be done. Going above that might require more than one COG. Don't know until I tear into a driver.

320 pixels is going to look nice, but with clearly defined pixels on VGA. If the color clashes are not bad, TV will actually smooth that, looking better, IMHO. Depends on whether one needs to see the shape of the pixels, or "the image".

Dr_Acula
11-16-2010, 08:55 AM
I haven't tested my TV yet but will do this.

I spent a few hours today soldering up a board for you and loading up an sd card with binary programs. It boots into kyedos, and you can run other binaries from there - eg pacman is on there in "full blocky color" (my son cleared several levels). It even has sound if you connect up a speaker to one of the prop pins. The main function of the board is to show the concept of loading and reloading binary files on the fly from an sd card. So you don't have to try to fit everything into one spin program (which means that each spin program can be small, which means more room for graphics buffers).

That post above is chock full of all sorts of useful information.

So if I understand right, a small TV could kind of be considered to have about 160 pixels? So if you had, say, 64x64 pixel icons, you could fit 4 of these on a little TV screen with some black around them and that could be the start menu.

Easily would fit in hub ram.

Load in new pixels for sub menus.

For VGA it will be very different. Four 64x64 icons will sit in the middle of the screen. But that is ok - it will still have the same 'look and feel', and maybe it could be the beginnings of a graphical operating system? You could have an icon for "date and time", and one could be some gears which means "operating system options" with boring things like screen settings and file transfers, and one could be a folder that brings up sub menus of binary programs. There are already binary files that spawn other binary files eg, I boot into kydos, then run catalyst to then run compiled catalina programs. It is a lot of tedious typeing though and icons would make the process much more intuitive.

If you reckon the TV icons are working (yes, we will need a converter program) then is vga going to be possible - maybe using a variant on Ariba's code?

Baggers
11-16-2010, 09:43 AM
Hi all, sorry I've been ultra quiet of late, but been busy with finding and doing paying work, but anyway, just to let you know what I've been working on in what little prop time I have, since Potatohead is doing this for TV.
It's a VGA driver that will do 256x192 any pixel colour using scanlines, like the TV drivers that have been used to make games. ( at 6Mhz it will do 320x240, but I'm trying to optimize to run on a 5Mhz crystal )
Will show pics soon, followed by release ;)

JT Cook
11-16-2010, 01:14 PM
Hi all, sorry I've been ultra quiet of late, but been busy with finding and doing paying work, but anyway, just to let you know what I've been working on in what little prop time I have, since Potatohead is doing this for TV.
It's a VGA driver that will do 256x192 any pixel colour using scanlines, like the TV drivers that have been used to make games. ( at 6Mhz it will do 320x240, but I'm trying to optimize to run on a 5Mhz crystal )
Will show pics soon, followed by release ;)

That would be awesome! I have been wanting a driver like that for a long time. I even tried it myself a while back, but with no success (tho I think I only gave it a couple of days of trying). I may have to plug this into the new game I am working on ;) Also what is the actual resolution that is being pushed out to the VGA monitor?

Keep us updated!

Baggers
11-16-2010, 02:57 PM
it was based on the 640x240 @69Hz timings

potatohead
11-16-2010, 06:15 PM
SWEET!!

(the message you entered is too short. Please lengthen to 10 characters.)

ericball
11-16-2010, 07:52 PM
Re: color table
The table I provided is from the capture potatohead did from my TV.spin colorgrid. There are formulas to convert from "TV color" (aka YIQ, YUV, YPrPb) to RGB, but there's as much bad info out there as good info. Again, "TV color" to RGB is a simple lookup table, but getting good results for the reverse will be a challenge, especially with only 134 colors.

Re: resolution
For composite video the color difference (R-Y and B-Y) signals are quadrature modulated at 3.5795MHz (227.5 cycles per line, or ~160 active pixels). At 320 active pixels any luma transitions get demodulated as color signals (unless the colorburst is disabled, then you just get black & white). 240 active pixels is around the max resolution before color aliasing becomes significant. S-video keeps the luma and chroma separated so you can generate 320 active pixels, but you lose the Propeller high saturation colors.

Re: Aural sub
Both my 240H sprite driver and "better TV color" driver use the aural sub pin (but in different ways).

Dr_Acula
11-17-2010, 05:43 AM
I know VGA better so here is a documentation of how to create icons:
1) Find some images
2) Do a screen capture with paint shop
3) Do copy/paste and size to 64x64 pixels
4) Paintfill the outside with black if it is white or another color.
5) Colors/Load Palatte and load the VGA 64 color palatte. Changes to these colors
6) Colors and increase the depth to 24 bit (makes the maths easier below)
7) Save as a RAW file (raw binary data, 3 bytes per pixel, no headers)
8) Run a tiny vb.net program


Private Sub Button92_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button92.Click
Dim b As Byte
Dim i As Long
Dim j As Byte
Dim k As Long
Dim Bitmap(12287) As Byte ' 64*64*3
Dim Output(4095) As Byte
Dim BinaryInput As New BinaryReader(File.Open("c:\" + TextBox46.Text, FileMode.Open))
Dim BinaryOutput As New BinaryWriter(File.Create("c:\" + TextBox47.Text, FileMode.Open))
For i = 0 To 12287
Bitmap(i) = BinaryInput.ReadByte
Next
j = 0
' propeller format is RRGGBBxx
For i = 0 To 4095
b = Bitmap(i * 3)
j = 0
If b = 0 Then j = j + 0 ' 00 red
If b = 85 Then j = j + 64 ' 01
If b = 170 Then j = j + 128 ' 10
If b = 255 Then j = j + 192 ' 11
b = Bitmap(i * 3 + 1)
If b = 0 Then j = j + 0 ' 00 green
If b = 85 Then j = j + 16 ' 01
If b = 170 Then j = j + 32 ' 10
If b = 255 Then j = j + 48 ' 11
b = Bitmap(i * 3 + 2)
If b Then j = j + 0 ' 00 blue
If b = 85 Then j = j + 4 ' 01
If b = 170 Then j = j + 8 ' 10
If b = 255 Then j = j + 12 ' 11
Output(i) = j ' store value
Next
For i = 0 To 4095
BinaryOutput.Write(Output(i))
Next
BinaryInput.Close()
BinaryOutput.Close()
MsgBox("Done")
End Sub


9) save as a name ending in .ico (they are actually binary files so rename as .bin to view)
10) Copy file to sd card
11) Run the attached spin code (a hybrid of Ariba's screen driver and Kye's sd card, with behind the scenes debugging using the VT100 VGA driver)

I think the Prop is ready for graphics!

So, next little thing -

a) getting Ariba's code to work so the pixels are smaller (same hub ram, most of screen is black)
b) translating these .ico files into TV

Is there a simple table that converts the 64 vga colors into the nearest TV color?

Failing that, a table for RGB to TV colors. (In some ways it would be better to start with the 24bit original file rather than the one that has been reduced to 64 bits).

This operating system is called PotatoDOS.

Tubular
11-17-2010, 06:13 AM
Just starting to read through this thread and its relatives. Lots of good stuff going on here.

Quick question; How many grey scales are possible using the techniques outlined so far, for TV out (either NTSC or PAL) ? Are we still limited to 6 levels, or can they be blended to make 11 levels, or more?

thanks
Tubular

potatohead
11-17-2010, 06:47 AM
Only 6 levels. To get more, a different DAC is needed. Existing code would not be difficult to modify, given more resistors. That is what yields the levels on the Propeller for TV. We had a thread once about using 8 resistors to yield something on the order of 160 or so grey scale levels, after subtracting the ranges of values needed for sync. A non-linear DAC might yield more.

@Dr_A: Easiest path is probably just to capture the RGB values, and go that route. When I get to my prop computer, I'll post up something that relates to the color table, adjusted for safe display values. I think the one in use on this thread is a little bit liberal. (A few of the lower intensity values may not display.) The latest Potatotext has a solid table. Need to double check.

Next steps for me is to go from a byte to word on tile addresses. Easy mod for the TV driver running right now. Then, start on VGA. Either one gets converted to scan-line capability, or Baggers scan-line type driver will work, which ever comes first!

His results indicate we are gonna get 320 pixels on a dual cog driver, so the truth is, the drivers will just about match up. Vertical resolution on the TV is 200, VGA a bit more, with horizontal resolutions matching up nicely at 320, or 160, maybe 256/224.

**Almost seems to me, with some creative work, SPIN could process images like VB can. Just a thought. We can open big files now, and it just occurred to me that kind of thing is now possible.

Dr_Acula
11-17-2010, 09:27 AM
All very encouraging!

320 pixels divide by 64 with gaps will give 4 icons, times however many rows. The program space to display these and process them will take a bit of space. The one posted above is about 4k of program space, though this could be less if you use BST and eliminate unused spin methods. There will need to be a mouse driver as well, but actually, the code needed to put a few icons on the screen and a mouse and work out which one has been clicked is not going to be very big. Mabye 6 or 8k?? So lots of room for display buffers.

If you make the icons always 64x64, and use a color depth of 24 bits, and save as a RAW image, it is always 64x64x3 bytes long.

Processing that on the propeller could be quite possible. Might even be better given some people don't have vb.net. Only need to do it once to convert a 12k raw image to a 4k .ico (binary) file. Could do that as a spin file compiled to a binary with vt100 drivers and the local keyboard. You could run that from kyedos, and when this is working, run it from PotatoDOS. That starts to get into the spirit of having an operating system that you run files from. The smaller the files, the quicker they load too.

I'm thinking about the formula if you do a conversion from 24 bit to TV colors. eg, say you had 4 shades of gray like the VGA is, with transitions at 85, 170 and 255. Then the break points divide 255 into 4 parts. So 0-63 maps to 0, 64 to 127 maps to 85, 128 to 191 maps to 170 and 192 to 255 maps to 255. Actually, even that is not quite correct as there is not equal weighting for the colors.

At the moment I'm letting paintshop work out the closest colors but for TV, the program is going to have to work this out.

If you wanted to run "Icon Builder for TV and VGA", click the attached icon? For a spin program, it could produce both files, maybe instead of calling them .ico you call them .tv and .vga, and depending on the display you pick the one to display. Then you only have to build icons once.

I'm amazed at the colors you can get even with only 64 colors. TV is going to look even better at 96. And like you say, the blurring you get with TV will probably improve the look.

ericball
11-17-2010, 01:40 PM
Only 6 levels. To get more, a different DAC is needed. Existing code would not be difficult to modify, given more resistors. That is what yields the levels on the Propeller for TV. We had a thread once about using 8 resistors to yield something on the order of 160 or so grey scale levels, after subtracting the ranges of values needed for sync. A non-linear DAC might yield more.

Note: Six grey levels is what the Propeller composite video generator can do. Three bits = three pins = three resistors = eight output levels = 2 sync levels + 6 grey. With my "better TV color" driver the aural sub pin is used to push the sync levels up to give a 7th grey (and a second black), but that's about it. To get more greys you'd need to either drive the pins in VGA mode as one big DAC for greyscale only output. Or you'd need to sync two cogs so one produces the normal 6 greys and a second would add additional LSBs. The disadvantage with both schemes is 1. requires a non-standard board and 2. uses more pins.

Oldbitcollector (Jeff)
11-17-2010, 03:02 PM
Only 6 levels. To get more, a different DAC is needed. Existing code would not be difficult to modify, given more resistors. That is what yields the levels on the Propeller for TV. We had a thread once about using 8 resistors to yield something on the order of 160 or so grey scale levels, after subtracting the ranges of values needed for sync. A non-linear DAC might yield more.

Does this translate into more colors if we would be willing to use a non-standard video circuit? Sounds like win here.

OBC

potatohead
11-17-2010, 03:29 PM
I'm curious to hear Eric's reply.

Yes. I see it breaking down two ways. If we run the Prop in TV mode, we get the same hues, but more shades, if there are more resistors.

If we run in VGA mode, TV drivers get more complex, but there would be more of both. Eric wrote one of these, and it's complex, and timing dependent. Pixel sizes won't vary like they can now, but the picture would be great. Dual COG driver solutions would be needed, because of the need to drive color in software.

RAM still is at issue though, which is why I never did much personally. Fleshing out byte per pixel to something closer to 256 colors would be good, because we do that now. Going higher seems impractical because resolution would have to be low because of RAM.

ericball
11-17-2010, 04:34 PM
Does this translate into more colors if we would be willing to use a non-standard video circuit? Sounds like win here.

Let's back up here and see what we have to work with.

On the Propeller side the main limitation is around the WAITVID instruction, which allows 4-16 pixels (at 4 colors) to be output with a single instruction. Driving OUTA directly is too slow. The video generator has two color formats: composite (4 bit PSK/hue, 1 bit color enable, 3 bit luma driving 3 pins) and VGA (8 bits which are sent directly to the pins).

On the TV side, the composite input expects a luma signal with color difference signals quadrature modulated at the colorburst frequency. Luma is easy, that's just a time-varying signal. The color signal is the hard bit.

My 240H sprite driver has a larger color gamut because it drives the 4 pins (3 pin TV DAC + aural sub) at 4 times the colorburst frequency, which gives full control over the color difference signals. But that means performing 1 WAITVID per pixel - so the pixels are stored in cog RAM and multiple cogs are required.

One way to generate more colors would be to have two synchronized cogs with two 3 or 4 pin DACs. One cog would generate the "MSB" the other the "LSB".

On the other hand, if you want "VGA color" output, I know there are RGB to TV chips. It may be easier to simply use those.

I guess my question is what's the target? Most Prop users usually get excited about solutions which use fewer pins, fewer cogs and less RAM - not more.

Dr_Acula
11-17-2010, 10:37 PM
I guess my question is what's the target? Most Prop users usually get excited about solutions which use fewer pins, fewer cogs and less RAM - not more.

Re pins - everything is a compromise, but for the boards I'm using, the top 8 do serial ports/mouse/keyboard/I2C, then next 8 down do VGA, the next 4 down do SD card and there are 12 pins free.

So if you are using 8 pins for VGA, you could use those 8 pins for TV too. That makes the color depth more, right?

Re cogs, this particular demonstration is for an operating system that is capable of loading new compiled binary files off the sd card. So the OS uses one cog for the spin interpreter, one for the SD card driver, and there will be one which will probably be a combo mouse/keyboard. So that leaves 5 cogs free for display drivers.

Re ram, I think there is about 24k free. Again, this would be used in an operating system that then loads new programs. The OS itself will be doing very simple things - detecting mouse clicks, key presses and loading pictures off the sd card. Then loading binary files and running them (Kyedos does all this in 'text mode' so this is just the graphical equivalent.)

So - lots of ram, pins are a compromise but there are 12 free, and up to 5 cogs.

This is for a tile driver in an OS. Of course, once you have such a thing, it can be used in other ways. I'd be thinking of Catalina running in external memory, which can be 512k in size for sram, or 32mb in size on jazzed's board. That also frees up virtually all the hub ram (all but the top 2k). And the ability to load cogs from within catalina, so you could do clever things like temporarily blank the screen while you load those cogs with other cog code.

I think this means you have a lot of hub ram to use.

I've been playing around with what we can fit on the screen. If you have one byte per pixel, by my maths 160x120=19200 bytes. If icons are 64x64, then you get four on a screen. If two are arrows, then clicking each arrow moves a list of icons along. That could be useful.

You could do more cunning things, eg if each icon is 64x64, that is 4096 bytes, so you could fit six into hub memory as long as the display driver put in some blank lines in between each icon.

I'd be inclined to stick with simple standard drivers for the moment.

Ariba's driver is 128x96 - which can only fit two icons side by side.

You could shrink the icons but they lose some resolution.

So a question to ask would be whether this driver can be recoded for 160x120, and if so, can it also be recoded so the pixels are smaller and the display ends up in the middle of the screen?

The attached file is 160x120 with propeller VGA colors.

Kye
11-18-2010, 12:05 AM
Hey, I found that I have time to make a driver for this on friday. Should be able to roll out something nice for use by the morning.

Thanks,

(I'm just gonna take my bitmap driver and modify it.)

Dr_Acula
11-18-2010, 12:42 AM
Kye, that sounds great!

More experiments. Start with what we have and then it can grow. So - this is using the full 12k of Ariba's driver, with Kye's sd card interface.

Attached is a photo of the screen. This could be the beginnings of an operating system - click the arrows and the icons scroll along. Click the icon and it runs that binary. Or use the keyboard arrow keys and Enter. Maybe the 'active' icon is the top left one? Or maybe draw a border round it in software?

Ariba's screen is 128x96, so for four icons that would make each icon 64x48.

ericball
11-18-2010, 02:09 AM
So if you are using 8 pins for VGA, you could use those 8 pins for TV too. That makes the color depth more, right?
Sorry, no. VGA has 5 outputs: 2 pins each R G & B, 1 pin each H & V. So to reuse those pins for TV you'd need some kind of external 8:16 demux to select a different set of resistors to make a single composite output. So if you have the pins to burn, better to simply dedicate 3 pins to a normal TV DAC.

Hmm.. I wonder whether there's enough time & space in the driver to do a lookup. Encode the icons with a color value then do a lookup for the equivalent VGA or TV bytecode.

Dr_Acula
11-18-2010, 02:17 AM
I was going to produce two files - one with the vga bytes and one with the tv bytes.

Re changing between TV and VGA using the same pins - could you do that with some headers? Even if it was up to 16 headers?

ericball
11-18-2010, 02:23 AM
I was going to produce two files - one with the vga bytes and one with the tv bytes.
Probably the easiest way. Pre-process so the cog only has to fetch a long from HUB RAM.


Re changing between TV and VGA using the same pins - could you do that with some headers? Even if it was up to 16 headers?
Sure. You just need some way select which resistor network and output connector to use. You could use a 3x8 header and 8 jumpers. Or use one of the existing daughterboard connectors.

Dr_Acula
11-18-2010, 01:06 PM
Attached is a little experiment with a smaller icon. This is the propeller icon resized to 32x24 and reduced to the 64 vga colors. Then placed in a 128x96 black display to give an idea of the scale. With smaller icons like this, one could fit 4x4=16 icons on a screen using code we have now.

If you had icons 32x32 then you would fit 4x3=12 icons in a screen.

I think the windows default in XP is 32x32.

potatohead
11-18-2010, 07:35 PM
One big problem with the tiles as currently implemented is their addressing. It sucks, because the images need to be broken into little pieces, then re-assembled on screen. I was building the TV test pattern tiles I said I was going to capture, and it's laborious with 4 pixel, sequentially addressed tiles.

Two changes coming:

1. Word tile addressing. That's easy, because 8K of tile data doesn't allow the Prop to be fully exploited, and the extra bits in the words might open the door for text tricks. Not sure on that, but it's a option.

2. Address change.

Right now, the tiles are 4x8, and they live as sequential longs in the RAM. That's the trouble.

I'm going to change it so that the addresses are non-sequential, so that larger images can be loaded into RAM directly, not in pieces. I'm thinking about 32 or 64 pixel x say 32 pixel chunks. That way, one larger icon can be developed to be used as a whole, or in pieces, avoiding most of the tile building work.

What this means is somebody could use a graphics program, and define a 32x32 bitmap, or maybe a bigger one horizontally, and just paste things into it. If that is saved as GIF, with a one byte palette associated with TV or VGA, then the resulting file can be used directly, included into the project as a "file: tile1.gif", then placed on screen by simply calling out the tile addresses in the screen array. This will make producing graphics viable, with only the matter of either avoiding, or stripping the header off the graphics file being needed to get the images to a useful state. For "pieces", it's pretty great too, because the source bitmap can just be considered a grid, containing lots of tiles. Paste in, or draw the desired goodies, and load, and display on screen by tile number. A simple chart can make this workable.

That's where I'm headed next, as that can be used on any tile driver that ends up getting written, VGA and TV.

Not sure where Baggers is with VGA scan-line drivers, but I'll give that a go this weekend. No time until then. The existing drivers look favorable for 256 pixels at least, and we know Baggers got 320, so I think that's just a code and timing exercise to connect a graphics cog to a modified VGA driver signal cog. He is using the lower VGA timing, which makes the drivers more or less match up. 320 pixels is the target horizontal resolution. Enough for graphics detail that will more than satisfy this "let's do cool icons" project :) Their placement and size on screen will be able to vary considerably with the new tile addressing, with a lot less grunt work or code being required to format the data in a way that makes sense to the Propeller graphics COG.

(or render COG to a graphics COG, if that lingo makes any more sense)

There is not enough compute time in a single COG to do tiles in this way at higher resolutions. Bitmap only. A highly specialized bitmap COG could possibly accomplish the "put a tiny bit in the middle of the screen" task, but honestly, if that's to be written, we might as well get the tiles right, and easier to use on VGA and TV, so that lots of different graphics are possible. The prep work will be modest with the addressing changes.

Aside from that, bitmaps are really easy!! However, it's not really possible to exploit the Propeller fully using them alone. There isn't enough HUB memory, meaning we need to populate the blank areas with as little as possible, focusing the data on the non-blank areas, and ideally allow for positioning. That means either sprites or tiles, and for this work, tiles are nearly done, so I'll do tiles. Maybe we can add sprites, with a third COG. Could do a pointer, or something with a few of those, and a few per line will be possible with a third COG. That will mean one signal COG, one tile or bitmap render COG, and one potential render sprites COG. Truth is, only a sprite COG could be running as well, if one didn't care about the tiles. I'll build my stuff that way, so that door is open.

More from me soon, when I get the work grind behind me :)

Kye
11-18-2010, 09:38 PM
Just finished rolling a 160x120 6-bits per pixel driver. I need to finish a demo and finish polishing the code and I'll post it to the OBEX.

Its very colorful!!! I should have it up by tonight!

potatohead
11-18-2010, 10:00 PM
Awesome!! is it scan-line, or bitmap?

Dr_Acula
11-18-2010, 11:14 PM
This all sounds fascinating. I'm still digesting potatohead's post - there are some complicated concepts in there.

Re file formats, I have not looked at .gif recently. .bmp is simply rgb bytes and there is a header at the beginning which has the file size and a few other things. I've been using .raw which is .bmp without the header.

Ariba's code has an array pixel[] in the main, and at the beginning you tell the vga cog where pixel[] starts, so from then on you just read things into the pixel array at the right place. For a 32x32 array at an arbitrary position x,y, there is a little bit of maths involved - r*128+c and then put in 32 bytes, then add 128-32 for the next position. I'll see if I can turn that into a pub where you pass the filename and the x,y position and the filesize.

If one considers special cog code that uses tiles, one could have a tile that is all black, and then have something like icon,blacktile,blacktile,blacktile,icon and one could potentially have something that has n icons at the proper small size in arbitrary positions on the screen. 32x32 icons are 1024 bytes, so maybe 20 of those. 64x64 icons are 4k. And then the data for one black tile.

Creating icons does take a bit of artistic work in paintshop - capturing, resizing, decreasing the color depth etc. It probably is not possible to automate this completely. Things work better in a certain order too - eg resize before decreasing the color depth.

Looking forward to seeing your code, Kye!

Kye
11-18-2010, 11:39 PM
Its a bitmap, and uses more than half your memory. But, it gives you the colors.

As for a scanline driver... not possible for VGA. I say this because if I can't fit the code in the video loop to figure out how to translate a tile map... making another cog do so won't give me anymore time.

And believe me. My tile map driver PUSHED the propeller chip to the limit. I have expierence with this stuff in VGA. If you try doing this scanline by scan line you won't have enough time.

Since TV goes at a lower frequency a scanline buffer is possible.

Dr_Acula
11-18-2010, 11:44 PM
Its a bitmap, and uses more than half your memory. But, it gives you the colors.

Sounds fantastic. No problem using half the memory. Indeed, I think one could probably use more - at least up to 20k.

Just a thought. Say you had a 640x480 vga screen. And say you had tiles 32x32. Say you can 20 of these in memory making 20480 bytes.

For arguments sake, tile 1 is black (but it could be any color really) and all the other tiles are icons.

Then you have a tile list. 640x32 is 20, and 480/32 is 15. So you have 300 bytes storing numbers 1 to 20.

Then you print them out eg tile 1,tile 1, tile 10, tile 1, tile 1, tile 1, tile 15 etc

Every 32 bytes on a scan line you need to load in the next tile number and change a pointer to a new location in hub ram. So you do that 20 times on a scan line of 640.

Do you think a vga driver would be fast enough to add this extra code (eg a 2 cog driver)?

potatohead
11-19-2010, 12:55 AM
Dr_A, that's very close to the change I mentioned above.

Kye
11-19-2010, 01:09 AM
Here's what I've made. I don't plan on working any harder. While two cog VGA solutions give better results I do not wish to make one.

I'll put this driver up in the OBEX.

(Edit - Its now in the OBEX http://obex.parallax.com/objects/686/)

Dr_Acula
11-19-2010, 01:20 AM
That looks good Kye. 160x120 will give enough 64x64 icons and more than enough 32x32. Can't wait to get home and try this.

Re potatohead - so you are working on a big full color tile driver? My father in law likes to run his PC with a black background, so with tile driver code and 20 icons, it could look rather similar to a PC home screen, or an ipad. That would be a propeller OS that would be 'familiar'.

Thinking of icons, there are times you want small ones and times you want bigger ones. I'm thinking of taking a 64x64 bitmap with the original 24 bit color and using this to produce a 64x64, 32x32 and a 16x16 in prop colors, both TV and VGA.

potatohead
11-19-2010, 01:29 AM
Yes. It will still be a lot of little tiles, but...

If the addressing of the pixels is done correctly, 16x16 bitmaps can be loaded directly into the Propeller, maybe 32x32, whatever size works out in code.

Then, when placing them on the screen, one can choose any origin tile location, within 4 pixels, allowing for placement anywhere within reason.

Because it's tiles, the 320 pixels can be used, as not all the HUB memory will be consumed.

Baggers has 320 on VGA, so I'm hoping those can be matched up for a nice "all-color" solution. However, I'll probably take what Kye did, and see what may be built from there.

On the next pass at this code, I'll post up some detail info on tiles that should clear up how things can work. People have the same general trouble with the Parallax driver, and so that info probably will be of good general use.

It's my intent for the icons to be placed in various places, duplicated on screen, etc... without just having to do a full on bitmap of the entire screen.

Dr_Acula
11-19-2010, 01:38 AM
It's my intent for the icons to be placed in various places, duplicated on screen, etc... without just having to do a full on bitmap of the entire screen.

That sounds brilliant.

16,32 and 64 seem to divide well into the screen sizes. I'm thinking in terms of icons at the moment, but one could always take a number of icons and put them next to each other for a bigger picture. So you could click on an icon of a photo, and then bring up a 128x128 picture or maybe even bigger.

Some of that could be built on the fly. Eg click on an icon of a clock, and it shuts down the operating system and runs a new binary that reads the time and displays it on a nice 128x128 clock, that you build up in software. You could even have the clock face as a bitmap and then draw the hands on in software. Then when you shut that down it reloads the operating system binary.

Intriguing possibilities...

potatohead
11-19-2010, 04:39 AM
Exactly! That was where my mind went when you first started musing about this idea.

Dr_Acula
11-20-2010, 12:46 AM
Testing out Kye's driver. Lots of manual steps with paintshop to get here. Once we have an OS working, one little App that might be useful is to be able to convert a .bmp into a .tv and .vga picture.

Abstract art and cartoons compress to propeller colors a lot better than photos.

I started a new thread for the eye candy.

Meanwhile, Icons.zip goes on the sd card, PotatoDOS gets compiled to the eeprom, and Photo.spin gets turned into a .bin file and goes on the sd card.

There are some bugs - if just one picture or icon file is missing the whole thing crashes. And it is slow to load pictures but I can think of several ways to overcome that.

Kye might have some advice, as this is the Kye SD code talking to the Kye 160x120 video driver code.

potatohead
11-20-2010, 07:37 AM
A incremental update.

This archive does WORD addressing for the tile indexes. It's capable of using all the HUB memory for tile displays.

All tiles are 4x8 sequentially addressed, that change to the bitmap friendly tile addresses is next.

Right now the tile addressing is still sequential. If you run the archive, I've defined a few black and white tiles for resolution tests. Nothing special, but useful for looking at how a tile works, and seeing the graphics product on screen.

The next address change will be to arrange tiles in a grid of 16x32, or 32x32, or something that makes sense code wise, so that images may be made that size, and put directly to use by this driver, using "tile sets" of sequentially numbered 4x4 tiles to draw the image anywhere on the screen.

At that point, several images can exist in the HUB, and placed on the screen with very little effort. That's possible now, but requires work to "stack" the 4x8 pieces into the right places on screen.

VGA scan line type, driver coming up next, along with some actual image tile data and a document explaining how things end up in the HUB RAM.

@Dr_A: Very cool to see those on the Prop! Nice conversions.

jazzed
11-20-2010, 04:53 PM
So I made a fat, beveled, grey scale "OK button" for a boring old GUI.
With the fat pixels I have to use 6 tiles. Are thin pixels impossible ?




{
'--------------------------------------------
' draw a fat letter OK button

TEXT.SetTile(0,1,8) ' upper left
TEXT.SetTile(1,1,10) ' upper middle
TEXT.SetTile(2,1,12) ' upper right
TEXT.SetTile(0,2,9) ' lower left
TEXT.SetTile(1,2,11) ' lower middle
TEXT.SetTile(2,2,13) ' lower right
'
'--------------------------------------------
}

long $06060606 '00_08 upper left
long $06060606
long $06050505
long $06050202
long $06050205
long $06050205
long $06050205
long $06050205

long $06050205 '00_09 lower left
long $06050205
long $06050205
long $06050205
long $06050202
long $06050505
long $05040404
long $04040404

long $06060606 '00_10 upper middle
long $06060606
long $05050505
long $02020502
long $05020502
long $05020502
long $05020502
long $05020502

long $05020502 '00_11 lower middle
long $05020502
long $05020502
long $05020502
long $02020502
long $05050505
long $04040404
long $04040404

long $06060606 '00_12 upper right
long $06060604
long $05050504
long $05020504
long $05020504
long $05020504
long $02040504
long $02050504

long $02050504 '00_13 lower right
long $04020504
long $05020504
long $05020504
long $05020504
long $05050504
long $04040404
long $04040404

Baggers
11-20-2010, 06:21 PM
Jazzed, thin pixels are going to be possible on my VGA driver.
( Potatohead, it's 256 pixels wide, as couldn't get 320 at 5Mhz especially with sync correction oring $03030303 )

64 * 30 * 4x8 chars

will be posting demo of it in a mo.

jazzed
11-20-2010, 06:45 PM
Sounds great Baggers! I'll try that on my lovely new VGA module which has megabytes of goodies and other "connected" things :D

Meanwhile, here's a yellow on blue fat pixel 3D shaded OK button.



{
'--------------------------------------------
' draw a 3D shaded fat letter OK button

TEXT.SetTile(0,1,14) ' upper left
TEXT.SetTile(1,1,16) ' upper middle
TEXT.SetTile(2,1,18) ' upper right
TEXT.SetTile(0,2,15) ' lower left
TEXT.SetTile(1,2,17) ' lower middle
TEXT.SetTile(2,2,19) ' lower right
'
'--------------------------------------------
}

long $eaeaeaea '00_14 upper left
long $eaeaeaea
long $eaeaeaea
long $fbfb7e7e
long $fbfb7efb
long $fbfb7efb
long $fcfc7efc
long $fcfc7efc

long $fcfc7efc '00_15 lower left
long $fbfb7efb
long $fbfb7efb
long $fbfb7efb
long $fbfb7e7e
long $eaeaeaea
long $eaeaeaea
long $eaeaeaea

long $eaeaeaea '00_16 upper middle
long $eaeaeaea
long $eaeaeaea
long $7e7efb7e
long $fb7efb7e
long $fb7efb7e
long $fc7efc7e
long $fc7efc7e

long $fc7efc7e '00_17 lower middle
long $fb7efb7e
long $fb7efb7e
long $fb7efb7e
long $7e7efb7e
long $eaeaeaea
long $eaeaeaea
long $eaeaeaea

long $eaeaeada '00_18 upper right
long $eaeaeada
long $eaeaeaea
long $fb7efbfb
long $fb7efbfb
long $fb7efbfb
long $7eeafcfb
long $7efcfcfc

long $7efcfcfb '00_19 lower right
long $ea7efbfb
long $fb7efbfb
long $fb7efbfb
long $fb7efbfb
long $eaeaeaea
long $eaeaeada
long $eaeaeada

potatohead
11-20-2010, 07:21 PM
Jazzed, Just enter the demo program and change the number of pixels from the large size to 160, 256, or 320.

I left it set to 80, because I debug in 80. I like to see the pixels clearly when dealing with the graphics cog. Was out really late at work last night, dealing with a network address change. Lots of little confused devices not talking to one another. I hooked up a prop to kill time while waiting for things to reboot, and archives to get written!

@Baggers, yeah, I toyed with the code already posted, and having to set the pixel clock explicitly adds just one more instruction. Still, 256, is excellent!!

(hard to see 320 on TV's, unless one picks colors very well)

So, they match up nicely pixel wise. I gotta get the next addressing piece done, so I can do bitmaps and have some real tile data!)

Eager to see how Baggers did his tile addressing :)

Baggers
11-20-2010, 07:51 PM
potatohead, can you go on msn for a bit?

jazzed
11-20-2010, 07:52 PM
Jazzed, Just enter the demo program and change the number of pixels from the large size to 160, 256, or 320.
Eggscellent :) Now we're cooking. Guess I'll be using more tiles.
How much HUB buffer memory is used for each of the widths?

potatohead
11-20-2010, 08:20 PM
Well, each tile is 4x8, which is just 8 longs. All you need to do is calculate the number of tiles addresses needed to cover the screen:

320/8 = 40*2 = 80 bytes * 25 rows (200 lines / 8 pixels) = 2000 bytes for the tile addresses on screen. That's a sunk cost, unavoidable.

Each tile then is 32 bytes.

To display a blank screen, you just need 2032 bytes!

If you add a tile, it's 32 bytes. Your RAM consumption then depends on the tiles you define, and how much you can leverage shared tiles. There is essentially no cost for populating a tile on the screen, which is why this method of graphics data encoding works well at higher resolutions.

jazzed
11-20-2010, 08:32 PM
I can live with that cost. What I have trouble with is not having access to the pre-defined characters in the ROM which are also bit-maps. Too bad we can't use pointers for that.

Thanks.

Here is a nice beveled OK button. Using 4 instead of 5 for button face could be useful. I suppose one could do a byte replacement as needed at run-time.




{
'--------------------------------------------
' Draw an 8 tile beveled OK button.
' Looks good at 120+ width screen

TEXT.SetTile(0,1,8)
TEXT.SetTile(1,1,10)
TEXT.SetTile(2,1,12)
TEXT.SetTile(3,1,14)
TEXT.SetTile(0,2,9)
TEXT.SetTile(1,2,11)
TEXT.SetTile(2,2,13)
TEXT.SetTile(3,2,15)
}

long $06060606 '00_08 upper left
long $06060606
long $06050505
long $06050505
long $06050503
long $06050502
long $06050502
long $06050502

long $06050502 '00_09 lower left
long $06050502
long $06050502
long $06050503
long $06050505
long $06050505
long $05040404
long $04040404

long $06060606 '00_10 upper mid1
long $06060606
long $05050505
long $02020205
long $04050403
long $05050502
long $05050502
long $05050502

long $05050502 '00_11 lower mid1
long $05050502
long $05050502
long $04050403
long $02020205
long $05050505
long $04040404
long $04040404

long $06060606 '00_12 upper mid2
long $06060606
long $05050505
long $05020505
long $05020504
long $05020502
long $05020204
long $05020204

long $05020402 '00_13 lower mid2
long $05020402
long $05020503
long $05020505
long $05020505
long $05050505
long $04040404
long $04040404

long $06060606 '00_14 upper right
long $06060604
long $05050504
long $02050504
long $02050504
long $04050504
long $05050504
long $05050504

long $05050504 '00_15 lower right
long $04050504
long $03050504
long $02050504
long $02050504
long $05050504
long $04040404
long $04040404

{
'--------------------------------------------
}

potatohead
11-20-2010, 08:44 PM
Yeah, Jazzed. Can't happen at high color. Too many shifts and adds. Would take several COGs.

Really, you can do that with 4 color tiles. That's what the Parallax driver does. You could also do it in 4 color, with a 2K font, designed that way, with any 4 colors per tile... That driver can be written quickly. May do it, once I'm done with Dr_A, and this VGA / TV graphics bit.

I want to see his icon deal happen :) IMHO, it's a cool idea.

Re: runtime. YES! If you want to, you can always be building into tiles off screen, encoding that stuff in a smaller way, using SPIN, or PASM to build the tile, then pop it on screen. A whole lot can be done that way. Recommended, IMHO.

If you want to, you can bit-mash the ROM font, into tiles, then display them as needed. When done, recycle the tiles and display something else!

jazzed
11-20-2010, 09:20 PM
The "OK Button" is a standard item. This is the first time I've ever seen a nicely shaded OK button on Propeller TV with a driver that allows something else useful with more colors to happen with video memory. The Parallax driver can't do that.

I'm excited by this.

The shades of grey are lacking resolution, but so are the shades of an given color. Dithering shades of color with small pixels offer better opportunities of course.

I'm not trying to distract from anyone's goals here. The full color icons are good and with time they will be really nice.

Good work so far.

potatohead
11-20-2010, 09:40 PM
BTW: If you use the older version driver on this thread, only 256 tiles are possible, but... screen cost is half. For your number pad example we discussed earlier, that's possible and likely practical. For something more complex, the word addressing for tile numbers is necessary.

No worries on anything else. It's driver work right now. What happens above that is anybody's call. Not a distraction, IMHO.

Baggers
11-20-2010, 09:59 PM
Hi Guys, here's the VGA driver first release pass anyway :D

Potatohead and myself are going to match up the drivers, so you can use one or the other, all calls will eventually be the same, and will also be designed to be usable as a binary to load into a cog, and leave, so you can just load it from SD

Anyway, here's the first pass.

1Cog for VGA driver
1Cog for Scanline Render with only a couple of sprites(4x8) more cogs = more sprites.

have a look and a play, and let me know what you think, or if it needs changes anywhere?

Coley
11-20-2010, 10:36 PM
Looking good Baggers, hopefully this will inspire a few more games to be written......

Amongst other things :smilewinkgrin:

Regards,

Coley

Baggers
11-20-2010, 10:37 PM
Yeah, that's the plan! :)
Cheers Coley!

Coley
11-20-2010, 10:39 PM
So I already have a question....

I guess for every tile I make the driver takes another 32 bytes of hubram no matter how many times I use it on screen?

I bet you already have some little app for converting a bitmap into tiles don't you???

Regards,

Coley

Coley
11-20-2010, 10:41 PM
and another question.....


Potatohead and myself are going to match up the drivers, so you can use one or the other, all calls will eventually be the same, and will also be designed to be usable as a binary to load into a cog, and leave, so you can just load it from SD

Does this mean it will be usable in PropBASIC and C also???

Thanks,

Coley

Baggers
11-20-2010, 10:50 PM
Yes, Coley, it will only take an extra 32bytes of hubram per tile you add to it, no matter how many times you use it on screen :D
And yes, my graphics converter, the one I posted AAAAAAAges ago, should convert for it, if you make the BMP 4 pixels wide, and arrange all your tiles down the image, it will do it, I will however make a newer mod to it, so it breaks a bitmap up into 4x8s :D

And yes, it should be usable in PropBASIC, I'm going to do a demo for PropBASIC next.
and C, I don't see why it shouldn't work in C, as the driver itself is self contained, IE doesn't need spin helpers it should even work with Sphinx :D

potatohead
11-20-2010, 11:31 PM
Since there is a converter app, I'm not going down the road of making address change. Let's get that worked out, and I'll strip down the more bulky driver I've built, and sync up!

Thanks a bunch Baggers.

Everyone: This thing renders a LOT of sprites per COG. @Jazzed, a few of these could be made to present as GUI elements, and you could have a mouse, and some common text as sprites. Would take some work at the SPIN layer to have it all come together, but, the sprites offer per pixel positioning, meaning the mouse and some "floating" GUI elements, or text is now possible. IMHO, convert a few buttons to tiles, place them, then render sprites on top of that, done! A lot of the things you wanted to do are possible.

@Dr_A, Jazzed, others: VGA Rocks. Not as many colors, but man! It's sure nice and clean to work with. This particular timing really makes sense too. Pixel clocks are in the range of good resolution for Propellers overall. Got my first real play on a monitor today.

It may be needed to give up 320 on the TV to match up with this, just FYI. Maybe not. Either way, 256 pixels is doable, and appears to be the standard high-color Prop resolution.

Dr_Acula
11-20-2010, 11:53 PM
Wow, this thread works 24/7!

Re "will also be designed to be usable as a binary to load into a cog, and leave, so you can just load it from SD "

That would be a huge bonus. Hub ram is precious and, for instance, with the code I posted, 2k is being wasted as the cog space used to load the vga driver, and another 2k for the keyboard and another 2k for the sd card driver.

Not such an issue when the hub ram is fixed at 19k for straight bitmap drivers 160x120, but for tile drivers, every bit of ram can be used for more tiles.

And, binaries for cogs that load from an sd card also will be useful for catalina, zog and the Basic compilers.

I'm already thinking ahead about writing a .bmp to tile converter in spin. Add it as another icon/binary for the operating system.

jazzed
11-21-2010, 12:00 AM
@Baggers, The demo looks good so far. I'll explore more later. Thanks.

Baggers
11-21-2010, 12:05 AM
Glad you like it so far :D
I'm off to bed now, will catch up again tomorrow!
It's been great having some prop time again!

jazzed
11-21-2010, 02:16 AM
@potatohead,

How can I set the border color? I've seen this done in other drivers.
BTW, non-interlace mode is very crisp here on my dinky DVD LCD TV.

Thanks.

potatohead
11-21-2010, 03:44 AM
there is no setting. I'll see about adding that as a fold in the stuff Baggers posted. Those color constants are hard coded into parts of the TV COG, and mixed into the render / graphics COG.

Thanks. The non-interlace mode on this one is kind of special. Happened by mistake, and I liked it. Most non-interlaced drivers either have no color phase change, or if they do, it's alternating back and forth, producing dot crawl, or OBC says, shimmer. This one is alternating static, which results in a crisp picture, with no dot crawl. The trade off is image movement may display ripples in the shape edges, at some specific speeds. The advantage is a nice picture, with nothing moving, unless the programmer wants it that way.

I use it on smaller displays myself.

Dr_Acula
11-21-2010, 03:51 AM
I've just been researching color dithering. With a limited palatte, it could potentially improve the look of pictures.

Can't wait to try out the tile driver.

Thinking about code that you can load into a cog from a binary, a display driver really only needs one variable - either passed to it, or passed back from it, and that is the hub ram location where the data is stored. That ought to make such code easier to write?

Playing around with fonts at the moment. Thinking of ways of automatically creating a library of fonts for use in text boxes.

@Baggers - I changed the last few lines so they are in binary and display all the colors. On my monitor they are just starting to bleed into each other, so I think this is finding the limits of vga.

Quite amazing resolution!



chars byte %00000000,%00000100,%00001000,%00001100
byte %00010000,%00010100,%00011000,%00011100
byte %00100000,%00100100,%00101000,%00101100
byte %00110000,%00110100,%00111000,%00111100
byte %01000000,%01000100,%01001000,%01001100
byte %01010000,%01010100,%01011000,%01011100
byte %01100000,%01100100,%01101000,%01101100
byte %01110000,%01110100,%01111000,%01111100

sprchrs
byte %10000000,%10000100,%10001000,%10001100
byte %10010000,%10010100,%10011000,%10011100
byte %10100000,%10100100,%10101000,%10101100
byte %10110000,%10110100,%10111000,%10111100
byte %11000000,%11000100,%11001000,%11001100
byte %11010000,%11010100,%11011000,%11011100
byte %11100000,%11100100,%11101000,%11101100
byte %11110000,%11110100,%11111000,%11111100


(Picture below is 160x120. Baggers seems to have pushed this out to 320x240)

Baggers
11-21-2010, 09:52 AM
Dr_Acula, If your still having trouble with the bleeding, make sure the colours are legal values, ie ( OR'd with $03 per byte or $03030303 per long to set the HVbits ) then you could go into the VGA_JB_001 driver and remove the "or pixels,coloror", which should give it the extra speed?
Btw, it's 256x240, not 320x240 :)

Dr_Acula
11-21-2010, 10:10 AM
I suspect the color bleeding is actually my eyes. <goes and puts on glasses>

Yes, 64x4 is 256.

So, to clarify, you have 64x30 tiles. I presume there is a list somewhere of those? How does the list work - does the list contain each x,y position, or is the list in order of x then y and the list contains the tile number?

Say I want to add to your code. I want to put a tile at position x,y and somewhere I presume I define what data is contained in that file.

So are the steps:
1) Build the data in the tile (either in a data array, but more usefully, loading from sd card)
2) Add the tile?
3) Tell the display code to display this tile?

See attached picture - this 256x240 in Prop colors (gray scale in this example). You need to zoom in to see the gray scale on the edge of the font - it is starting to look smooth.

So - do we need to first scale this somehow from 1.066 to 1.333? Do this while in higher res?

Then, with this example, run it through some code (I'm thinking vb6 as vb.net can't do pictureboxes so well) and search for 4x8 blocks that are solid. It will find lots of white and also some black ones. Make a list of those. Then make a list of all the leftover ones. Store x,y and the data as sprites.

Then create some sort of build list, maybe as a header file, so this can be loaded from the sd card?

Testing fonts on the screen - these seem to work.

Writing a program in vb6 to try to automate capture of a font to turn it into files we can read. See this vb6 program - we can create a font of any size/color and print it to a picture box. If we use the underscore character as a reference, and maybe the top of the [ character, it ought to be possible to capture the bottom, top, left and right of fonts that are variable width - eg Arial and Times Roman. If the process can be automated, it should be possible to build up libraries of data files at a wide range of sizes. Draw a text box of the right size, then fill it with the bitmaps of the appropriate text.

jazzed
11-21-2010, 04:33 PM
Nice picture :D

Baggers
11-21-2010, 08:17 PM
Hi again,

Here's the graphic converter, with a new project, which has the converted data files in, displaying an image + sprites.

To convert the (8bit) bmp image to .chr and .map files just type

bmptolite filename -vga4x8

don't add the .bmp to filename, as it appends the .bmp automatically, and uses that filename to add the .chr and .map extension for the output files.

Cheers,
Baggers.


EDIT: I'm noticing sometimes the PLL messes up and you get blocky columns, so I remember seeing something a while ago, that linus found about the stabilising of the PLL, hopefully that should fix it :)
but for now, to fix, set the NUM_COGS to 6, then back to what you had it on, or a turn off and on, can fix it too.

Coley
11-21-2010, 09:25 PM
Baggers, I experienced those same issues with the PLL and I turned cogs up to 6 and then back down to 3 and it worked.

Here's the display....

Baggers
11-21-2010, 09:42 PM
Also, you could try starting the VGA cog after the render cogs, that works also. :D
I tried the Linus thing, which didn't seem to alter anything, I think that was probably more to do with sync'ing 2 or more cogs.

potatohead
11-21-2010, 11:10 PM
Sweet!!

I'm currently working on getting the TV COG to work with Baggers render COG. (bloody brilliant, I might add) My buffer scheme is a careful race between TV and render COG. This scheme is much better, fails gracefully too. So, I'm kind of digging in right now, tracing through, learning what was just done for us.

Got sidetracked with a plumbing problem. Don't you guys hate those?

Anyway, I thought I would say, if somebody wants the higher resolution, just add the OR operation to all the tiles, prior to launching the video COGs. Call it when needed to deal with tile data, and life is pretty good.

...just a thought, so we can have 320 (maybe, if that makes it quick enough) on both drivers. I'm gonna do it as a SPIN method at some point, just because it's a shame to not have all the pixels possible. Funny that way :)

Dr_Acula
11-21-2010, 11:17 PM
@Baggers, is the source of that conversion program available? I might see if I can merge it with something to create all the fonts.

Baggers
11-22-2010, 03:19 PM
@Dr_Acula, et all,

Here's the latest version, I've modded it, to have transparencies on the sprite, which is now done by RGB $FF00FF in the colour palette in the bmp file. this will come out as $00 in the data, as black is $03, but if you want purple just set it to $FE00FE it'll be rounded down to the correct VGA $CF value.

I've also modified BmpToLite to now have allow transparencies $ff00ff, I've also allowed it to grab with not allowing repeats ie for fonts.

bmptolite font -norep -vga4x8

will grab the font.bmp image ( it's in the zip file ) and convert to chars for VGA you'll also see a print routine inside the VGA_JB_Demo.spin which will print a text string at X, Y position, for how to decode the characters, in case you want to add other characters to the font, but this is using the least amount of chars for the font + numbers, to save space.

as you can see, although the chars are in a different place compared to the image, they can still be referenced by the display, as they done by an offset from the image charset.

I've also included the code, it could be a tad difficult to read, as their are MANY MANY options in the converter, as it is for PropGFX Lite.

jazzed
11-22-2010, 05:04 PM
I just booted this fantastic demo! Thanks Baggers!

Baggers
11-22-2010, 09:12 PM
You're welcome Jazzed :D
I hope to see some good things from this and potatohead's driver

Dr_Acula
11-23-2010, 01:13 PM
This is really quite an extraordinary demo.

1) small pixel size
2) 64 colors
3) smooth movement of tiles

I'm thinking not just a graphical OS, but also games!

I've been playing around with vb.net code editing bitmaps. I think you already have something similar in your conversion program, but I think I need it as part of vb.net so I can automate the creation of operating system screens.

Just to check - if we are modifying fonts, we need to do some scaling as your ratio is 64/60 and most fonts are going to start as 4:3? If so, I'm assuming it might be better to read in fonts at a big size, do the scaling while they are big, then ? shrink.

Also - I see you have a line in the code
chars file "mario.chr"

Is this reading the file as part of the compilation process and storing it in hub? If so, I need to study your .chr format to work out how to build new screens.

Amazing work!

Baggers
11-23-2010, 02:54 PM
Dr_Acula,
The line chars file "mario.chr" is reading the file "mario.chr" in the compilation process, which is the output file of the tiles, from the mario.bmp image that was converted with BMPtoLite, the file "mario.map" is the other output file from the BMPtoLite process, which is the tile layout, which gets written to the screen after multiplying it by 32 ( I might make that a process inside the BMPtoLite, so it is ready to go direct to the screen.

dr hydra
11-23-2010, 07:29 PM
Are the small blue squares the sprites?

Baggers
11-23-2010, 07:55 PM
dr_hydra yes, the small blue squares are sprites.

dr hydra
11-23-2010, 09:24 PM
so...VGA...256x240...64 colors...64 sprites...transparencies...and only three cogs...that is amazing!!

Baggers
11-23-2010, 11:20 PM
Thanks dr_hydra,
btw, it's 3 render cogs + 1 vga driver cog
you can do less sprites and 2 render cogs, or 0 sprites and 1 render cog ;D

Dr_Acula
11-24-2010, 02:52 AM
Hi Baggers,

I'm looking at the .map file and trying to work out how it is coded.

Here is a typical line in hex:


00 00 00 00 00 00 00 00 30 01 31 01 32 01 33 01
34 01 35 01 36 01 37 01 38 01 39 01 3A 01 00 00


and I've worked out that this file is 3840 bytes long and the numbers like 00 mean 'white' (presumably tile 00 is white) and that numbers like 31 and 32 mean tile number 31 and 32.

But 64*30 is 1920, not 3840 and I've noticed that between the tile values is 01.

So each tile is described with two bytes. What does the 01 mean?

Addit: Scratch that. I worked it out - 01 is the high byte. Ok, so you have more than 256 tiles. How many can you have in total?

Cluso99
11-24-2010, 03:01 AM
Don't you just hate being off-air for a couple of days! It's almost an impossible task to catch up on what happened!

This is brilliant :smilewinkgrin: Congratulations guys.

Dr_Acula
11-24-2010, 05:17 AM
I think I'm getting there decoding the format.

The .map file is a list of tiles, in order, with one word (two bytes) per tile. 3840 bytes.
The .chr file is the tile data, with 32 bytes per tile.

The .chr file can be unlimited in size, but clearly it has to fit into hub ram. Thus with a minimalist driver one can work out in advance how big the file is allowed to be, and generate a warning. Pictures are about as big as mario, unless they have large blocks of color the same.

Tile data is %RRGGBB11 as described by Baggers above.

Pictures will need scaling. I need to work out the exact ratio to make sure a square stays a square. I see from above that there was a timing issue that has kept the width to 256 rather than, say 320.

I have the basics for picture manipulation at the pixel level in vb.net so hopefully can automate producing .map and .chr files from a suitably pre-scaled picture.

Baggers
11-24-2010, 09:30 AM
Thanks Cluso :)

Dr_Acula, yeah the map is a word ( 2 byte ) layout of each tile that was converted from the original BMP. and as you say, the .chr file can be any size as long as it fits into HUB-RAM :D
You can have multiple sets of .chr files also ( if they fit obviously ) just remembering to set the tile WORD in the screen buffer to ((chrnum)<<5)+(@chrbase-@chars) where chrbase is the new .chr file you want to use, and chars is the render cogs initial charbase. the <<5 = *32 as there are 32 bytes per character.

Oldbitcollector (Jeff)
11-24-2010, 04:25 PM
This is an amazing thread! Can't wait until the weekend to try some of this out!

OBC

Dr_Acula
11-25-2010, 02:19 AM
Created a one click picture creation with the correct ratio. Circles now display as circles.

1) Create a bitmap 640x480 (or any higher 1.333 ratio resolution)
2) Save this as the working bitmap
3) Resample in paintshop pro to 256x240 with the "maintain aspect ratio" unchecked and resave (maybe with '256' in the name as a reminder this is a narrowed picture).
4) Run the image processing in the Catalina IDE - enter the file name and one click.
5) Compile the spin program.

Some things I have learnt along the way:

*The maths involved in the ratio correction is a bit complex but just resizing fixes the problem.
*Some blurring does occur on resampling, so some small fonts may need to be created in another way.
*With the display driver stripped back (no fonts) the max tile filesize is about 21k (I display the file size in the vb.net code so if it is too big, shrink the picture and add more whitespace)
* Doing the color reduction in vb.net is much quicker than doing it by hand in paintshop.
* Adding text to pictures may look better if the text is added after scaling.

The third picture is a screenshot of an example GUI using the Baggers driver. You can see the slight stretching of the text so it is wider and Tweety has a fat head. On the other hand, the text is crisp and clear. The gray needed to be darkened as the cutoff in the code is 192 and the gray values are around 200 for RGB. This picture took 6.2k of tile data so there is plenty more room when the display is buttons/radio boxes/text boxes. The white lines across the pictures are artifacts of taking my camera taking photographs of pictures with white backgrounds.


The meaty bit of the vb.net code is below:



Private Sub Button4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button4.Click
Dim sizex As Integer
Dim sizey As Integer
Dim PixelValue As Color
sizex = 256 - 1 ' baggers screen is 256x240
sizey = 240 - 1
Dim PixelArray(sizex, sizey, 3) As Byte ' R,G,B and calculated prop byte so 4 values
Dim x, y, i As Integer
Dim Propbyte As Byte
Dim TileArray(1920 - 1) As String ' Up to 1920 tiles though this is more than hub ram
Dim TileMap(1920 - 1) As Integer ' each entry is 2 bytes
Dim OutputArray(30000) As Byte ' use for both tilearray and tilemap, can never be more than hub ram
Dim TileX, TileY As Integer
Dim TileString As String
Dim HexString As String
Dim t, TileCounter As Integer
Dim TileMapCounter As Integer
Dim TileExists As Integer
Dim lsb, msb As Byte
Dim Sourcefile As String
Dim DestinationFile As String
Sourcefile = TextBox4.Text + TextBox3.Text
' this little bit of code replaces new sytem.drawing.bitmap as the latter leaves the file locked eg so paintshop can't save a new file
Dim img As Image
Dim fs As New FileStream(Sourcefile, IO.FileMode.Open)
img = Image.FromStream(fs)
fs.Close()
PictureBox3.Image = img
'PictureBox3.Image = New System.Drawing.Bitmap(Sourcefile) ' load picture
Dim MyBitmap As New System.Drawing.Bitmap(PictureBox3.Image) 'image from picture box
For y = 0 To sizey
For x = 0 To sizex
PixelValue = MyBitmap.GetPixel(x, y) ' get the color
PixelArray(x, y, 0) = PixelValue.R ' red byte
PixelArray(x, y, 1) = PixelValue.G ' green byte
PixelArray(x, y, 2) = PixelValue.B ' blue byte
PixelArray(x, y, 3) = 3 ' pre fill the prop byte with %00000011 for Baggers tiles
Next
Next
' create the propeller color byte
For y = 0 To sizey
For x = 0 To sizex
For i = 0 To 2
ConvertColor(PixelArray(x, y, i), Propbyte) ' get the value 0-3
Select Case i
Case 0 : Propbyte = Propbyte * 64 ' shift to red position
Case 1 : Propbyte = Propbyte * 16 ' shift to green position
Case 2 : Propbyte = Propbyte * 4 ' shift to blue position
End Select
PixelArray(x, y, 3) = PixelArray(x, y, 3) + Propbyte ' add to existing color
Next i
Next x
Next y
'PictureBox3.Image = MyBitmap ' bitmap array to picturebox - need to convert pixelarray back to mybitmap to show the decreased color depth
' now create the tiles and the map using the pixelarray data in dimension 3
TileCounter = 0
TileMapCounter = 0
For TileY = 0 To 29 ' 30 rows of tiles
For TileX = 0 To 63 ' 64 columns of tiles
TileString = ""
For y = TileY * 8 To TileY * 8 + 7
For x = TileX * 4 To TileX * 4 + 3
NumberToHex(PixelArray(x, y, 3), HexString) ' get the hex value
TileString = TileString + HexString ' add to the tilestring
Next x
Next y
' does this tile exist already?
TileExists = -1
For t = 0 To TileCounter
If TileString = TileArray(t) Then TileExists = t ' found a match
Next t
If TileExists = -1 Then
' no match so add as a new tile
TileArray(TileCounter) = TileString ' add to tile array
TileMap(TileMapCounter) = TileCounter ' add this to the map
TileCounter = TileCounter + 1 ' and add one to tile array counter
TileMapCounter = TileMapCounter + 1 ' and increment map counter
Else
' found a match at Tileexists so no need to add this tile
' add this to the map, and increment the map
TileMap(TileMapCounter) = TileExists
TileMapCounter = TileMapCounter + 1
End If
Next TileX
Next TileY
' now turn these arrays into binary files
' the map file is two bytes, lsb first

t = 0
For i = 0 To 1920 - 1
IntegerToBytes(TileMap(i), msb, lsb)
OutputArray(t) = lsb
t += 1
OutputArray(t) = msb
t += 1
Next
DestinationFile = TextBox4.Text + TextBox6.Text
Dim OutputMap As New FileStream(DestinationFile, FileMode.Create, FileAccess.Write)
OutputMap.Write(OutputArray, 0, 3840)
OutputMap.Close()
' and now the tiles
t = 0
For i = 0 To TileCounter - 1
For x = 0 To 31 ' number of bytes in each tile
OutputArray(t) = Val("&H" + Strings.Mid(TileArray(i), x * 2 + 1, 2))
t += 1
Next
Next
DestinationFile = TextBox4.Text + TextBox5.Text
Dim OutputTile As New FileStream(DestinationFile, FileMode.Create, FileAccess.Write)
OutputTile.Write(OutputArray, 0, TileCounter * 32) ' if tilecounter=1 then 32 bytes
OutputTile.Close()
' display the file size
Label13.Text = "Tile size (bytes) = " + Strings.Str(TileCounter * 32)
End Sub
Private Sub ConvertColor(ByVal Bytevalue As Byte, ByRef Returnvalue As Byte)
' takes a number 0 to 255 and changes to the nearest propeller color
' prop colors are 00,01,10,11
' so 0-63 is 00, 64-127 is 01, 128 to 191 is 10 and 192 to 255 is 11
' this is the same as dividing by 64 but do it this way in case later
' need to tweak the values
Select Case Bytevalue
Case 0 To 63
Returnvalue = 0
Case 64 To 127
Returnvalue = 1
Case 128 To 191
Returnvalue = 2
Case 192 To 255
Returnvalue = 3
End Select
End Sub
Sub NumberToHex(ByRef N As Integer, ByRef Hexstring As String)
' 0 to 255 and returns 00 to FF
Hexstring = Strings.Hex(N)
Hexstring = Trim(Hexstring)
If N < 16 Then Hexstring = "0" + Hexstring
End Sub
Sub IntegerToBytes(ByRef N As Integer, ByRef msb As Byte, ByRef lsb As Byte)
Dim hexstring As String ' there is a way with mod and integer division as well
hexstring = Strings.Hex(N)
hexstring = Trim(hexstring)
hexstring = "0000" + hexstring
hexstring = Strings.Right(hexstring, 4)
msb = Val("&H" + Strings.Left(hexstring, 2))
lsb = Val("&H" + Strings.Right(hexstring, 2))
End Sub

Private Sub TextBox3_TextChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles TextBox3.TextChanged
If Strings.Len(TextBox3.Text) > 4 Then
TextBox5.Text = Strings.Left(TextBox3.Text, Strings.Len(TextBox3.Text) - 4) + ".chr"
TextBox6.Text = Strings.Left(TextBox3.Text, Strings.Len(TextBox3.Text) - 4) + ".map"
End If
End Sub

JT Cook
11-25-2010, 06:04 AM
That looks pretty awesome (I too have to wait until the weekend before I can check it out)! I am still a little fuzzy on somethings.
You say the tiles are 32 bytes, are the tiles 4bpp or are the tiles odd sizes? Also it can do 64 sprites, is that total on screen or per scanline? And lastly what are the size of the sprites?

Dr_Acula
11-25-2010, 06:17 AM
I'm not quite up with the formal terminology of sprites and bpp, but the tiles are 32 bytes each - 4 bytes wide and 8 bytes high. Each pixel is a byte RRGGBBxx where I think xx is used for transparancy (I'm setting them to 11 for the moment).

A screen is 256 x 240 pixels. So that is 64 x 30 tiles.

Each of those tiles can be moved around the screen from code, and Baggers' demo does that very smoothly.

potatohead
11-25-2010, 06:49 AM
The way Baggers writes renderers is very clever.

(and I've been working at getting the TV driver to mesh, learning a lot right now)

Sprites per line depends on the number of render cogs. Fewer cogs = fewer sprites per line, also, where the sprites are can impact sprites per line, so consider sorting your sprite list by horizontal screen position, if things are tight!! Put the last sprites in the list, farther right on screen to get the most out of the render cogs allocated.

He mentioned multi-plexing to me. I think that means dedicating the sprites based on screen region, sorting the list during blank, like I mentioned.

The renderer computes the scan line, then can work on the next one, meaning smart sprite placement operates down to the per-sprite level, failing gracefully, with part, or all of a sprite simply missing, with no other impact on the screen.

Higher clock = more sprites per scan line. Sprite data is 4x8 pixels, same as the tiles, all one byte per pixel.

Dr_Acula
11-25-2010, 01:09 PM
Pushing things to the limit here but we can get 16 picture icons on a screen. This uses a lot more memory than 'windows style' gray buttons.

The problem is there is no room left in hub for any spin code.

The only solution I can think of is Catalina running in external memory. That potentially gives a huge amount of code space, and means you could even have c code to rebuild tiles from bitmaps (or pixel arrays) on the fly within code.

So I am thinking now of porting the Baggers video driver into Catalina somehow.

potatohead
11-25-2010, 05:42 PM
All that really needs to be done is build the driver, and write it out to a SD card.

I'm thinking the way to go is just add the SD object to the demo, then write out the COG image that the Prop Tool builds.

Then, in the other language, do the variable setup, note the start address of the block of variables, fetch it from SD, or include it as a BLOB (binary), and cognew. Launch some render COG's, using a port of the small start loop found in the demo that fires those off.

Baggers
11-25-2010, 07:23 PM
if you want I'll make SD binaries of each of the drivers ( VGA and RENDER cogs ) that way you can just load them into HUB-RAM with SD driver and then upload them to cogs.

Dr_Acula
11-25-2010, 09:57 PM
SD binaries would be great. Building sd binaries for catalina is a two step process - the first and hardest step is stripping out all the extra spin code that usually accompanies cog code. But your demo has very little. The second step is adding some standard header code to handle talking to fixed locations in hub upper ram.

I think that extra code is maybe 15 lines of pasm, so hopefully the cogs are not completely filled with code already?

I presume there is no way this could ever be done with less than 4 cogs?

Baggers
11-25-2010, 10:30 PM
My demo has very little spin for the apps, because they were designed with the intent to eventually be stand along binaries :)
There's also PLENTY of room left in the cogs :D
if you don't want sprites, it can be done in 2 cogs, VGA driver + 1 Render Cog. at 80Mhz

Dr_Acula
11-25-2010, 11:07 PM
Ah, this is all very good news.

I took a look at the code - now I understand what "unrolled" means.

Re if you don't want sprites, it can be done in 2 cogs, VGA driver + 1 Render Cog. at 80Mhz

Could you explain that a bit more. What is a sprite?

potatohead
11-25-2010, 11:22 PM
In this driver, there is "the background" which is essentially stationary 4x8 sprites, which we call tiles.

Those are indexed by the screen memory array, with each value indexing into the tiles, so that any tile can be placed at any screen location. The locations are fixed, with each tile stacked right against the next one to fill the screen.

On top of that, if one runs another COG, are movable tiles. They are also 4x8, but instead of being sequentially positioned, are positioned with a sprite list, which contains the tile address index (same method), and the screen position X and Y.

The draw order is background, then sprites, all of which can share the same tile data.

Sprites are generally limited by number per line, and that is what can consume extra render cogs.

Dr_Acula
11-26-2010, 12:25 AM
Ok, that makes sense.

So maybe one could think about two versions of the code - the 'sprite' version for games, and the 'background' version for a GUI?

Also - maybe the sprite version could be used for a GUI - eg you draw a gray background (which would only take one tile, plus the 4k for the map), then you draw objects on the background using foreground sprites.

What would a 'background only' version of the code look like - is it just a matter of leaving out one cog or is it a bit more complicated than that?

potatohead
11-26-2010, 01:27 AM
It's just a matter of calling out two cogs, then not defining any sprites, or maybe just one sprite. (It will do a couple, regardless)

The renderers just complete the background, then begin processing sprites until time runs out.

Dr_Acula
11-26-2010, 01:42 AM
Potatohead, do you have a dracblade?

I just had a crazy idea looking at your avatar - could we load screens quickly enough to make a movie?

Eg, say we preload tiles and maps from sd card into external ram. Then move them quickly, maybe using a pasm routine, from ram into the video driver cog. Typical files might be 20k total. The ram driver code moves a byte from external to hub ram in about 20 pasm instructions, and can move bytes over 1 million per second. If a video 'frame' takes 20k, we ought to easily be able do 30 frames a second?

Is your avatar a gif? If so, one could potentially take the frames and turn them into .map and .chr files (I could automate that with the vb.net code). Then it is a matter of how much video you could store. Only a second at 30 frames, but if you went to 5 frames a second it could be a number of seconds. And one could maybe be feeding data off an sd card into ram at the same time??

potatohead
11-26-2010, 02:36 AM
No I don't, but I like where you are going with that.

The entire GIF is about 30K! It's possible to display on the Propeller :) There are much longer ones out there too. Never thought about it that way before.

IMHO, a movie could happen by only changing some of the tiles each frame, worst case. Maybe the best case is to kind of "compile" the whole thing, leaving most of the display intact... Probably exactly how video compression happens for real. Take a key frame, then compute deltas, every once in a while accumulating enough for another keyframe, repeat...

Dr_Acula
11-26-2010, 04:24 AM
Thinking about movies, I don't know what the timing is like, but if it is possible to move 20k of data for a new frame in between frames that would be easy. But... I don't think it will be fast enough without flicker.

It could be tricky if the first tile is, say, all white, and the first tile in the map is this white tile, and so is the last tile in the map. You can't do any updating until the last tile is displayed.

Looking at what you can display with different file sizes, it could be possible to sacrifice a little resolution and store two 10k files (.chr and .map) One is the display one, and one is being updated from external memory or sd card. Switch back and forth between each one.

Or maybe there is a complex formula one could work out in advance.

Or maybe go back to Kye's 160x120 driver for movies? I did try moving data one byte at a time from sd card to hub ram but it was far too slow. There may be scope to do a block move that could be faster - I haven't explored that. If not, then external ram may be another solution. Kye's code may be easier than tile code as one could be updating the pixels on the fly.

Re background only code, when I get home I'll take a look at the code and see how it might work with one less cog.

At some time I'd like to bring XMM catalina into this and see what could be done with some demo code. An example might be to use some existing C code for Pacman and see if one could build up tiles for the maze walls, corners, the dots and the ghosts.

Addit: Some experiments with movies using Kye's 160x120 driver:



pix: "VGA64_PIXEngine.spin" ' thanks to Kye 160x120
fat: "SD2.0_FATEngine.spin" ' thanks to Kye
...

PUB FastWallpaper
fat.openfile(string("Prop160.vga"),"R") ' 160x120
fat.readdata(pix.displaypointer,19200) ' read data to display buffer location
fat.closefile ' close sd file


No flicker and loading frames every 200ms.

Not bad really!

Kye
11-26-2010, 02:02 PM
@Dr_Acula - Yep, that would be how you could do it. FSRW should be abe to give you more frames per second. Look into the displaySync method if you need to fix flicker issues.

Dr_Acula
11-26-2010, 11:37 PM
Hi Kye, thanks for the PM. I'd love to write a review for your SD driver code. Only problem is - I can't seem to be able to log into the Obex. Do you know if the passwords changed with the forum migration?

I'm using more and more 'Kye code'. I've got a new PCB that just arrived today with a mouse port, so in the near future I'll be looking to add the combo mouse/keyboard object you have as well.

Re the tile driver, the attached picture is fake, as the propeller is not really browsing the internet, but it does show that colors look good, and it also gives an indication of how much screen space you would get. One would need a html translator that knows about the small screen. And of course, there is no memory left in the propeller, so this would have to be running in Catalina in external memory. And some C code to build new tile maps on the fly (a copy of the existing vb.net code). There must be some C code out there that can translate html. And decode jpegs and bitmaps.

JT Cook
11-27-2010, 07:38 PM
I was able to get the program working on the C3 and it looks pretty awesome! I also tried it on my HDTV and it worked there as well.

potatohead
11-27-2010, 10:22 PM
With some help from Baggers, I've almost got the TV display operating with the render COG. 256 pixels x 200 lines. I'll post shortly after some cleanup and final debugging.

I'll include a TV folder, with data and such, running basically the same demo bit. That way, people can build from there, using either device.

@JT: Excellent!

Screenie from the same data converted for TV attached. There is a purple supposed to be transparent ending up green problem in the font. Needs work, but the little figure 8 sprites show the renderer working properly.

:)

Zip archive soon. Just need to tidy the mess

JT Cook
11-27-2010, 11:37 PM
My plan is to merge that with my TV graphics driver and maybe port over some of my games to VGA. The hard part will be converting the graphics :)

jazzed
11-28-2010, 03:49 AM
This is looking better all the time.
Having a TV driver with the same functionality as the VGA driver would be great.
Now if only the start interface could be as simple as start(basepin), that would be excellent.

potatohead
11-28-2010, 04:26 AM
Well, I'm going to keep it lean on this one. Demoboard @ 80, with people doing mods from there.

There are a lot of boards now, lots of clocks, and lots of drivers. The standards work is very significant, and that's not something I want to own, mostly because it would take my hobby time completely to do. It's hard to test without maintaining a lot of boards too.

So yeah, me too :(

I've attached the TV modded driver. Some small work to do yet, but it's basically up and running with the same calls as the VGA one. Good for a play. I've got notes and such to pack in there about the converter, and the mod to the renderer. Might make that a constant, and just have one renderer file too.

Tomorrow for that.

jazzed
11-28-2010, 04:58 AM
Well, I'm going to keep it lean on this one. Demoboard @ 80, with people doing mods from there.

There are a lot of boards now, lots of clocks, and lots of drivers. The standards work is very significant, and that's not something I want to own, mostly because it would take my hobby time completely to do. It's hard to test without maintaining a lot of boards too.

A "Properties.spin" file should be sufficient to satisfy any user's config.
Simple, no dependencies on what other pins might be connected, etc....

Such a file can define clocks and pins for any board.
Developers can add new board types as necessary.
Users can reference the file that works for them.

No headaches, No bias, No multiple file source edits.

potatohead
11-28-2010, 05:24 AM
There are basically several source code trees for video drivers. Parallax, CardboardGuru, Eric Ball, others...

There are variations on how timings are calculated, and pin use, etc...

And there are variations on boards, as well, as circuits. Finally, the demands of the drivers themselves mean some variation, running on some boards, not on others, etc...

If you want to start such a project, or rope somebody in, I'm happy to share what I know, and run something on occasion on the boards I have. The know how to configure all the drivers is more or less here, just not well organized. That's one start. Maybe not too tough. Then come the many code changes... I'm just not up for that right now.

When OBC went down that road, ownership of that project was clearly significant, and it kind of just splattered. Out of that came the Coley autodetect, and that's kind of cool, but not all that inclusive, though perhaps it could be extended some. Don't know. I like it, but got the same query despite it being there.

Honestly, I just want to get the TV function operating well, mostly because Baggers was nice enough to jump in with the sprites and a great VGA timing, which advanced things a lot! I had just started on the drivers that were close, and he had pretty much nailed it already. (wonder just what he has cooking that we don't know about? LOL!!) So, it's nice timing.

The calls are all there, and the renderer and such work. Just need a clean up pass for some signal options, comments, and such, and it's at a stage where people can then build on it. That was the original intent anyway.

jazzed
11-28-2010, 05:46 AM
I'm used to the simplicity of the Parallax drivers - others are too.
Sure all the other drivers add value, but not everyone uses them.

I saw and participated the mess that ensued after the OBC foray :)
We can get more mileage out of localized driver specific properties files.
That way we don't have to define the universe.

We use a simple userdefs.spin file for ZOG to define a few basic items.
There's been no complaints at all, and it solved the problems.

It should be pretty easy to extract the constants out of the HwInit method
as a start. The board and driver owners should add/correct the properties.

No point in changing the old drivers, but if these two drivers could be
friendly to more people, that would be great.

I'll contribute something more substantial after a fresh cup of coffee tomorrow.

Dr_Acula
11-28-2010, 06:55 AM
Properties.spin sounds interesting.

So - that would define things like the pins you use for the video driver, sd card etc?

The solution for multiple platforms on the emulation projects has been multiple #ifdef statements at the beginning of the code. And possibly through the code, and that is where things get messy.

Only problem there is that you need BST (or other compilers) and can't do a 'quick and simple' test on some code using the prop tool.

I like quick tests!

Ok, so is the idea that every program you release has a line in the OBJ section:
properties : properties.spin

and in that is a list of CON declarations that then become common to the entire program?

I like the concept!

on another topic...

@baggers/potatohead - the 256x240 driver is amazing and is probably the best resolution we are going to get with full color. I've gone some way towards automating scaling having discovered the vb.net instructions to rescale images. However, 256x240 is not 4:3 and it seems most of the other video drivers are. Are there any technical reasons a similar driver cannot be written that is 256x192? Would you do this with different sized tiles, or would you do it with less than 30 rows?

potatohead
11-28-2010, 07:16 AM
Well, the TV driver is 200 lines, which is a whole lot closer!

I'm not sure whether or not the VGA will run at 320, due to the sweep timings. Maybe without the color or operation happening... That's going to make data conversion and on the fly creation harder though.

Could run fewer rows, but then the actual display shrinks too. That means tweaking the screen.

Kind of funny how it all worked out. The TV is probably looking near best case at 256, but can run 320. VGA would rock hard at 320, but that's a stretch! Too bad, that can't be flipped around.

Problem is the TV range timings just don't work on very many displays, which would limit the driver. As it is, Baggers found a good one that's pretty low --lower than the one Kye was running.

Re: Properties files.

Well? If it works with the Prop Tool, I'm eager to see how that goes. Honestly, once the last few bits are folded back into the TV part of this the resulting package will have VGA and TV, horizontal resolution matched, converter that will do either one, and the demo able to run on either one.

Jazzed will post some stuff up soon enough, so we can take a peek!

Re: Art.

Do you have any vector art? Ever run anything like Inkscape? (free software vector SVG editor) Art done with that thing can be output at the aspect needed. Just a thought.

Yeah, above this resolution, it's deffo a 4 color scene, with various ways to encode different colors. Scan line palettes, tile palettes, sprite palettes are basically the options.

Dr_Acula
11-28-2010, 08:41 AM
Could run fewer rows, but then the actual display shrinks too. That means tweaking the screen.

Yes, I'm still a bit confused about that. You have a 640x480 vga screen and it displays 4:3 and fill an area x cm by y cm on the screen. Shrink to 160x120 and it fills the same physical area on the screen. That makes sense.

But display it 256x240 and it still fills the same physical area on the screen.

What has changed? Are squares stretched? Is 4x8 something that is hard to code any other way? What actually is a square tile?

For example, 640x480, then a 3x3 pixel square will display square on the screen, right? So will a 6x6 and 12x12. If 256 is the max squares per row, then is there a divisor that divides into that, gives a square tile and works out ok with Longs (4 bytes) as well?

Could a 256x192 driver be coded that fills the same screen as, say, 160x120?

Of course, if it were possible to push the VGA to 320...

jazzed
11-28-2010, 07:49 PM
Here is potatohead's TV zip with changes to support a TvProperties.spin.
Configuration comes down to choosing a few parameters and moving the file.

TvProperties.spin is not usable with VGA just now because of the different
configuration methods. Also TV and VGA pins are just different by nature.
A calculation for ifrqa rather than some constants would be an improvement.

While the startup interface is not as simple as tv.start(pin), this method does
centralize the changes in a user replaceable file which is advantageous.

The same idea can be used with the VGA package and potentially merged.
I'll leave this for someone else as an exercise as my time is limited today.

--Steve

potatohead
11-28-2010, 09:00 PM
Dr_A, it's the relationship between the horizontal and vertical sweep signals that determines how the pixels will end up on the display.

The timings in use right now are not 4:3, thus the display won't be 4:3.

Other timings could be used, but they might not all display. The trick on these things is to use ones that are well recognized by a variety of devices, and that are slow, so the Prop has time to get pixels done.

At this sweep frequency, displaying fewer rows would change the screen refresh rate, and spread them out on the monitor, leaving gaps between the pixels, IMHO.

Dr_Acula
11-28-2010, 10:18 PM
@jazzed - yes that would simplify things. You could swap between vga and tv by changing one config file.

@potatohead - that makes sense. With 256x240 I'll look at a little vb.net routine to scale 640x480 to 256x240.

Baggers
11-29-2010, 02:09 PM
Hi Guys, in collaboration with Potatohead, I now release the latest version.

You can now with just a simple change use TV or VGA.
( Also set SCAN_YCOUNT to 200 for TV or 240 for VGA. to tell the renderer what line to stop at )

Now with Button printing too, which draws a box, and puts text on it.

Enjoy,
Baggers.

I've modified the bmp8tolite too.

to convert mario.bmp for TV
bmp8tolite mario -novga -vga4x8

to convert mario.bmp for vga
bmp8tolite mario -vga4x8

to convert font.bmp for TV
bmp8tolite font -novga -norep -vga4x8

to convert font.bmp for VGA
bmp8tolite font -norep -vga4x8

Oldbitcollector (Jeff)
11-29-2010, 06:36 PM
Perfect!

This gives me "exactly" what I need to finish an old demo that was set aside due to video driver limitations.

Thanks Baggers & Potatohead!

OBC

Baggers
11-29-2010, 06:46 PM
Perfect!

This gives me "exactly" what I need to finish an old demo that was set aside due to video driver limitations.

Thanks Baggers & Potatohead!

OBC
You're welcome OBC, look forward to seeing your demo.

Baggers.

jazzed
11-29-2010, 08:48 PM
@Baggers. Impressive work as usual.

Here's an updated TvProperties.spin file if anyone cares to use it.
Maybe a VGA variant will come later. VGA is much easier to use though.



{{
TvProperties.spin
Copyright (c) 2010, various contributors
See MIT license for terms of use.
}}

{{
----------------------------------------------------------------------------
Users select TV properties for their hardware platform
in a single, well defined, and easily replacable file.

This file should be modified by the user and put in a library folder
separate from the downloaded folder. Once the file is copied and
modified, the file should be removed from the download folder.

The file can then be referenced by the driver as:

1) Propeller Tool users: copy the file to the Propeller Tool library folder.
2) BST/BSTC users: keep modified file in the user specified library folder.
----------------------------------------------------------------------------
}}

CON
{{
'' USER DEFINED CLOCK PROPERTIES:
----------------------------------------------------------------------------
clkmode is used to define the clock parameters used by the program.
xinfreq is used to define the frequency of the crystal being used.
sysclock is used to derive an IFRQA or calculated clkfreq value.
}}

clockmode = xtal1 + pll16x ' enable external clock and pll times 16
xtalfreq = 5_000_000 ' set frequency to 5 MHZ
sysclock = xtalfreq*16 ' sysclock frequency is xtalfreq * pllx

{{
'' USER DEFINED VCFG PIN PROPERTIES:
----------------------------------------------------------------------------
basepin is the first pin used by the TV DAC
ifrqa is value to use with the TV COG frqa register - prefer calculation
}}

''NTSC Demoboard & Hydra @ 80MHz
' basepin= 12
' ifrqa = $16E8_BA2F ' accurate ifrqa value for NTSC @ 80MHz

''NTSC GadgetGangster SDRAM Module TV @ 80MHz
basepin= 20
ifrqa = $16E8_BA2F ' accurate ifrqa value for NTSC @ 80MHz

''NTSC Hybrid @ 96MHz
' basepin= 24 ' Hybrid
' ifrqa = $1317_45D1 ' accurate ifrqa value for NTSC @ 96MHz

''NTSC IFRQA value for 100MHz
' ifrqa = $1253C824

{{
'' DERIVED IFRQA VALUES
'' If you have an odd frequency use this. The method is not accurate, but
'' seems to produce reasonable values for a range of sysclock frequencies.
'' You can always comment out this and use the ifrqa values above.
'' If the value is not suitable, open your calculator to 64 bit mode and
'' enter the following (AOS or infix - RPN postfixers figure it out):
'' 7159090.1/sysclock*268435456 then convert to hex if you like.
----------------------------------------------------------------------------
ntsc = 7_159_090_9
ntscm = 268_435_456/(sysclock/1000)
ifrqa = (ntsc/10000*ntscm)<<4
}}

{{
'' Derived values for driver
----------------------------------------------------------------------------
}}
group = (basepin/8) ' group selects P0-7, P8-15, P16-23, P24-31
nibble = (basepin/4) & 1 ' nibble selects the 4 bits of a group to use
vmode = 2 | nibble ' vmode selects the video mode in VCFG

ipins = (group<<9) | (7 << (nibble*4))
idira = %0111 << basepin
ictra = %0_00001_110_00000000000000000000000 ' CTRA PLL Mode VCO/2
ivcfg = (%0_00_1_0_1_000_00000000000 << 12) | (vmode << 29) | ipins


{{
All spin files must have at least one PUB method.
This method satisfies that requirement and is not to be called.
}}
PUB none

{{
----------------------------------------------------------------------------
MIT License:
----------------------------------------------------------------------------
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
----------------------------------------------------------------------------
}}

Baggers
11-29-2010, 09:43 PM
Cheers Jazzed,

I'll incorporate that for the next release :D and do a VGA version too.

JT Cook
11-29-2010, 09:48 PM
Does the bmp tool support other sizes besides 4x8? I have my own rendering driver that I am going to try to plug into it which uses different sizes for sprites and tiles.

Also what are the rules for VGA colors? Is it $V(sync)H(sync)RRGGBB for the byte setup?

markaeric
11-29-2010, 11:34 PM
I know my question is quite contrary to the premise of this thread, but since this is quite active, and there has been slight mention of it, I'll ask anyways..

How exactly would increasing the greyscale depth work? For instance, would 6bpp require 6 pins for an r2r ladder, or would it actually require 64?

I'm asking this because I've been doing a little experimentation today to see the results of colored photos converted to various lower greyscale bit depths, and found detail to remain quite good - especially if dithering was used. While not as pretty for games, it's certainly much better than a similar bit-depth in color for photos - a huge plus for the previously discussed wiki reader. Any thoughts?

potatohead
11-30-2010, 01:04 AM
Would a full scan TV driver, doing 240 lines be useful?

It would be overscan on most all ordinary TV devices, though it may be visible on small LCD displays, and will be visible on PC capture type devices.

Baggers and I tossed that around early this morning. It's possible to do, but I don't know if practical. Targeting that for a next release actually.

BTW: @Jazzed, you will find a border color setting in the bottom of the TV driver, along with the other core parameters. :)

Baggers
11-30-2010, 09:20 AM
Does the bmp tool support other sizes besides 4x8? I have my own rendering driver that I am going to try to plug into it which uses different sizes for sprites and tiles.

Also what are the rules for VGA colors? Is it $V(sync)H(sync)RRGGBB for the byte setup?

Hi JT,
yes, it supports bitmaps, so if you line your sprites or whatever in a column image, you can grab it all as bitmap

instead of -vga4x8 you need to do -bitmap2 or bitmap4 or bitmap16 or bitmap256
and -vga if you want to grab vga colours instead of TV

ericball
11-30-2010, 12:17 PM
How exactly would increasing the greyscale depth work? For instance, would 6bpp require 6 pins for an r2r ladder, or would it actually require 64?
6bpp would require 6 pins. Most of the answers to your questions can be found on page 4 of this thread.

Dr_Acula
11-30-2010, 01:09 PM
Just to take that further, can you do grayscale on vga? eg say you have 6 pins and go into a R/2R array, then output that to the red/green/blue pins joined together. Any issues with impedance matching?

markaeric
12-01-2010, 01:00 AM
6bpp would require 6 pins. Most of the answers to your questions can be found on page 4 of this thread.



My apologies for blabbering - had I done a little homework like I did shortly after posting, I would have actually understood an R2R ladder circuit. Typical case of wanting to talk instead of listen.

Anyone else interested in a ~6bpp greyscale composite driver?

ericball
12-01-2010, 02:44 AM
Just to take that further, can you do grayscale on vga? eg say you have 6 pins and go into a R/2R array, then output that to the red/green/blue pins joined together. Any issues with impedance matching?

Unfortunately, simply connecting the RGB lines together would only get you 0..3*3 == 0..9 or 10 levels which would net you 7 levels of grey + 3 sync.


Anyone else interested in a ~6bpp greyscale composite driver?

I did a low res high grey driver: http://forums.parallax.com/showthread.php?t=116828

See also: http://forums.parallax.com/showthread.php?t=119588

JT Cook
12-02-2010, 02:14 AM
Baggers: The bmp converter worked pretty well! After some tweaking I was able to get X-Racer running on the VGA driver. It still needs some tweaking because I need a way to plug in vsync and adjust the VGA driver to display 192 lines instead of 240 lines ( filling it with just black lines or something).

Dr_Acula
12-02-2010, 04:43 AM
Unfortunately, simply connecting the RGB lines together would only get you 0..3*3 == 0..9 or 10 levels

Just thinking through the maths, is it not 4^3, not 3*3?

You have 6 lines so with a R/2R D to A that is capable of 64 levels. That ought to be 64 gray scales.

What I'm not sure about is whether you need an op amp buffer, and it might need to be a high speed one, as I don't know what the input impedance is for vga pins.

@ Baggers, are you doing 240x192 on vga?

Baggers
12-02-2010, 09:57 AM
Thanks JT Cook, glad it's worked well! :) I was also thinking of blacking some lines, to maybe do a 256x200 to go with the TV driver, and have border, which would give you some more vblank timing :)

Dr_Acula, are you wanting a 240x192? or 256x192 for anything in particular?

Dr_Acula
12-02-2010, 10:13 AM
Yes sorry, I meant 256/192 as that is 4/3.

I guess the advantage of that over 246/240 is that no scaling is needed. Not sure how the tiles work out though.

ericball
12-02-2010, 12:08 PM
Unfortunately, simply connecting the RGB lines together would only get you 0..3*3 == 0..9 or 10 levels

Just thinking through the maths, is it not 4^3, not 3*3?

VGA has the following output: RrGgBbHV or 2+1,2+1,2+1,2,2 from an output standpoint. So connecting RGB together (without any additional resistors) gets you 2+1+2+1+2+1 = 9.

However, for greyscale there's a better way of doing things. . . .

Toby Seckshund
12-02-2010, 12:11 PM
Dr_A

VGA feeds are 75 Ohms each for the RGB. The syncs are not so tightly defined and are something around TTL levels at 1K Ohms. Some posh cables use 5 x 75 Ohm coaxs (not strickly correct) but a lot just have 3 x poor excuses of coaxs and a couple of single wires (not nice at all).

Dr_Acula
12-02-2010, 12:55 PM
VGA has the following output: RrGgBbHV or 2+1,2+1,2+1,2,2 from an output standpoint. So connecting RGB together (without any additional resistors) gets you 2+1+2+1+2+1 = 9.

Yes, that is exactly correct, if you didn't change the hardware.

For grayscale, and noting the 75R impedance value above, I think it would require quite different hardware. 6 propeller pins. Feed them with 6 binary values xxNNNNNN and run that into a R/2R ladder. Maybe use 10k and 20k 1% resistors. Feed the output of that into three op amp buffers, and run each of the outputs of those op amp buffers into (I think) 75R resistors, and thence to the R and G and B pins.

Toby Seckshund
12-03-2010, 09:04 AM
If you run the amplified O/Ps through a 75 Ohm resistor then the o/p of the amp will have to be 2V p-p. This would have to be arranged either by the R2R and/or the amplifier gain.

Toby Seckshund
12-03-2010, 11:44 AM
Being thick. again.

the double level before the output reistor would be 1.4 Volts.

jazzed
12-22-2010, 08:02 PM
@Baggers or potatohead.

I've never been able to get the latest demo with 16_TV.spin to show in color.
I don't have a demo board. The only changes I think I need are these:



ivcfg LONG %0_11_1_0_1_000_00000000000_010_0_01110000 ' dac on p20..23
ictra LONG %0_00001_110_00000000_000000_000_000000 ' NTSC
ifrqa LONG $16E8_BA2F ' (7,159,090.9Hz/80MHz)<<32 NTSC demoboard & Hydra
idira LONG $0070_0000 ' dac on p20..23


If I use the 09_TV.spin driver everything is fine except a few color problems.

Any help?

My end goal is to integrate something into ZOG, but I'd to get SPIN working first,

Thanks.
--Steve

potatohead
12-23-2010, 01:57 AM
I'll check on this for you near the end of the week. I'll have some prop time then.

Hey, I need to ask. Baggers and I thought about a final release, with the TV driver extended out to 240 lines. That would include the overscan area, not viewable on many TV's, but likely viewable on little LCD devices, and capture cards. Would that have any value, or is the thing better with the TV operating in the safe area, at 200 lines, as it is right now!

Since the driver package will be touched again over the holiday (at least by me), it makes sense to add this in, if possible, and or practical.

Thoughts anybody and everybody?

jazzed
12-23-2010, 02:24 AM
I want to use the driver in the SDRAM TV/SDCARD module ZOG demo and would prefer that "all customers" be able to use the device, so operating in the safe area is more important to me. Besides I kind of like the framing effect on the little LCDs.

I think the fact that your non-interlace feature works so nice makes TV an attractive option as a "Propeller Computer" display. The current interlace only drivers don't really cut it at all for some combinations like CYAN on BLUE and others.

Thanks for your time and Merry Christmas!

--Steve

potatohead
12-23-2010, 04:15 AM
Thanks!

That's a complete accident. Truth is, I spent a LONG time trying to get it to act like the other drivers do. Then, I connected the Demo Board I was running at the time to the SONY, and decided that's a feature!! Glad it works well for your display.

More soon, when I can look. Deffo keep it a option then on the 240 lines. Easily done.

potatohead
12-27-2010, 07:07 PM
Jazzed, are you around?

Wondering about your clock and pin setup... And is that the TV code from the last release Baggers posted??

jazzed
12-27-2010, 07:31 PM
Yes, I'm here. Here's the setup detail:



basepin = 20
ifrqa = $16E8_BA2F
idira = $0070_0000
ictra = %0_00001_110_00000000_000000_000_000000 ' CTRA PLL Mode VCO/2
ivcfg = %0_11_1_0_1_000_00000000000_010_0_0111_0000


Code is 16_TV.spin

potatohead
12-27-2010, 10:39 PM
Everyone,

The TV driver as released is botched. I'll post another release here, with the TV driver sorted, proper headers and such. Sorry, if you've been getting a rough TV signal outta this demo.

Edit: Here's a stable release, current, with converter, fixed TV driver, graphics samples.

potatohead
12-28-2010, 02:03 AM
Bump (please lengthen your message to at least 10 characters) Sorry for the bump. Was dorking around with attachments.

Oldbitcollector (Jeff)
12-28-2010, 03:20 AM
Very nice!

I've got to get my Ghostbusters demo converted over to this!
(Maybe after I finish my Tron lightcycles game)

OBC

trodoss
02-24-2011, 03:48 PM
@potatohead,
for screenshots of tearing on the display, see:
http://www.savagecircuits.com/forums/showthread.php?520-Dissecting-Baggers-Potatohead-s-Tile-Driver

--trodoss

Oldbitcollector (Jeff)
03-06-2011, 04:19 PM
Has anyone found a better solution to the PLL issue with this driver?

The solution doesn't really work... This tends to happen in 8-10 compiles at random.



EDIT: I'm noticing sometimes the PLL messes up and you get blocky columns, so I remember seeing something a while ago, that linus found about the stabilising of the PLL, hopefully that should fix it
but for now, to fix, set the NUM_COGS to 6, then back to what you had it on, or a turn off and on, can fix it too.


Normal:
79058

Issue:
79059


OBC

kuroneko
03-07-2011, 12:34 PM
Could one of the video warriers please explain what PLL messes up actually means? I can't decide for myself if it's either made up or tries to explain something else entirely. That said, I hope it's the latter but you never know with assumptions, that's why I ask :)

potatohead
03-07-2011, 05:32 PM
I've not ever had this happen.

The TV portion has some small issues on my list to fix, and I've tagged those. Know what's going on. This one confuses me, because the driver has always started correctly. Would be really helpful, if we could get a photo or screen capture of the failure condition.

Oldbitcollector (Jeff)
03-07-2011, 05:45 PM
Photo's were added to my message. I'm currently testing a solution created by kuroneko. So far so good. If I don't see the issue reappear by late tonight, (after 20-30 compiles) I think we've got it.

OBC

kuroneko
03-08-2011, 04:53 AM
This one confuses me, because the driver has always started correctly.
Relax and count yourself lucky. This particular setup has about 1 chance in 4 of failing which is skewed by the fact that not all cogs are equal after power-up (it took me a while but I collected all 4 cases). Anyway, it's the same issue Bill is facing. If you squeeze a waitvid into a fixed hub access raster, make sure that the hand-off point is where you want it. That said, I still don't see the PLL connection, you'd have the same issue with NCO driven video h/w.

potatohead
03-08-2011, 05:04 AM
If it's the same issue Bill is facing, then it's highly likely Jim just figured it was the PLL and moved on.

kuroneko
03-09-2011, 02:38 AM
Jeff reported that the issue disappeared which is probably as close as we can get to a solution (I did this as a blind fix as I don't have a VGA monitor available).

This is based on the driver in the Sunday, November 21, 2010 at 7:52:15 PM package.

blank_hsync mov vscl,_hf 'hsync, do invisible front porch pixels
waitvid hv,#0

mov vscl,_hs 'do invisble sync pixels
xor hv,#%10
waitvid hv,#0

neg href, cnt ' waitvid reference ...
cogid $ nr
add href, cnt ' ... relative to hub window
sub href, #(76 + 42) * 4 ' pixels start in (_hs+_hb)*4
shr href, #2 ' delta in frame clocks
and href, #%11 ' limit to 0..3
add href, _hb ' add base -> _hb + 0..3

mov vscl, href 'do invisible back porch pixels
xor hv,#%10
waitvid hv,#0

...

href res 1
The single res goes at the end of the file.

Pixels are latched between 2 hub ops which are in fact 2 slots apart (32 cycles). Meaning the waitvid has 16 cycles leg room in there somewhere. The code above will make sure that the waitvid stays in the middle of this windowA. Previously there was a condition that you got a non-blocking waitvid which means the pixel info was taken from the or instruction just before the waitvid. In this case the active value for pixels is $03030303 (coloror) which means colour 3 is used once and colour 0 three times. When you look at the relevant image you'll find that this is exactly what happens, two colours with a 1:3 ratio.

A or rather finishes 8..11 cycles before the next rdlong which also means the unrolled loop could in fact be a loop as add only consumes 4 cycles of the gap

Oldbitcollector (Jeff)
03-09-2011, 03:19 PM
I'm on two days of testing with this adjustment and it seems to have fixed the issue with the VGA object.

Well done and thank you!

OBC

potatohead
06-19-2011, 11:11 PM
I am unclear if a fixed distribution was posted, or not. Jeff, et al. if there is, can you link me to it, or post the corrected software here?

Thanks. PH :)

kuroneko
06-20-2011, 12:37 AM
I am unclear if a fixed distribution was posted, or not. Jeff, et al. if there is, can you link me to it, or post the corrected software here?
I'm not aware of a complete posting in this forum. Try this instead http://www.savagecircuits.com/forums/showthread.php?529-VGA-Spyhunter-test-using-Tile-Driver&p=4139&viewfull=1#post4139 (driver only).

Update: Please refer to post #206 instead.

Dr_Acula
07-31-2011, 02:21 AM
I've been testing out this code - see attached. The tv parameters are for 80Mhz and TV on pins P16-18.

The original demo has a tile driver with 256x240 and a picture of mario with the colors matched to the closest color of the 86 in the palette.

I thought I might run this through the Floyd Steinberg dithering and yes, it does come out better. See the pic of mario below 256x240.

Pushing things further and further...

Ok, 256x240 with tiles is a little fake in that this picture is about half white, so it does work with tiles where half the tiles are white (or the same as each other) but not with most pictures.

Limitations of the prop memory limit things to 256x96 with 86 colors, or 256x192 with 16 colors.

But I have resurrected this thread because I'm interested in how far things could go using external ram.

Firstly, what is the absolute best resolution for TV, either with a replicated tile, or with code created on the fly? For the full palette, is it 256x240, or have things been pushed further?

(The hypothetical demo might be a single small tile sitting in the middle of a white or black background).

Next question - how fast can you read lines off external ram?

Consider one of the smaller drivers we have - eg 256x96. That is 24k, and say you were reading at NTSC speeds of (I think) 30 frames a second, that is about 740k a second.

Now imagine a propeller chip dedicated to video. 3 pins for video, some pins for a high speed data link, and 24 pins devoted to driving a ram chip. With 24 pins on a SRAM, you can do this with one latch and read out data in 8k blocks. Speed will be limited by the ram chip itself (55ns sram needs one NOP).

Dedicate one cog to the high speed data link - buffer the data as it comes in, and store it to the ram in the back porch and at the end of the frame.

Dedicate one cog to reading data one line at a time off the ram and into hub. This greatly decreases the requirement for hub video ram. Maybe hub ram is instead used for the data buffer for data coming in?

And then there are the video driver cog(s). Only one minor change to the code - instead of the counter going up for the whole video buffer from 0 to 24575 (or whatever), it resets at the end of the line (256). Or maybe you have a little more of a buffer - maybe a few scanlines then everything can work out of sync and really capitalise on the parallel nature of the propeller.

Can we read data off the sram fast enough?

Well, with a 55ns ram, and for most of the time /RD is permanently enabled, so you are just clocking up the address lines and reading out data, that ought to be able to read at over 10megabytes per second.

Reading in 256x96 at 30 frames a second is around 740 kilobytes a second.

So I think there is scope to go higher than 256x96. Maybe even 320x240 with a 86 color palette.

I see on some other threads that the PropGFX gang are using 2 propellers to increase the video memory. I wonder if one propeller plus a 512k ram chip would work out cheaper and give you more ram as well?

Just to dream of what could be possible with 320x240 and F/S dithering and 86 colors is the Monet below.

ericball
08-01-2011, 02:42 AM
NTSC is 525 lines in 33.367msec, PAL is 625 lines in 40ms. NTSC line period is 63.555usec, PAL line period is 61.249usec. So the first question is how much data you can pull from external RAM in that time. The closer your pixel rate is to twice the colorburst frequency (NTSC: 3.579545 MHz = 455 pixels/line, PAL: 4.43361875 MHz = 422 pixels), the more likely you are going to get color artifacts.

Dr_Acula
08-01-2011, 02:56 AM
Thanks for that. 33ms for a frame and say a frame has 320x240 which is 77kilobytes. Number of bytes per second is 320*240*1000/33 which is 2.3 megabytes a second. Approx 429 nanoseconds per pixel. The SRAM is a 55ns part and needs one NOP in PASM.

This should be well within the limits of the ram chip.

I'm thinking of buffers so that timing is not so critical - eg one cog is reading data off the ram into hub, and the video cog is reading data from hub. Maybe enough of a hub ram buffer for a few lines of the picture. So that should avoid color artifacts.

As was pointed out on another thread, this is not going to work very well for fast moving graphics as there is limited time to update the sram with new video information.

Although, thinking this through, if at 320x240 the sram is nearly 10x faster than it needs to be, that might leave plenty of time.

The refresh rate for a video signal is 30x a second, and the frame rate for a movie with the sd card running flat out is around 7-8 frames a second. So there should be enough time to
1) keep a video buffer topped up from the sram
2) feed data into the sram from another buffer and
3) keep data coming into the input buffer.

With 24 pins devoted to running the sram, if the sram is disabled then that leaves all those propeller pins free to do other things, eg read data off an sd card. Or establish a fast parallel link with another propeller (maybe a 16 bit wide link?).

I have some boards on the way to test some of this - hopefully soon.

ericball - I've heard you have a high resolution driver available. I have the driver code but not the 'main' demo program. Do you have any code you might be able to share?

PS - as an aside, is your avatar a CRO tracing of a NTSC signal?