Font and Graphics in 1024x768!!!

cgracey

Here's the latest 1024x768 tile driver, now with mouse cursor support.

The Propeller's built-in font was designed to run in this mode, but for a long time it wasn't looking possible. I think this driver would be great for these self-hosting languages that are being discussed.·Note the 3D bevel characters and easy-to-read 64x24 text. There's also some graphics in this example just to show that it can be done. This demo was thrown together, but it exercises the tile driver thoroughly. It shows the two built-in mouse cursors, plus a custom one.

The driver itself is 271 longs w/12 VARs. It requires 6KB of RAM for the tile array.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 11/12/2006 12:06:38 PM GMT

Jim C

WOW! This is unbelievable.

This combined with all the memory extension stuff, an Prop OS on-board, and main stream languages coming on strong >> the possibilities are hard to fathom. Things seem to be rapidly moving these days.

Jim C.

potatohead

I wondered about the ROM text size. It seemed really big for the resolutions possible at the time I got my prop. Good job Chip. There is enough here for some really great graphical UI's now.

Bill Henning

Excellent!

Very impressive Chip!

Makes for some interesting possibilities...

william chan

I thought that all graphics had to be based on the 16x16 tiles, since the interface to the VGA is based on the tile driver.
But I saw the vector graphics in a small window that seems to be 1 pixel thin.
How is that possible?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

rokicki

Well, you get a certain number of tiles, and each location on the screen can point to any tile.
Tiles can be characters (from the ROM) or they can be your own bitmap. If I wanted to draw
a 128x64 bitmapped area, I would just allocate 8x4 tiles (32 total tiles) for my bitmap and
point the display tile pointers there for that section of the screen.

This is very flexible, lets you mix text and graphics very nicely.

Fabian Nunez

This is really cool, but I have a question. I see that you're making use of the INA register as a destination register, which the propeller manual says should only be used as a source register. I realize that the INA register is really just a memory location and so this is simply a cool optimization trick, but what happens if I have the Prop wired into a circuit and data arrives at any pin, won't that change the value of the INA register and thus corrupt the value stored in it?

cgracey

Only when INA is a source register does it contain the pin input states. As a destination register, it·reads and writes·a shadow RAM register. So, you are accessing two physically different registers between source and destination within the INA register address.

Fabian Nunez said...
This is really cool, but I have a question. I see that you're making use of the INA register as a destination register, which the propeller manual says should only be used as a source register. I realize that the INA register is really just a memory location and so this is simply a cool optimization trick, but what happens if I have the Prop wired into a circuit and data arrives at any pin, won't that change the value of the INA register and thus corrupt the value stored in it?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 11/15/2006 9:27:02 AM GMT

Fabian Nunez

Oh, I see. And since you're always doing either "mov ina, <blah>", "cmp ina, #<blah>" or "djnz ina, #<blah>" there's never a risk of the value getting nuked by an external signal.

Clever [noparse]:)[/noparse]

DaveF

I am nowhere near even knowing what you are talking about because I am just starting out with the prop, BUT.... Does this mean that there is hope for increasing the resolution of the video output (composite)?

If so, how high could it go?

That would be HUGE for me!

Mike Green

The big problem with increased resolution of the video output is the actual limits of standard video. You've got maybe 240 lines vertically that can be doubled with interlacing to make somewhere around 480 lines. You can get maybe 640 dots horizontally. The existing TV driver (TV.spin) can already handle that. You might be able to squeeze a little more out horizontally, but it's not likely to look good. The current text driver uses a 16 x 32 font which gives a 40 x 13 character screen. You can use the graphics driver to do vector-based characters that are smaller than the text driver's. A completely new text driver could use a smaller font (like 8 x 8) to get more characters on a line, but it's not clear how good it would look on most displays.

How much resolution do you really need and is there a particular reason why you wouldn't be able to use VGA instead (which has much better bandwidth).

Bean

If you want to do color the limiting factor is that there is only about 180 color burst cycles per line. This really limits the number of horizonal pixels to about 360.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com

"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·

DaveF

so are you saying that the propeller can give a TV as much as it can handle? I thought I heard the resolution was something like 188x82 or something. I am pretty sure a tv can do 640x480.

I am no expert though...

And what about colors? Any way to get more colors?


EDIT::::· I see that I was told 320x200 for the prop.· Sorry!
But·I want more!!!!!

·· any chance of it?

Post Edited (DaveF) : 11/16/2006 3:48:08 AM GMT

DaveF

I am looking to do graphics.... animations, etc and I HATE the jagged edges!!! It just does not look professional.

And one step futher, I could use more colors for better depth in the graphics.

Mike Green

Yes, the Propeller can give a TV as much as it can handle.

The current TV display driver provides 40 x 13 "tiles" each consisting of a 16 x 16 pixel tile whose pixels can have one of four colors which can be selected from any that the monitor can support. For text, each tile is normally considered to be one character. The graphics routines (graphics.spin) can draw vector characters that cross tile boundaries. Look at the graphics_palette.spin sample program in the Propeller Tool's sample library. It displays the range of possible colors and lets you see the number associated with whatever color the mouse cursor is positioned over. The graphics routines come with a demo program that does show you what the vector characters look like.

Again, both the TV and the VGA display is made up of tiles. The Propeller hardware does the video generation and limits the colors for any pixel to be one of the four defined for the pixel's tile. The colors in the palette for the tile can be chosen from any that the monitor is capable of, but only four can be chosen for any given tile. Adjacent tiles can have completely different colors.

Mike Green

The Hydra (probably due out this week) comes with a graphics engine (actually several) designed for gaming that demonstrates what the Propeller chip is capable of for TV display. Anything much more complex than that would rapidly run up against primarily memory capacity issues. It is possible to attach significant external hardware to the Propeller to provide additional memory for video buffering and off-chip video generation that would support modestly higher resolutions (mostly more colors) on TV displays. Again, you're up against fundamental limitations of the display format. Remember that, if you start with a higher resolution picture, the display itself will blur adjacent pixels which does smooth the image a bit and make it look better than it really is.

The primary task of the graphics engine in the Hydra software is to produce high enough resolution graphics (again about 500+ x 200+ practically) without using a bitmap which would fill up most of memory. The VGA graphics routine for 512 x 384 pixels is an example of that. The bitmap takes up over 1/2 of the memory. There isn't enough memory for a full resolution VGA bitmap (1024 x 768) which the video generation hardware is fully capable of doing.

Post Edited (Mike Green) : 11/16/2006 4:09:38 AM GMT

ciw1973

As the ouput pins from each cog are OR'd together, it's actually possible to generate a full 64 colour (this isn't a spelling mistake, I'm British) VGA display. It involves using three cogs, all outputting VGA to the same set of pins, but with the colours set so each cog is effectively working on a different pair of output pins - one for the red pair, one for the green pair and one for the blue pair. As a consequence of the way memory would need to be organised, you'd be dealing with the colour planes independently, allowing some nice simple colour effects. If you wanted 1024x768, you'd obviously need to double up the number of cogs required to buffer and output the image.

This is on my to-do list, but the full 1024x768 windowed GUI and new language runtime I'm working on are keeping me busy at the moment, not that I'm getting any real time to work on them either right now. Anyone else fancy having a go at a 64 colour VGA driver using this technique?

DaveF

Thanks guys, I am starting to understand much more about the possibilities. What I need is a MANUAL! Is there documentation about this? I do not see anything about it in my prop manual... How did you learn about it?

Please point me to whatever documentation exists for designing graphics on the prop so I can learn. That will do it for me!

Chip- sorry for hijacking your thread! I did not mean to get off on a tangent like this!!

Dave

ciw1973

I expect the Hydra book will include all the details you'll ever need for controlling the cog's video hardware, along with plenty of practical examples.

From a development point of view the video hardware is actually pretty simple stuff, as you'd expect with only two dedicated registers and an assembly instruction, but there's also the issue of clocks (and PLLs) and timing which are so fundamental to the operation of the thing, that you need to have a good understanding of these before you can actually get started. You also need to have an understanding of the basics of video generation. All that said, I'm sure everything could be covered in a short (10 pages or so) quickstart guide as long as it included a range of suitable examples.

Until the Hydra book is released or such a quickstart guide appears, you'll have to dig through the (generally well commented) example code and objects released by Parallax and others and experiment, which to be honest is half of the fun.