Newbie question about propeller video
bastibasti
Posts: 2
I am looking at this amazing chip and justsaw in the data sheet that there is a pal&ntsc generator inside. WOW.
my question: how many colours and what resolution is available in these modes? Can there be graphics (manipulate pixels) or text only?
my question: how many colours and what resolution is available in these modes? Can there be graphics (manipulate pixels) or text only?
Comments
I don't belive you can generate more colors·In PAL and NTSC without special addons or video generation circuitry or a·NTSC-RGB chip you can't generate much more than 68 without using the method in the 400 color driver topic.
I'm not so sure about PAL though, but I think it goes for it too.
did that Help you?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
Post Edited (Bob the Builder on a C64) : 6/11/2007 2:40:13 PM GMT
I was afraid it only gives 2/4 colours. I will have to keep on looking at cpld+sram thus its much more complicated
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
720x486 is a full overscan NTSC display, with interlaced color and interlaced vertical pixels. This driver has not yet been written as a full on bitmap display. There is not enough RAM in the prop to hold this large of a bitmap, unless you are planning to use tiles, or an emulation of character modes as seen on older computers. The propeller video generators will create this display though. The elements are all here. The timing in the Parallax driver is correct for both color and vertical pixel interlace, and works to that resolution.
If you look at the easy NTSC thread, I've got a very clear example of how to drive the propeller in high color (80, 96) mode bitmaps, thanks to CardboardGuru laying out how a display is built. Combining the two will yield your full NTSC display, given you address the RAM issue. I highly recommend looking that thread over as Cardboard did an excellent job of laying out the timing. It's really easy to understand. On the high-color demo thread, I've got a program that does artifacting for a lot of colors, but it's got a timing problem. In that package is an easily adjusted version of easy NTSC that will generate bitmapped displays at 80, 160, 256 and 320 pixels at either 96 pixels or 192 pixels. (no interlace on that one for either color or vertical scanlines, so the 320 mode won't quite give you what you are looking for)
There are also a ton of excellent display examples and working demos on the HYDRA CD. If you are into this stuff, I highly recommend the package. Andre' does an excellent job putting all of that together in a package that's easy to learn from. I've been having an excellent time! (wish I had more time actually!)
One COG might be able to build that display, given you load as many pixels as you can during the hblank, then continue to load them while the scanline is displaying. Not sure there would be time for tile logic though. That still leaves a RAM problem however.
I've driven the Parallax driver that high, but not with overscan. (640x384) The horizontal pixel clock was just fine. There is a screenshot of that here: http://forums.parallax.com/forums/attach.aspx?a=10530 The funky chars you see on the right are just parts of the ROM, as I did not have enough RAM to make the entire display addressable. Was just a timing test anyway to see if the chip could easily reach full NTSC resolution. (it can)
In that thread, I mentioned problems at 720. Well, I was not considering overscan at that time. The 640 pixel screen shot, which is a single frame, is actually what you are looking for. The prop looks to top out at about ~480 or so bytes per scanline, when just dumping them to the screen bitmap style. If you have processing for tiles and other things, that number drops to about 160, maybe 256, depending on how much on the fly pixel processing needs to occur.
Depending on what you want to display, such a driver might be fairly easy (tiles), or fairly complex (bitmap, sprites).
320 x 240 would be a much easier stretch. At that resolution, you can get the standard propeller colors and there is enough time for logic in the scanline. A single COG should be able to do a tile display at that resolution. If you look at how the Parallax driver is done, it's very clever in that one can make parts of the display directly addressable as a bitmap, other parts from ROM, still others from tile tables in RAM as well. Overall, this scheme makes good use of the Propeller RAM, with a nice balance of overall complexity
At the 320, you can still interlace the color, to get the full resolution without artifacts. And 320 happens without overscan too. So, you might really be looking at 360 pixels, if you choose to make the overscan area addressable in a fashion similar to the 720 top resolution.
From there, it's either generate video on the fly (see the Dodgy Kong game on the HYDRA side), or multi-cogs rendering and fetching from the SRAM, IMHO.
Post Edited (potatohead) : 6/11/2007 7:11:25 PM GMT
Essentially, you clock the waitvid instruction so that it's always drawing 4 pixels at a time, numbered 3,2,1,0. This way, you dynamically load the color information for all 4 pixels, thus they become directly addressable. Using the waitvid command in this way results in an additional mode beyond the 16 or 32 pixel, 2 or 4 colors at a time tile mode.
It is 4 pixels with one color byte per pixel. This does not yield 256 colors however. The reason for this is there are only 8 intensity levels present in the reference video output circult. Two of these are used for sync, leaving 6 for active video display. 6 intensities times 16 hues = 96 colors. Adding in the 6 intensities brings us to the 102 color standard palette generated by the prop video hardware. So some bits go unused. Depending on your RAM use, it might make sense to pack pixels in and decode them on the fly, mapped to a palette.
Having two of the intensities be sync signals, means being able to generate the entire display under software control, and that's just cool as it presents a lot of choices from there that would not otherwise be the case, given some hardcoding of these things as usually found in graphics systems.
Instead of loading a set of colors, then a set of pixels, you load only colors, and always display the same pixels! Done this way, each long you load from the display buffer holds the color information for the 4 on screen pixels. It's a much higher bandwidth use of the waitvid, requiring more bytes per line, which is what might require more than one COG to render a full on 720x486 frame.
That's been the basis for most of the interesting displays created so far.
It's possible to have multiple video generators generating displays independant of one another as well. There are 8 of them, so one could drive a VGA, and a TV, and do other things. In VGA mode, it's fairly easy to have two of them generate video at once, to build overlay graphics that are or'ed with the main image. This is done in the highres VGA driver with cursor driver posted here.
Doing this with NTSC is not yet a reality for some timing issues being discussed in the HYDRA part of this forum, as Mike indicated. These same issues prevent highcolor displays beyond the 102 from being reliable at this time. I'm working on that as I have time because I want to do NTSC overlays for a number of reasons. Not there yet however...
Sorry for the short book, I like this stuff!
Post Edited (potatohead) : 6/11/2007 7:15:39 PM GMT
I am starting to share your enthusiam.
But ... I feel like such a mellonhead sometimes. I have avoided looking at the video generators because there is so much available on the Prop and there is only "so much" time.
I am making a one pixel camera...(on a two axis servo) with the Education Kit's photoresistor. I am getting a dynamic range of about 10 bits. I actually have it all working except for the display[noparse]:)[/noparse]
If one were only interested in a low-res gray scale image... are there any tricks available?
...And what is the highest reported number of gray scale values available without tricks?
Rich
(goes off to try it)
Rjo, 12 greys are easily done. I know, in relation to your dynamic range, this is essentially nothing. However it is double the nothing you have now.
With some work, a 160x192x12 grey display will consume about 7.5K of RAM. A 160x96 display will consume half that.
This would take rewriting the display driver to display with ordinary waitvids, instead of high-color ones, to avoid excessive reads from HUB memory. This will allow time to unpack pixels from RAM. Essentially, one could pack two pixels into one byte, with each nibble holding the color index. Thought I might get 16, but that's just not the case. The real limit appears to be 11 greys actually. You can get one more, that should display on all TV's by mixing in the brighter blacker than black color, that is really supposed to be sync. Tried it on a coupla TV's here, both new and old. None of them had any problem with it, but it's outta spec...
Post Edited (potatohead) : 6/12/2007 8:10:39 AM GMT