As for the interpolators, that would be a small size(?) 8 bit adder attached to the output pins register I presume. With a mode selector as to whether writing to the Cog's output address performs an 8 bit add or just loads a 32 bit word. Something like that?
Of course that would mean the 8 bits are predetermined. Would need a different register and some mappings to make it dynamic.
I do like the idea of only three Cogs for displaying a rich colour image. And obviously only one Cog would be needed for grayscale images.
I'm in agreement on the idea of there not being too much dedicated video hardware. Doing as much in software as we can, while using the hardware to make the really hard stuff possible seems the right way to go.
Being able to sync the color clocks is a good example of this, that also will have other uses.
I like Phil's idea too. Don't know if I would trade it for the proposed changes up thread though. For a micro, those are pretty nice really. If this were a ready option, that ends up just being a switch, then I think it's probably good. Not only will it open up more video modulation options, but it's another output mode for what is just a serializer and that fits well with the general utility of the on chip functions. Getting too specific with those seems a mistake. Maybe that's just me and existing Prop I expectations.
Somehow I think the improved color resolution possible with the interpolaters at the expense of "any pin, any use" does not seem worth it. A mode like that, in addition to consuming three of 8 total cogs, would require lots of compute for dynamic displays. I don't know how many real tasks would require that kind of display. Adding an external DAC seems the way to go with that stuff. How would folding in other objects work with such a display engine?
With composite on NTSC, and with the proposed changes, pixels could still be blended to increase the available color space, just as is possible on the Prop I right now. The additional memory means we could interlace these signals for higher color / intensity spaces on PAL / VGA also. Frankly, that's a very nice color space for a micro. Exceeding that would easily justify external hardware, ala PROPGFX type projects.
Maybe I'm a bit too retro, but there is a line where there is quality and Prop I lies just below it for a lot of people, or perhaps it's just good but too much work or comes with too many RAM limits. (I like it though, but for the limited grey scale) Where we will be in Prop II, I'm not sure that will be as true. Going beyond that then sets the expectations for true color type quality, and having that on board seems to exceed the scope of what is and what is not a micro -vs- a full on computer type graphics capability.
Then there is using the Prop as a GFX subsystem. Seems to me that's a case for external hardware anyway, so again we are left with how much is enough on chip?
My mind still wanders back to using these generators in tandem, and that's going to be easier with the sync operation proposed. So, two of them working together means additional color space, and or flexibility in terms of different resolutions on screen, in motion at the same time, depending on display needs.
It will be possible then to have bitmapped graphics at a moderate resolution, higher color depth, with overlayed higher resolution, lower color depth objects in just two cogs, with no fancy scan line renderers necessary. (might be the best option anyway though)
The higher compute speed of the Prop II, combined with the full scan line buffer capability proposed means we might see compressed bitmap displays being possible also. So background graphics could exist compressed and be largely static, with dynamic objects folded into the render engine, just before waitvid. That combination could be potent where saving display memory is concerned. That would consume just one generator, leaving the others for sound and such.
One thing about using them together is that they are additive. Nice for transparent overlays, also nice for lots of things happening on a black background, or perhaps one with large, muted colors.
Is there a cheap silicon solution to having them be able to have priority over one another for output to the pin?
Say we've got one that's building a low resolution screen. Another one is displaying higher resolution sprites or just bitmaps that are dynamic. If we can only add, then the color choices that make sense are limited. Or, we use just one and build a scan line renderer like we've seen on Prop I.
If, one could be designated as being the priority one, or if there was a priority scheme, then multiple ones could all combine to make a complex signal, each focusing on it's coded strength. Lots of bit mashing operations go away, leaving us with a three COG display, for example, that has a lot of straight forward utility in terms of the types of things being drawn on screen, compute necessary to manupulate them, and display RAM to manage them.
Edit: Just re-read that and thought perhaps it's easier to just say it this way.
If multiple video subsystems are rendering to the same pins, provide for an option where they don't just add electrically like they do now, but have them output their signal at the exclusion of the others. If the signal level is zero, or maybe some arbitrary value, then ignore that output. This ends up being hardware overlay, similar to older sprite systems where multiple sprites overlap, and one of them gets the display. Priority determines which one thus:
COG 1 yyyyzzzzaaaabbbb
COG 2 00ddd000ee0000f0
RESULT yydddzzzeeaabbfb ; WHERE COG 2 HAS "PRIORITY" OVER COG 1
potatohead, has a point, I guess it depends on how many want it to be able to do hi-colour tv or vga outputs.
I think just increasing what we have now for composite, ( ie 5 pins instead of 3 like mentioned way back ) will still have lots of great results.
without the extra Ram hit, leaving ram spare for other tasks like loading from USB thumbs etc + graphics, as you don't want all the ram to be used for display only.
I really like this proposal of an 8 bit interpolator on each COG's VSU. If I understand it correctly, it kind of reminds me of the old Amiga HAM graphics modes.
It's a somewhat generic chunk of hardware that can be used for video, but could also be used for other things.
I can imagine them being used for waveform sound output allowing you to have higher quality audio in less memory, or maybe even to drive RF signals or motor controllers?
My question It is Graphic Controler You construct else in my opinion it is to much advanced.
It is fine to have many colors but to what cost (3x8+2 Pins) in my opinion is waste of resources.
And all constructions that eat upp Pins is not alternative.
If any adition ad programablity/free resources from COG it is welcomme else it is BAD!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
That's one of the tradeoffs for a rich colour set. You will still be able to select each bit as an output just the same as now. So, if you only want to use 17+2 pins then no problem, and if you only want 10+2 pins then no problem there either.
This could be used with Component signalling also.
Actually, there is no reason why the digital signals can't be piped into a laptop LCD. They are pretty simple to clock colour data into. Then LVDS is just an interface chip away.
My question It is Graphic Controler You construct else in my opinion it is to much advanced.
It is fine to have many colors but to what cost (3x8+2 Pins) in my opinion is waste of resources.
And all constructions that eat upp Pins is not alternative.
If any adition ad programablity/free resources from COG it is welcomme else it is BAD!
A Propeller will not be able to do everything at once. It's a choice of allocating its resource to one thing or another. Hopefully it will excel at both even if not both together, as long as the possibilities don't consume resources when not used it will be okay.
Where two functions need the same resources there is always the multiple Propeller solution - That's the principle behind PropGFX and I would expect anyone wanting 'amazing video' to take that route and be prepared to lose I/O for other purposes.
We all would like 8:8:8 color depth, but we also know that we are not likely to have enough hub RAM to do much of a display, right?
If it's paletted color, like it is now, there's plenty of memory, right?· Assuming we still have 64 outputs on Prop2, I think 24 bit color would be great!·
Should be plenty of memory for a 256 color palette 320x240 image· (only 78 out of 256 kB, right?)
You said.
""A Propeller will not be able to do everything at once."
Not evryting BUT so much is posible
It was litle of my point. But if VIDEO generator is strikly constructed to that funktion it is waste of resources.
Only open construction to more possiblites have full use. Else it waste COG power/posiblites
1 COG > VIDEO = VGA
2 COG > Video =· WAV function 2
3 COG > Video =· X function 3
4 COG > Video =· Y function 4
5 COG > Video =· Z function 5
etc.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
I tend to agree with Praxis, if folks need this level of graphics, they ought to buy a FPGA/CPLD and roll their own or use something like the OMAP3530 processor.
The Prop is just not meant to compete with GPU's period.
I'm not advocating competing with a GPU. I'm just asking for more accurate color control. I feel what I was asking for was not something·super powerful, or even really all that much. What I was asking for is the color control equivolent to what the first iterations of VGA had back in 1985. Which was 256 colors at a time from a palette(CLUT) that had 8:8:8 colors in it. This requires 64k for a 320x200 display and ~1k for the CLUT.
The Prop 1 does already have hardware on it that is catered towards output to a VGA or NTCS ports (the VSU).
Chip mentioned changes to that hardware for the Prop 2 that would make it better. I was asking for what I thought was a minor tweak. It turned out to be not as minor as I thought, but Chip offered up a compromise feature that also happens to have uses aside from just video. In my opinion, this is a good back and forth discussion. Do we really need to have all the negative replies?
I already know I can add specialized hardware to achieve better video/color if I want, I already know the Prop 2 is not going to be competing with GPUs or even much simpler specialized display chips. This thread seems to be all about making the Prop 2 as great as can be within reason. Appealing to the users of Prop 1, which consists of a not insignificant amount of people doing video/graphics (helped along by the Hydra I'm sure).
This chip has a broader audience than a typical embedded microprocessor would. I think it's because of how unique it is, but also because it has features that apply to so many different targets including video/graphics/games.
Post Edited (Roy Eltham) : 9/9/2008 4:38:17 PM GMT
@Roy: I couldn't agree more. So long as any added video circuitry doesn't a) preclude other stuff that's been mentioned, and b) can be used for non-video stuff (I'm sure there are many here who'll take-up that challenge), then it can only be a good thing.
That said; I'm probably not someone who'll be making any use of it in my projects - but will enjoy all the demo's immensely
(jeez; this is one thread you can't stop reading for a day - it's too fast moving!)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
Well how many customers (industrial) are currently using the Prop?· If you do· not provide a backward compatible platform you could end up having them mad at you?
I am not interested in graphics. If I really need graphics, I will get a cheep PC. I know that some people want better graphics for games. In the embedded market, I do see a use for graphics for man-machine interfaces. Given that the Prop II will have more RAM and more speed. My priority list is more GOGs, built in ADC, more IO pins, and internal pull-up resistors. I am probably tilting at windmills since Chip likes graphics.
Roy Eltham said...
This requires 64k for a 320x200 display and ~1k for the CLUT...
1 kByte is half the CogMemory! So much RAM only for the ColorTable which you use normally only on one Cog's Video Generator.
But the ColorTable must be write accessible to write the colors in. If it is also made Read accessible, and the access is fast, then this RAM can be the CogRAM extension which many ask for (not for code, only for data).
Or perhaps it can be reused for a big FIFO for the InputSerializer.
In My opinion discssion on Video capablites has litle with Props utility power for the large group of users.
The best comment has Ale "Rayman, A palette of 256 out of 65536 colors would be enough, even for video, and those are 6 bits per color."
For my and I think that most users more important is how many PINs I will have after I use Video/VGA mode.
In control aplications Video is use only to relatively simple Terminal. Most important what and how I can control My Robot else Machine and how many external components I must have to build complete Controler.
I does not want to be negative and I know that people which GAME programing on Propeller will have more Video power.
But in My opinion Prop II will be not only GAME procesor.
Thanks
Ps. In advanced constructions is always about one Pin very little
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
Roy Eltham said...
...What I was asking for is the color control equivolent to what the first iterations of VGA had back in 1985. Which was 256 colors at a time from a palette(CLUT) that had 8:8:8 colors in it...
I thoguht that VGA came out in 1987 and had 6bits per color? Before then was good old EGA, CGA etc.... [noparse];)[/noparse]
I remember the 6x3 bit color DAC from programing in VGA in the older dos days.
Roy Eltham said...
...What I was asking for is the color control equivolent to what the first iterations of VGA had back in 1985. Which was 256 colors at a time from a palette(CLUT) that had 8:8:8 colors in it...
I thoguht that VGA came out in 1987 and had 6bits per color? Before then was good old EGA, CGA etc.... [noparse];)[/noparse]
I remember the 6x3 bit color DAC from programing in VGA in the older dos days.
You are correct, my memory of that timeframe is faded some (I was in high school then). I forgot that VGA originally had 6bit per component color, of course later in the early 90s and beyond things changed to include 8bit per component palettes among other things.
Any enhancements to the VSUs for NTCS and VGA would be happily welcomed by me, even if it's not up to the levels I would ideally prefer.
I've just had a discussion with a friend who suggested that raw LCD displays may be linear colour. This would mean that realtime mixing/rendering engines can be far more accurate, ie: No need to deal with gamma conversions. However, I suspect that level of access will prolly be hidden behind a CRT equivalent gamma of ~2.5.
Ok, back to extreme colour depth output. I don't personally care how many bits per pixel would be the maximum as long as the onchip real estate consumption is linear. I too am an industrial type. I'll never be wanting more than minimal colour but a single Cog outputting the whole display is desirable. Piping out a serial data stream to a LCD is another likely direction.
Roy Eltham said...
... of course later in the early 90s and beyond things changed to include 8bit per component palettes among other things.
Officially, those are beyond VGA as a screen mode. But yeah, it's still the same old RGB signalling on a VGA connector, and being able to specify a screen mode by it's resolution and bit depth rather than by a name or mode number is an obviously superior solution.
Okay lets compare the difference between these different color depths.
With a image. (Allowing any color anywhere no dithering)
Currently the PropI has a 6 bit (2:2:2) support which returns an image of this:
Figure A) 6bit (2:2:2)
A proposed 16bit PropII RGB color support would look something like this:
Figure 15bit (5:5:5)
The extended 32bit PropII RGB output would look something like this:
Figure C) 24bit (8:8:8)
Seems like a lot of talking about going from Figure B to Figure C.
Honestly I'm more worried about the NTSC/PAL output.
[noparse];)[/noparse]
While I'm open to the BEST everything! I think that the 16bit output would work the best for the PropII.
If anyone needs say, HDMI's 10:10:10... or SVGA's 8:8:8 Then just use more then one COG for video output.
With the currect prop Bagger's has been able to get true color out of it by using 3 COG's *a single COG for output. *Corrected
16bit would work for 98% to 99% of users both robotics controls & computing/gaming.
Best fits the balance of the rest of the chip. (Would you connect a 80gig hard-drive to an AppleII? *lol*)
And doesn't place the extra overhead memory & silicon costs for the larger 32bit entry CLUT tables.
Ah, that's the other item I asked about ... what colour is the eye more sensitive to, the answer, apparently, is they are all equal. But ... blue spacial resolution is Smile. Blue shading is easier to fake with dithering. So, that's why blue is given least priority in uneven colour ratios.
That said, if real time dithering is going to be used then having all three primary bit depths the same is far more important than using every last available pin for extra colour depth. Otherwise there is extra work in dithering with the distorted ratio.
That said, if real time dithering is going to be used then having all three primary bit depths the same is far more important than using every last available pin for extra colour depth.
Evan
I agree. I was also worring about the color jitter in the Grey Scale if not all colors had the same bit depths.
While at higher bit depths it is harder to notice any color jitter in gray, at the lower ones it's a real eye sour.
Anyone remember 3:3:2 8-bit TrueColor's annoying purplish grey?
Things would look good and then you would have some slight color in your gray from when the RGB values didn't line up perfectly.
"rrr_ggg_bb" Thanks to the unmatched number of bits in the Blue. Gray's don't line up correctly at all spots of the of the scale.
Edit: I'd take 12 bit color (4:4:4) over 14bit uneven color (5:5:4)...
5:5:5 is ideal. [noparse]:)[/noparse]
With the currect prop Bagger's has been able to get true color out of it by using 3 COG's for output.
One COG does the Red (6bit), another outputs the Green (6bit) and the last outputs the Blue(6bit).
I got·15bit·colour out of 1 COG ( but it could have just as easily been 24bit, I just reserved 9 pins as I needed to attach other stuff, with 64 pins it will easily go back to 24bit if required. [noparse]:)[/noparse], I just had to manually bit bash the data to the ports, without using the video unit, So it's really just down to peoples own needs from it.
15bit produced decent images, even using DXT1 the output looked fine ( see attached imge ) yes there's some banding, and yes, it's DXT1 so I got 256x192 15bit colour out of a prop [noparse]:)[/noparse]
Praxis said...
I see that the PropII Graphics Chip thread is still moving along [noparse]:)[/noparse]
I know, isn't it great!!!!
Seriously though, while this is a valid discussion, Baggers has clearly demonstrated that the limitations with Prop I video hardware can be overcome with a bit banged video generation routine and an external DAC for composite output.
The major limitations are RAM and Speed and it's as simple as that, Prop II will overcome both of these issues.
You've got to remember at the end of the day this is a microcontroller and not a graphics chip, the fact that it will generate video as easily as it does is what won some of us over in the first place.
Don't get hung up on colour depth and resolution, the Prop II will be able to do most things with relative ease.
You've just gotta love Parallax for throwing this open to the floor in the first place......
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
I keep thinking that when Chip started this thread, he probably already exceeded most of
the posted expectations and wanted to see response.. [noparse]:)[/noparse] Bet he already has a fully-working
prototype and is giggling to read this thread..
<my theory, could be wrong, but something tells me.....>
Betcha he's tinkered with it since. The multi-threading / LMM discussion sure was interesting. A tweak or two and that stuff just flies.
On graphics, really I'm quite happy with the earlier stuff proposed up thread. Heck, I'm happy with what the chip does now. Tricks remain, but RAM is tight. On the next one, we've got RAM, so more good stuff is gonna happen, just as it has happened with retro hardware being pushed with software over the years.
As long as the video stuff is not too dedicated, we all will be surprised at what eventually comes out of it once a few dozen brains hack on it for a while [noparse]:)[/noparse]
In my earlier post, I mentioned the priority bit. Was just thinking, if somehow the extrapolators ended up in the thing, having a priority system would solve most dynamic display problems with a mode of that type. Just use it for the background, then overlay simpler images with additional COG's, or if it isn't there, use more than one COG to do lots of display memory lean tricks for dynamic and colorful displays!
Talking about graphics is always fun! What happens happens. I harbor no doubt about Chip not getting carried away with that element of it. Sometimes the discussion triggers things that might prove quite useful in the end, even if it did get somewhat off track. Not sure there is any practical way to avoid that!
Comments
Of course that would mean the 8 bits are predetermined. Would need a different register and some mappings to make it dynamic.
I do like the idea of only three Cogs for displaying a rich colour image. And obviously only one Cog would be needed for grayscale images.
Evan
Being able to sync the color clocks is a good example of this, that also will have other uses.
I like Phil's idea too. Don't know if I would trade it for the proposed changes up thread though. For a micro, those are pretty nice really. If this were a ready option, that ends up just being a switch, then I think it's probably good. Not only will it open up more video modulation options, but it's another output mode for what is just a serializer and that fits well with the general utility of the on chip functions. Getting too specific with those seems a mistake. Maybe that's just me and existing Prop I expectations.
Somehow I think the improved color resolution possible with the interpolaters at the expense of "any pin, any use" does not seem worth it. A mode like that, in addition to consuming three of 8 total cogs, would require lots of compute for dynamic displays. I don't know how many real tasks would require that kind of display. Adding an external DAC seems the way to go with that stuff. How would folding in other objects work with such a display engine?
With composite on NTSC, and with the proposed changes, pixels could still be blended to increase the available color space, just as is possible on the Prop I right now. The additional memory means we could interlace these signals for higher color / intensity spaces on PAL / VGA also. Frankly, that's a very nice color space for a micro. Exceeding that would easily justify external hardware, ala PROPGFX type projects.
Maybe I'm a bit too retro, but there is a line where there is quality and Prop I lies just below it for a lot of people, or perhaps it's just good but too much work or comes with too many RAM limits. (I like it though, but for the limited grey scale) Where we will be in Prop II, I'm not sure that will be as true. Going beyond that then sets the expectations for true color type quality, and having that on board seems to exceed the scope of what is and what is not a micro -vs- a full on computer type graphics capability.
Then there is using the Prop as a GFX subsystem. Seems to me that's a case for external hardware anyway, so again we are left with how much is enough on chip?
My mind still wanders back to using these generators in tandem, and that's going to be easier with the sync operation proposed. So, two of them working together means additional color space, and or flexibility in terms of different resolutions on screen, in motion at the same time, depending on display needs.
It will be possible then to have bitmapped graphics at a moderate resolution, higher color depth, with overlayed higher resolution, lower color depth objects in just two cogs, with no fancy scan line renderers necessary. (might be the best option anyway though)
The higher compute speed of the Prop II, combined with the full scan line buffer capability proposed means we might see compressed bitmap displays being possible also. So background graphics could exist compressed and be largely static, with dynamic objects folded into the render engine, just before waitvid. That combination could be potent where saving display memory is concerned. That would consume just one generator, leaving the others for sound and such.
One thing about using them together is that they are additive. Nice for transparent overlays, also nice for lots of things happening on a black background, or perhaps one with large, muted colors.
Is there a cheap silicon solution to having them be able to have priority over one another for output to the pin?
Say we've got one that's building a low resolution screen. Another one is displaying higher resolution sprites or just bitmaps that are dynamic. If we can only add, then the color choices that make sense are limited. Or, we use just one and build a scan line renderer like we've seen on Prop I.
If, one could be designated as being the priority one, or if there was a priority scheme, then multiple ones could all combine to make a complex signal, each focusing on it's coded strength. Lots of bit mashing operations go away, leaving us with a three COG display, for example, that has a lot of straight forward utility in terms of the types of things being drawn on screen, compute necessary to manupulate them, and display RAM to manage them.
Edit: Just re-read that and thought perhaps it's easier to just say it this way.
If multiple video subsystems are rendering to the same pins, provide for an option where they don't just add electrically like they do now, but have them output their signal at the exclusion of the others. If the signal level is zero, or maybe some arbitrary value, then ignore that output. This ends up being hardware overlay, similar to older sprite systems where multiple sprites overlap, and one of them gets the display. Priority determines which one thus:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Post Edited (potatohead) : 9/9/2008 5:37:39 AM GMT
I think just increasing what we have now for composite, ( ie 5 pins instead of 3 like mentioned way back ) will still have lots of great results.
without the extra Ram hit, leaving ram spare for other tasks like loading from USB thumbs etc + graphics, as you don't want all the ram to be used for display only.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
It's a somewhat generic chunk of hardware that can be used for video, but could also be used for other things.
I can imagine them being used for waveform sound output allowing you to have higher quality audio in less memory, or maybe even to drive RF signals or motor controllers?
My question It is Graphic Controler You construct else in my opinion it is to much advanced.
It is fine to have many colors but to what cost (3x8+2 Pins) in my opinion is waste of resources.
And all constructions that eat upp Pins is not alternative.
If any adition ad programablity/free resources from COG it is welcomme else it is BAD!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
This could be used with Component signalling also.
Actually, there is no reason why the digital signals can't be piped into a laptop LCD. They are pretty simple to clock colour data into. Then LVDS is just an interface chip away.
Evan
A Propeller will not be able to do everything at once. It's a choice of allocating its resource to one thing or another. Hopefully it will excel at both even if not both together, as long as the possibilities don't consume resources when not used it will be okay.
Where two functions need the same resources there is always the multiple Propeller solution - That's the principle behind PropGFX and I would expect anyone wanting 'amazing video' to take that route and be prepared to lose I/O for other purposes.
Should be plenty of memory for a 256 color palette 320x240 image· (only 78 out of 256 kB, right?)
You said.
""A Propeller will not be able to do everything at once."
Not evryting BUT so much is posible
It was litle of my point. But if VIDEO generator is strikly constructed to that funktion it is waste of resources.
Only open construction to more possiblites have full use. Else it waste COG power/posiblites
1 COG > VIDEO = VGA
2 COG > Video =· WAV function 2
3 COG > Video =· X function 3
4 COG > Video =· Y function 4
5 COG > Video =· Z function 5
etc.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/9/2008 1:52:55 PM GMT
EDit: there were 256 out of 262144 (18 total bits, so 2^18), my bad. (just not that much better...)
Post Edited (Ale) : 9/10/2008 10:20:51 AM GMT
If that level of performance is required then move it off the prop and use external components.
Just a thought.
The Prop is just not meant to compete with GPU's period.
The Prop 1 does already have hardware on it that is catered towards output to a VGA or NTCS ports (the VSU).
Chip mentioned changes to that hardware for the Prop 2 that would make it better. I was asking for what I thought was a minor tweak. It turned out to be not as minor as I thought, but Chip offered up a compromise feature that also happens to have uses aside from just video. In my opinion, this is a good back and forth discussion. Do we really need to have all the negative replies?
I already know I can add specialized hardware to achieve better video/color if I want, I already know the Prop 2 is not going to be competing with GPUs or even much simpler specialized display chips. This thread seems to be all about making the Prop 2 as great as can be within reason. Appealing to the users of Prop 1, which consists of a not insignificant amount of people doing video/graphics (helped along by the Hydra I'm sure).
This chip has a broader audience than a typical embedded microprocessor would. I think it's because of how unique it is, but also because it has features that apply to so many different targets including video/graphics/games.
Post Edited (Roy Eltham) : 9/9/2008 4:38:17 PM GMT
That said; I'm probably not someone who'll be making any use of it in my projects - but will enjoy all the demo's immensely
(jeez; this is one thread you can't stop reading for a day - it's too fast moving!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
jm.
John Abshier
But the ColorTable must be write accessible to write the colors in. If it is also made Read accessible, and the access is fast, then this RAM can be the CogRAM extension which many ask for (not for code, only for data).
Or perhaps it can be reused for a big FIFO for the InputSerializer.
Andy
In My opinion discssion on Video capablites has litle with Props utility power for the large group of users.
The best comment has Ale "Rayman, A palette of 256 out of 65536 colors would be enough, even for video, and those are 6 bits per color."
For my and I think that most users more important is how many PINs I will have after I use Video/VGA mode.
In control aplications Video is use only to relatively simple Terminal. Most important what and how I can control My Robot else Machine and how many external components I must have to build complete Controler.
I does not want to be negative and I know that people which GAME programing on Propeller will have more Video power.
But in My opinion Prop II will be not only GAME procesor.
Thanks
Ps. In advanced constructions is always about one Pin very little
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/9/2008 11:32:37 PM GMT
I thoguht that VGA came out in 1987 and had 6bits per color? Before then was good old EGA, CGA etc.... [noparse];)[/noparse]
I remember the 6x3 bit color DAC from programing in VGA in the older dos days.
256 CLUT out of 6:6:6...
en.wikipedia.org/wiki/VGA
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
Any enhancements to the VSUs for NTCS and VGA would be happily welcomed by me, even if it's not up to the levels I would ideally prefer.
·Roy
Ok, back to extreme colour depth output. I don't personally care how many bits per pixel would be the maximum as long as the onchip real estate consumption is linear. I too am an industrial type. I'll never be wanting more than minimal colour but a single Cog outputting the whole display is desirable. Piping out a serial data stream to a LCD is another likely direction.
Evan
Evan
With a image. (Allowing any color anywhere no dithering)
Currently the PropI has a 6 bit (2:2:2) support which returns an image of this:
Figure A)
A proposed 16bit PropII RGB color support would look something like this:
Figure
The extended 32bit PropII RGB output would look something like this:
Figure C)
Seems like a lot of talking about going from Figure B to Figure C.
Honestly I'm more worried about the NTSC/PAL output.
[noparse];)[/noparse]
While I'm open to the BEST everything! I think that the 16bit output would work the best for the PropII.
If anyone needs say, HDMI's 10:10:10... or SVGA's 8:8:8 Then just use more then one COG for video output.
With the currect prop Bagger's has been able to get true color out of it by using 3 COG's *a single COG for output. *Corrected
16bit would work for 98% to 99% of users both robotics controls & computing/gaming.
Best fits the balance of the rest of the chip. (Would you connect a 80gig hard-drive to an AppleII? *lol*)
And doesn't place the extra overhead memory & silicon costs for the larger 32bit entry CLUT tables.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
Post Edited (Ym2413a) : 9/10/2008 1:53:06 PM GMT
That said, if real time dithering is going to be used then having all three primary bit depths the same is far more important than using every last available pin for extra colour depth. Otherwise there is extra work in dithering with the distorted ratio.
Evan
I agree. I was also worring about the color jitter in the Grey Scale if not all colors had the same bit depths.
While at higher bit depths it is harder to notice any color jitter in gray, at the lower ones it's a real eye sour.
Anyone remember 3:3:2 8-bit TrueColor's annoying purplish grey?
Things would look good and then you would have some slight color in your gray from when the RGB values didn't line up perfectly.
"rrr_ggg_bb" Thanks to the unmatched number of bits in the Blue. Gray's don't line up correctly at all spots of the of the scale.
Edit: I'd take 12 bit color (4:4:4) over 14bit uneven color (5:5:4)...
5:5:5 is ideal. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
15bit produced decent images, even using DXT1 the output looked fine ( see attached imge ) yes there's some banding, and yes, it's DXT1 so I got 256x192 15bit colour out of a prop [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I know, isn't it great!!!!
Seriously though, while this is a valid discussion, Baggers has clearly demonstrated that the limitations with Prop I video hardware can be overcome with a bit banged video generation routine and an external DAC for composite output.
The major limitations are RAM and Speed and it's as simple as that, Prop II will overcome both of these issues.
You've got to remember at the end of the day this is a microcontroller and not a graphics chip, the fact that it will generate video as easily as it does is what won some of us over in the first place.
Don't get hung up on colour depth and resolution, the Prop II will be able to do most things with relative ease.
You've just gotta love Parallax for throwing this open to the floor in the first place......
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
the posted expectations and wanted to see response.. [noparse]:)[/noparse] Bet he already has a fully-working
prototype and is giggling to read this thread..
<my theory, could be wrong, but something tells me.....>
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Betcha he's tinkered with it since. The multi-threading / LMM discussion sure was interesting. A tweak or two and that stuff just flies.
On graphics, really I'm quite happy with the earlier stuff proposed up thread. Heck, I'm happy with what the chip does now. Tricks remain, but RAM is tight. On the next one, we've got RAM, so more good stuff is gonna happen, just as it has happened with retro hardware being pushed with software over the years.
As long as the video stuff is not too dedicated, we all will be surprised at what eventually comes out of it once a few dozen brains hack on it for a while [noparse]:)[/noparse]
In my earlier post, I mentioned the priority bit. Was just thinking, if somehow the extrapolators ended up in the thing, having a priority system would solve most dynamic display problems with a mode of that type. Just use it for the background, then overlay simpler images with additional COG's, or if it isn't there, use more than one COG to do lots of display memory lean tricks for dynamic and colorful displays!
Talking about graphics is always fun! What happens happens. I harbor no doubt about Chip not getting carried away with that element of it. Sometimes the discussion triggers things that might prove quite useful in the end, even if it did get somewhat off track. Not sure there is any practical way to avoid that!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net