Is Hydra Platform Better Than Standart Parallax Video?
sobakava
Posts: 34
We were developing an hardware based on P8X32A processor with color composite video output. During the development we faced with insufficient memory issues and I found non-double buffered rolling TV driver on this forum (I really need to thank to the developer)
The design was almost complete but then we decided we need more than 4 colors at a time on the screen. I'm not talking about the tiles. I really need at least 8 colors to draw lines and put text. We decided to use the parallax after watching a pal/ntsc demo on youtube with a countdown display, start etc etc. It was looking so 'colorful'.
The resolution is also not very satisfying. I can barely fit the necessary graphics and the text.
So we decided to migrate to another method. Possibly a 32bit microcontroller @80-100MHz with larger RAM for graphics (>=128K) and external video encoder ie AD724, AD725 . But today I saw Hydra development kit videos. Especially car race game demo looks much more advanced than what we can do with the standard graphics driver.
What is the trick? Does Hydra use external memory or multiple P8x32As for additional FPGA/CPLD for grapchics?
This one is also have more colors at a time than we can have:
http://www.pyrofersprojects.com/blog/wolfenstein3d-on-a-parallax-propeller/#more-288
The design was almost complete but then we decided we need more than 4 colors at a time on the screen. I'm not talking about the tiles. I really need at least 8 colors to draw lines and put text. We decided to use the parallax after watching a pal/ntsc demo on youtube with a countdown display, start etc etc. It was looking so 'colorful'.
The resolution is also not very satisfying. I can barely fit the necessary graphics and the text.
So we decided to migrate to another method. Possibly a 32bit microcontroller @80-100MHz with larger RAM for graphics (>=128K) and external video encoder ie AD724, AD725 . But today I saw Hydra development kit videos. Especially car race game demo looks much more advanced than what we can do with the standard graphics driver.
What is the trick? Does Hydra use external memory or multiple P8x32As for additional FPGA/CPLD for grapchics?
This one is also have more colors at a time than we can have:
http://www.pyrofersprojects.com/blog/wolfenstein3d-on-a-parallax-propeller/#more-288
Comments
The color limitations are those of the video hardware which is limited to 4 colors out of a palette, each color using 8 bits. It's possible to use different palettes for each group of 16 pixels (horizontally). Some people have experimented with generating more colors, but you'll have to search this forum for threads on the subject.
The links on the Wolfenstein demo page are broken. Here's the revised link for the source code and here's the revised link to the discussion thread.
Wolf3d is dynamically drawn, using the cogs in parallel, "racing the beam" style. Any Propeller can put 64 color or 120 color bitmaps on the screen, though at a fairly low resolution, due to the 32K hub memory limit. Other high color drivers you see are done with tiles and sprites, again done to deal with the 32K limit, and they offer the full color set in most cases, again dynamically drawn.
The reference video driver is a great driver, but it does have 4 color / tile limits. All the propeller colors can appear on the screen though. Depending on your display needs, it might actually work.
Because of how the video sub-system works, propeller color is generally 2 color 4 color 8 bits of color, with those 8 bits varying in how many colors are produced, depending on what the author did to generate color. On TV, they all can be color. On VGA, it's 64 colors, unless a different video circuit is used for output.
Video has been done many different ways. We've got a PWM driver that will do 2K colors, though the resolution is 80 pixels / line or so.
We also have some LCD drivers that do high-color and high resolution displays with external RAM too. Those are more complex both circuit and code wise, but they are there.
It's all about trade-offs on the Prop. Much is possible, though rarely all three resolution, color depth and flexibility of object placement are realistic at the same time.
Make a mockup of your desired display and post it here. Many of us do video related things. Let's take a look at what is possible.
Also a note on composite color. With the Propeller you get: black ($02), white ($07), 6 shades of gray ($03-$06), ~80 muted colors ($xA-$xE), and 32 intense colors ($x8 & $xF). The remaining byte values are either grays or not stable.
We have 32KB external SPI SRAM on board from Microchip. I 'm not sure if it is helpful for using as external frame buffer memory with TV driver. It is probably possible to read several lines from this memory during HSYNC pulses.
I simply need 220 pixel or wider horizontal resolution with at least 3bpp (8 colors) Is it a realistic goal to implement with Propeller?
Do you need 8 colors on every pixel, or just 8 colors total? If 4 colors per display tile and you could get any 4 colors per set of tiles, would that work? All the Propeller colors could appear on screen, limited to 4 at a time per 16x16 or 16x32 tile area.
If that would work, you can use the standard Parallax driver to get resolutions up to 640 pixels horizontally, though color artifacts would be seen on high detail images. 256 - 320 pixels is more realistic for color.
Tiles can be reused too, covering the display entirely, just not providing unique pixels horizontally...
You can drive an LCD easily enough, and it's RAM can contain the display image.
OBC
There is the concept of the canvas. You can use the HUB memory to define small regions that can hold your graphics, and you can assign them palette entries when you display them up to 62 entries. That's a lot of colors present. Regions can be placed onto the TV display on a tile addressable basis, allowing for the result of elements, and each re-use having unique colors.
If desired, the ROM font can also be placed on a tile addressable basis, and it can have unique color entries too, though I didn't do that, just going for white on black.
Within a given region, which can be as small as a single 16x16 tile, the Parallax Graphics library (graphics.spin) can be used to draw text and graphics into it. Any number of regions can be defined, within the limits of the HUB memory. This is a use of the parallax driver not really seen much, if at all actually.
Finally, drawing can be performed off screen, then "popped" on screen when complete. Take a look at this one and your text / graphics requirements. If you want, you can adjust the display resolution higher or lower, simply by increasing the number of display tiles. Adjust 'hx" and "vx" as needed to shrink the pixels, before adding resolution. You can remove tiles easily enough, adjusting those to fill your display.
The idea behind this is to break your display into elements, define graphics regions for drawing, and place them on the display canvas, saving RAM that would be otherwise be used for blank pixels...
This is brilliant. I get very sharp picture using the code you have shared.
But I couldn't figure out how to use whole screen for drawing operations. I understand that I could define drawing regions.
I defined one 16x16 tile ( 256x256 pixel ) top-left aligned region. It covers left side of the screen.
Then I defined another 16x16 tiile right aligned region and it covers right side of the screen. So I covered almost all of the screen except bottom part of the screen. Display is 512x384 and my height is only 256 pixels. So 128pixels blank space at the bottom is not so important for me.
The problem is, I can't use both left and right regions together. If I draw something to the left region, a "ghost" image appears at the right one. It seems the memories are somehow overlapped.
Do you have an example how to use big (256x256 pixel) regions together?
Thank you for your help
When you put the same canvas into two different regions of the TV display, the pixels are duplicated. In the end, the HUB can only contain so many pixels.
You've got a few options:
1. Break your display into finer pieces, and use a few canvases mapped into regions where the pixels need to be. Place ROM text into the blank areas, or just leave blank areas.
2. Re-use display elements, using color to turn them on and off. Think those older gas plasma displays, or LCD that had everything already drawn, just activated or not. (stereo displays are a great analogy)
3. Lower screen resolution so that canvases can contain fewer pixels per screen region.
4. Single buffer things. I'll have to review the code I posted up this weekend to see whether or not, I've done that. I don't think I did. In my blog, I've got some single buffer and partial buffer code demonstrations that are pretty effective. This can double the number of pixels you can place in the HUB.
Do you have a sketch, or some visual of the display you desire? If so, send it to me. There might be other options.
Regions are broken up into tiles. Each tile is 16 pixels x 16 pixels, and that's 64 bytes. 16 tiles consumes 1Kb of HUB RAM. A 256x256 pixel display is 16x16 tiles, which is 256 tiles, consuming 16K RAM. That's half the HUB for just that one canvas.
It is not possible to use the entire screen for drawing independent pixels. That simply requires too much RAM. It is possible to fill the screen with graphics, if some graphics are reused, perhaps with a different color, and or there is text from the ROM present on screen. The pixel data comes from the ROM, which does not consume HUB RAM.
I have a thought that I can connect the SSD1963 (from our DVI Graphics Shield) to a AD725 and thereby have NTSC output in 24-bit color...
Was looking into doing this, but then found a VGA to NTSC adapter for ~$15 that makes this solution not very cost effective since the AD725 is about $10...
I reduced the number of tiles and adjusted them to get two 160x240 regions side by side forming a 320x240 display. I also modified the Tv parameters to let this display fill whole screen. This is much much better than my previous resolution. I can fit anything I want into the screen. I already ported my old GUI and graphics to this new configuration. I switch between display regions according t the drawing coordinates.
My only concern is color depth now.
The Prop 2 however, when it does debut, should have HDMI capability (@ least in 480i mode i would suspect). There is a list of it's unofficial specs floating around on the forums and on a (semi broken) wiki, look for it around spring/summer 2013.