Shop OBEX P1 Docs P2 Docs Learn Events
Is Hydra Platform Better Than Standart Parallax Video? — Parallax Forums

Is Hydra Platform Better Than Standart Parallax Video?

sobakavasobakava Posts: 34
edited 2012-07-04 09:39 in Propeller 1
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

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2012-05-04 07:21
    The Hydra uses the same video circuitry as does any other Propeller board with TV output. It's just a simple digital to analog converter using 3 resistors. All the rest of the work is done inside the Propeller's video generator and in the software. There are some Propeller video driver objects that use external memory. Mikronauts is one source with their Morpheus board which uses two Propellers, one to mostly do the video and the other to do other things. This is particularly an issue when doing VGA text and/or graphics where the data rates are very high and screen buffers can exceed the 32K available.

    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.
  • potatoheadpotatohead Posts: 10,261
    edited 2012-05-04 07:37
    The Hydra platform isn't superior.

    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.
  • ericballericball Posts: 774
    edited 2012-05-04 09:10
    The Propeller Video Generator is based around the WAITVID instruction which feeds the shift registers used to drive the output pins. WAITVID takes two parameters: a four color LUT and up to 16 pixels (in 4 color mode). How those pixels and colors get set is up to the video driver, which is all software. The challenge is then space (storing the color and pixel data) and speed (retrieving the color and pixel data for each WAITVID). Composite video also has restrictions on horizontal resolution without generating color artifacts.

    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.
  • sobakavasobakava Posts: 34
    edited 2012-05-07 06:47
    I'm using static graphics for instrumentation (multi color boxes and text titles inside them) Because of we don't need very high processing power for other tasks, I can use most of the CPU time for TV graphics. Unfortunately I don't know how to do it.

    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?
  • potatoheadpotatohead Posts: 10,261
    edited 2012-05-07 09:00
    It is, depending on the display. A simple bitmap won't fit. Propellers can dynamically draw the display, using the RAM where needed. The complexity of that may be too high, which is why a mock up might help. One example is the tile driver in my signature. It can do 320 pixels, and tiles can be placed around the screen, and updated as needed, not requiring the full amount of RAM.

    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.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-05-07 09:21
    Depending on what size text you are looking for, you may way to take a look at the recent work which has been done on the Ranquest video object (By JTCook) There is now a TV version as well as a VGA version in the works.

    OBC
  • potatoheadpotatohead Posts: 10,261
    edited 2012-05-07 16:31
    I've attached an example of how to do graphics windows onto a high-resolution Parallax Graphics screen. The program is set for demo board. It runs a graphics screen that is 512x384.

    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...
  • sobakavasobakava Posts: 34
    edited 2012-06-29 06:58
    Potatohead,

    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

    potatohead wrote: »
    I've attached an example of how to do graphics windows onto a high-resolution Parallax Graphics screen. The program is set for demo board. It runs a graphics screen that is 512x384.

    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...
  • potatoheadpotatohead Posts: 10,261
    edited 2012-06-29 08:43
    Thanks.

    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.
  • RaymanRayman Posts: 14,827
    edited 2012-06-29 08:54
    Just a note in case you need more... You mentioned the AD725...
    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...
  • sobakavasobakava Posts: 34
    edited 2012-07-04 04:54
    I agree with you. AD725 is quite expensive and if I could high-res and 4bpp or more color depth VGA video using parallax or another cpu, using a VGA to NTSC adapter would be more convenient.

    Rayman wrote: »
    Just a note in case you need more... You mentioned the AD725...
    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...
  • sobakavasobakava Posts: 34
    edited 2012-07-04 04:59
    Thanks for the idea potatohead.

    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.




    potatohead wrote: »
    Thanks.

    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.
  • RinksCustomsRinksCustoms Posts: 531
    edited 2012-07-04 09:39
    the HYDRA demos were written by demo coders (JEDI knights of coding), most of us (pretty much all of us) aren't on the same level of coding. They make the prop do things bordering impossible for the specs of the prop 1. If you have the HYDRA manual (which comes with a CDROM of all the code and software mentioned in the manual), the demos you saw on youtube are on the CD. I viewed them in the prop IDE and the code was amazing! I could not make sense of the majority of what they wrote for those demo games, it was that cryptic! It resembles an encrypted message in one language that got scrambled with another language encoding, and smothered in a generous amount of gibberish.

    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.
Sign In or Register to comment.