Graphics and tv objects

DaveC3

I am new and trying to understand what is happening under the covers of the propeller.

I see how to start and send commands to the above objects objects. I can not see how the graphics object passes the display information to the TV object. I would like to develop a custom display driver. I am not sure how the inter-communication works.

Thanks

Dave

Mike Green

The graphics object directly writes into the display bitmap in main memory. When the graphics object is initialized, the address of the bitmap is passed to it.
See the setup routine in the graphics object.

Rayman

Look here:

http://www.rayslogic.com/propeller/Programming/GraphicsDemo.htm

potatohead

To roll your own driver, you need:

1. Address of passed parameters. At a minimum, this is the display buffer, if you don't locate it inside of a COG. You do this with the PAR register. When a COG is started up, PAR contains the address of a block of parameters located sequentially in memory.

Inside your driver COG, you read these from the HUB, using known offsets from that address passed by PAR.

Higher level objects either set these parameters, or write information to areas of memory pointed to by these parameters.

Display mode, number of lines, etc... are all things that would be set by higher level objects. Writing information to areas of memory is like the screen memory.

2. Display driver consumes these parameters and is responsible for drawing the display on the display device. If this is a TV or VGA type display, it has to do *everything*. That's sync and pixels both. On the Propeller, this is done via the waitvid instruction where some pixel color and intensity values are sync and others are colors and intensity for actual active display pixels. For TV, the intensity values 00 and 01 are sync, with an actual black pixel being 02.

One the display driver is up and running, it can largely just do it's thing without further intervention. If the driver needs to change modes, then it also needs to be looking at the passed parameters in the HUB every frame so that it can respond to mode changes from higher level objects.

3. Some plan for how the video system is supposed to work. It's a great idea to layout your screen memory and pixel depth / resolution requirements and how they impact the available amount of Propeller RAM. The nice thing about this is you get to do whatever you want to. The not so nice thing is that you have to do whatever you want to!

Easy pixel depths are one bit per pixel, two bits per pixel and 8 bits per pixel. Those are directly supported by the waitvid instruction. Other depths, such as 4 bits per pixel, will require some bit mashing to be done in the display COG. At higher resolutions there isn't much time for this.

Memory requirements for full on bitmap display are pretty steep, with 160x192 resolution easily consuming 16K of RAM for one display page. This is why lots of drivers do character mode displays, tiles or sprites so that display data can either be used sparingly or generated on the fly to conserve RAM.

Part of your planning then includes the need to sort out what display capabilities are needed.

Doing sprites generally takes more than one COG to do.

In that scenario, more passed parameters are necessary for the various COGs to know how to do things together. One primary display COG will draw scanlines to the display device, while other COGs are building those scanlines based on the display information given to them.

I think Bamise has written up a nice multi-cog tutorial. There are several single COG display drivers laying around that are commented well enough.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

DaveC3

Mike, Rayman, Potatohead

Thanks for the replies. This gives me something to study. Your help is greatly appreciated.

Dave

potatohead

IMHO, the best way to get rolling on your own custom display is to go through a few of the existing ones, and add comments, tweak until you see how it all comes together.

The Parallax reference driver, that is distributed with the Propeller Tool is very capable, but it's also complex. One nice thing about it is that it does both NTSC and PAL, and does interlaced video. If you use that one as a basis for your own custom display, you get a lot of flexibility built in from the start.

If these things are not so important, then I recommend Cardboardgurus SIMPLE_NTSC. You can find it in the HYDRA threads. I really liked this one because it does not do interlaced video. That output is very similar to older game consoles and computers of the 80's and is well suited to the Propeller. Downside is resolution being limited to about 256 pixels (with some minor color artifacts) and non-interlaced vertical output, so that's about 200 lines for NTSC. No PAL, if you go this route though.

Upside is the timing is easy to understand. I have used this one for several of my display projects with good results. Those are posted here as well, and are commented. One of the better ones is the 8x8 NTSC display. In that one, I've got the non-interlaced timing expressed mathematically, making it easy to setup lots of basic bitmap and text (character mode) displays. Those drivers are not so good, if you are looking to do the equivalent of hardware sprites.

Baggars, and a few others, have gone the other route, building off the Parallax one. Video output is higher and better quality, in that you can get the full 720x486 interlaced NTSC video out of it, and it does PAL too. Downside is the complexity and relative lack of room in the COG to do your own stuff. Going this route means a simple tile or bitmap display, or multi-COG for sprites and such. One nice thing about that driver is that many of the parameters you will need are already done, leaving you to just work on your waitvid loop and multi-cog communication, if you need that.

I had three big hurdles. One was just understanding the overall structure of things. I posted on that one. Another was dealing with waitvid. I highly recommend building a dumb display, that does just a border and a black or grey frame. Once that's all done, then you can work on your waitvid loops and decide how you want to plug graphics data in. Tiles, bitmap, sprites, characters (text), etc... all require various computations to end up on the screen. Tiles, bitmaps and text can be done on one COG, with the minor HUB memory and pointer update operations happening in a simple waitvid loop.

1. read pixels from HUB
2. operate on them (rev instruction maybe)
3. feed them to waitvid
4. update pointers for next pixel block.

You will see that in a lot of drivers.

Sprites are kind of ugly because they have to be masked into a scanline, and that takes time and many and / or / xor operations, depending on what you want the sprites to do. Transparent sprites take the most bit mashing. Going there basically means a multi-COG driver, or one that is speed limited where sprites are updated during the vertical blank. (time when the TV / display beam is returning to the top to begin a new frame)

You can also do sprites in software. If you go for a simple bitmap display, it will use the most RAM, but your higher level objects can then draw sprites in software. This is how the Parallax driver works.

Generally, the disadvantage of that is high RAM consumption and limitations on color and or limitations on achieving flicker free sprite movement.

Anyway, have fun! Coding video stuff is lots of fun, IMHO!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net