Propeller and video, I haven't got a clue!!

Mike B.

I'm switching from the BS2P40 to the prop and so far love this thing!!· I'm not looking for some code fragments or a pointer to the object exchange to download the gee whiz shabang video object but rather some really BASIC words on what is involved in making the Prop generate video.·

· By the way, I just ordered the Propeller backpack and the 7" A/V color display from Parallax.· What kind of images can I display, how about storage (maybe the SD card "OS" I have seen posted on here).

· I assume (God, I hate that word!) one or more cogs would be dedicated to making the video..

· How about a thumbnail scetch of the process for a totally unprepared newbie??·
· Thanks, Mike B.·

w8an

I haven't played too much with the propeller video, but have tried it and it was very easy to get the demo to run. Unfortunately I don't recall where I got the download from.

Here's a link to a forum discussion of the video so may have some useful info for you.

Mike Green

Like most Parallax related programming, you start with the existing demo programs and modify them to do what you want.

The Backpack comes already programmed to produce a text-only display and the documentation for the Backpack describes how to use it.

There are several other video text-only drivers that would work with the Backpack. There's also the graphics driver in the Object Exchange which lets you generate graphics for a video display.

Underlying the graphics is a bitmap buffer that's output to the video display and you could just read a bitmap image from an SD card to the buffer. You would need to use a PC-based program to convert any JPG or BMP or other format images to the 2-bit bitmap images needed by the driver. There's a program for the Mac called GraphicConverter that's a sort of image Swiss-Army-Knife tool.

Attaching an SD card to the Backpack requires that you make an adapter that plugs into the Backpack expansion connector. As shown in the documentation for the various SD card drivers, this requires 4 Prop I/O pins and I'd recommend pull-up resistors although the drivers seem to work without them.

If you want a description of how the Propeller generates video, try the Hydra Manual. The author has provided an excellent introduction to NTSC video and how the Prop produces it.

localroger

Actually making the prop produce video isn't so simple; I've done some mods to tv_text myself (I made an object that mixes low resolution user defined characters that don't take so much RAM with the ROM font, but I didn't put it in the obex because of the big collective yawn). Basically the counter/timer arrays have a few features specifically designed to make it possible to generate video. In particular there's hardware support for the 3-resistor DAC that creates the analog video output and the translation of color and intensity values stuffed into a shift register into proper intensity and subcarrier phase shift on that analog output. The weird way the ROM font is laid out is intended for easy use by this video system. But at the hardware level it isn't much more than a shift register, a wait trigger for letting code when to load the shift register again, and some level translation stuff; a lot of heavy lifting still has to be done in PASM, which is only possible because of the determinant timing and absence of interrupts to mess up the signal. Much of the code in the tv driver would be hardware in any other system, which is pretty darn elegant when you consider how little you're wasting if you don't use the tv hardware that is there and decide to use your RAM for some other function.

Generally it takes 1 cog to generate a video signal. As Mike said there are a number of different approaches depending on whether you want a rich, many-color display that takes lots of RAM for the bitmap, or a terse text-only display that is frugal on frame buffer RAM. Also some very fancy work might involve more than one cog, but you usually see that more with VGA. Starting out it's best to pick one of the many video objects out there (really, start with tv_text, it doesn't bite) and see what it can do before asking what else you can do. The main limitations on prop video are color depth (due to limitations in the palette to phase shift conversion) and graphics resolution (due to the RAM required and the bandwidth to shove it into the shift register). It's generally agreed that you can't display something like a photograph on a Prop video display. But you can display a pretty impressive amount of text and retro-gaming compatible graphics if you want.

Post Edited (localroger) : 7/28/2010 3:40:46 AM GMT

potatohead

The process for the newbie:

Either build on a video circuit, or identify the one that is already there. You need to note the pins, and your system clock at a minimum. This is just handy so that you can deal with the many different video drivers out there. The demo board schematic is a download at the Parallax web site, in the Propeller downloads section.

From there, the next step is to run the demo programs that come with the Propeller tool. Graphics_demo.spin, and Graphics_Palette.spin are two to fire off right away.

Doing that involves insuring those compile with the Prop tool, and that you can communicate with your Propeller setup.

Each driver needs to know the system clock and which pins the video is setup on. How to modify this varies. Some drivers autodetect some boards. The text driver in my board does this, and works with a stock demoboard, HYDRA, and HYBRID boards. Most setups are some variation on these core layouts. The Parallax drivers have a set of longs you can put values into. Those are documented in the TV cog, called TV.spin.

Ask questions on that, if you don't see any joy. There is no extended writeup on that. The info you need to get that setup done for video circuits that are not like the demo board is contained in the Propeller Data Sheet download, and the Propeller manual. Since the drivers vary, writing up that topic can take considerable time. Better to ask and figure it out. This is your video coming of age test. Knock down a driver or two, and you will very rapidly be able to get drivers sorted for your hardware in the future.

Once you've run the demo, then it's time to play!! If it were me, I would modify the various graphics commands, you could run the commented graphics demo linked in my signature too. This is all about just checking out graphics, colors, text and such to get familiar with how things go.

From there, you try different drivers and games until you've got a good handle on seeing a video driver, and configuring it to operate on your hardware.

Then you are really not a newbie. Time to build stuff, break stuff, ask questions and do all the stuff the others are doing. [noparse]:)[/noparse]

Video on the Propeller involves these basic elements:

There is a TV cog. There can be more than one, because each cog can do video output. If you can find the RAM, propellers can drive multiple displays.

In the TV cog, the code builds the entire video signal in software, using the video generator, which as Localroger said, is just a fancy shift register, with some color capability intended for TV.

The most important thing to know about this is the numeric values contained in your screen buffer are not all legal colors for your display. Some of those are sync values, because the entire signal is done in software. 02 is black, not 00, on most drivers. That's what graphics palette is about. Just showing you the way around.

The drivers generally have to loop through a video frame, fetching data from the HUB, or generating it on the fly, feed that through the waitvid instruction, and keep looping to draw the signal.

There is time in a cog to do a signal, and also generate a simple display, such as a bitmap or text. Anything more complex than that requires the TV cog to fetch data from a buffer filled by other graphics cogs.

There are some limits on the Propeller. As resolution goes up, the time to fetch and shift data goes down. At some point, the data cannot be fed to the waitvid command quick enough, and the display breaks down. For TV, this is somewhere around 600 pixels, depending. Expanding that costs you cogs and ram.

Color is limited by the simple video circuit. Expanding that costs you pins and ram, and maybe cogs.

HUB memory limits the display detail and complexity. Expanding that costs you cogs and or pins.

Have fun!!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 7/28/2010 4:50:35 PM GMT

Rayman

I posted a video player here:

http://forums.parallax.com/showthread.php?p=842253

It was rather difficult to create the video.· I think I used a Photoshop macro to do a frame by frame conversion...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

ericball

Video isn't simple, but it's not impossible either (see my templates in my sig for a starting point). Note: the Backpack doesn't use a standard Demoboard output so you will need to modify any drivers to accommodate the different pin group and use of A16 / A17 along with the 10MHz crystal.

It should be noted that the Propeller doesn't have enough internal RAM for a normal framebuffer at more than low resolutions. Therefore most graphics drivers tend to be tile based, which brings in a lot of restrictions and complexity. Other limitations include the capabilities of the video circuit (especially when it comes to color), processing power, and the horizontal resolution of a composite video.

And although it is possible to synchronize multiple cogs to generate video, a single cog is often all that is required.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

markaeric

I've been having some issues grasping how the ROM fonts are used, and figured this thread is as good as any to ask, especially as I have not been able to find the info I need doing a search.

I understand how the fonts are combined, and mapped in memory. What I don't understand is how "the ROM font is laid out is intended for easy use by this video system." as mentioned not only by Local Roger, but also the Prop manual. The only way this explanation makes sense to me is if 2 of the 4 color combination per pixel are actually the same color. If this is the case, then that would mean that only a single foreground, and a single background color can be defined per 16 pixels (at least for composite) when utilizing ROM fonts. Is this correct?

localroger

Mark, that's right; the color registers are used to select which of the two interleaved characters is "displayed." There is a lot more detail about how this was done in the Hydra manual.

potatohead

Yes. What was done was character interleave. The pixels common to both characters are color 11, the pixels common to one character or the other are colors 10, and 01, and the background is color 00.

Color selection is used to differentiate between characters in the case of text, meaning only two colors should be in a text character cell.

Other cells, or tiles don't have to abide by that however, making all 4 colors available.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

Mike B.

Wow!·

· I have a large mouth (or so I have been told) but I think I may have bitten off more than I can chew to start with!! lol..

· I just recieved in the mail today the Parallax 7" mini NTSC/PAL video display and the Backpack and·they both·look very nice.· Maybe I should start off easy with just text.· The 2 page manual that came with the display says if no video signal is detected then only a blue screen is displayed.· Is that enough to use the Prop Backpack as a text only display for the moment??

· And thank you to every one that responded to my cry for help.· I will need to print out all these replys and refer to them as I expand my experience with the pro video adventure..

I'm off to chew on some of the video objects.· Thanks again

· Mike B.

markaeric

Mike B,

I personally think the text/tile graphics drivers are significantly more complex than the bitmap drivers, as weird as that may initially sound.

With bitmaps, you have an entire array of memory comprising of the image to be displayed that can more or less be read sequentially from the hub, and fed to the video cog. On the other hand, a text/tile driver requires a tile map array (my terminology may be incorrect), that basically holds the addresses to the appropriate graphics tiles (a tile is usually 16x16 pixels, and the entire screen is made up of a whole bunch of them) and color tables located in a different part of memory.

The benefit to using a tile driver verses a bitmap driver is that it can potentially reduce the amount of memory needed to generate the entire image - that is, as long as the each tile that makes up the image isn't different from all the other tiles. I hope that makes some kind of sense.

ericball

Mike B.

The Backpack is a specialized Propeller board with a lot of different ways to drive the output jack. Therefore your first stop should be the Backpack documentation and software. Once you have exhausted the possibilities provided by the included software then you need to make sure you understand the differences between the Backpack and the Demoboard (or Hydra) outputs so you can tweak any drivers to match the Backpack's requirements.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum