It's 32bit colors in a palette (CLUT), so it doesn't have to be that much memory. The palette could be 32, 64 or 256 entries (whatever really). The pixels in the bitmap or tile would still be 8bit or smaller.
It's really about having more precise color control.
OT: People get obsessed about what's hot and forget about what works.
For example, interlace gets a bad rap. Yet, it's superior to non-interlaced in every way when it comes to motion storage/transmission. Interlacing basically halves the bandwidth for a given resolution/framerate. This even applies to rasterisers where interlacing can be processed as half the vertical resolution per pass(frame).
Admittedly, since LCD is an always ON display technology, it's very difficult for LCD to correctly display interlaced video. Maybe this is what is causing all the marketing behind the reinvention of the terms progressive and interlace from two encoding systems into screen-mode labels.
Roy Eltham said...
It's really about having more precise color control.
I know, but the only time you'd want more than 16 bit is for high quality images. 12 bit colour is good enough imho.
16bit color has very noticable banding especially in the green and blues. 12 or 14bit is going to be even worse banding. It becomes very noticable if you do any kind of gradiants. I'd like to play around doing 3D graphics and lighting with the Prop 2, and I'd love it if we could have higher than 16bit color. Especially if it's not very expensive silicon-wise, which is seems like it wouldn't be if they are already going to do a CLUT system with 16bit entries, seems trivial to also support 32bit entries.
I'm not sure. Your color depth is only as good as your DAC.
Also the RAM limit would make 24bit image space hard to store.
I don't know. Maybe it's overkill? If you could work around the CLUT and make the thing display every color per frame. You'd have enough RAM for a 320x240 24bit (8x8x8) bitmap space. With 31k left over for code.... This would also take up 24 output pins. (not including sync)
I've got mixed feelings on this one.
While having more of something is good. At what point is it overkill? Also if you needed more bit depth output would syncing two cogs together work better? One COG could output R(8) and G(8) and the other COG could output B(8) and Sync.
I'm more excited about the new NTSC video output honestly. [noparse]:)[/noparse]
Roy Eltham said...
I'd like to play around doing 3D graphics and lighting with the Prop 2, and I'd love it if we could have higher than 16bit color.
What you really want to do here is perform the rendering with linear lighting, 32 bit might just about be good enough for that. And then the framebuffer to output processing can translate from 32 bit linear RGB to 16 bit output RGB. They'll be roughly equivalent I suspect.
Praxis said...
I think this thread has lost the plot.....
Should the next Propeller be code-compatible?, does question relate to the source code or the binary image?
I would also ask (Parallax) what markets do you see (or want to target) for the PropII?
This relates to both. [noparse]:)[/noparse]
I think the conclusion has already been made to NOT keep compatibility to allow for new features and a more open design.
You said. "This would also take up 24 output pins"
""
I don't know. Maybe it's overkill? If you could work around the CLUT and make the thing display every color per frame. You'd have enough RAM for a 320x240 24bit (8x8x8) bitmap space. With 31k left over for code.... This would also take up 24 output pins. (not including sync)
""
If I understood Chip corectly. It is not 24 pins but only 3+2. 3 internal R2R DACs to 3 pins and 2 H,V sync pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
You said. "This would also take up 24 output pins"
""
I don't know. Maybe it's overkill? If you could work around the CLUT and make the thing display every color per frame. You'd have enough RAM for a 320x240 24bit (8x8x8) bitmap space. With 31k left over for code.... This would also take up 24 output pins. (not including sync)
""
If I understood Chip corectly. It is not 24 pins but only 3+2. 3 internal R2R DACs to 3 pins and 2 H,V sync pins.
Hello Sapieha. [noparse]:)[/noparse]
I'm not all that sure. But if there was a built in internal DAC that would help save some pins. [noparse]:)[/noparse]
The only thing is... I think if the DAC was internal, it would have to be built into each pin set configuration.
Since the propeller doesn't have dedicated pins for anything. All pins are the same and can be configured to any input or output.
Building a DAC inside the prop would mean every pin's in/out pad would have to have a DAC built into it... [noparse]:([/noparse]
If I understood You corectly.
WR/RDLONGS cog_address,hub_address < will have Decitated Registers in COG.
If that is corect then I have one more sugestion to it.
WR/RDLONGS (RegIndexPair),cog_address,hub_address for nested posiblites
Ps. Very handy to move data HUB to HUB and much more.
With one more flag in. ··· TRLONGS count,increment flags < Increment only cog_address, hub_address else both ·············································· (Mostuseful·HUB_Addres with transfer block protocols ···············································from and to I/O. With HUB flag on it is posible to fill block ··············································· with specific value
··· TRLONGS count,RELOADcount,increment flags
I have posiblites to Circular Bufer in only a few instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
[noparse][[/noparse]quote]Also, for your 16bit variant it would be 5:5:4 14bit color with 2bit HV sync, I would prefer this to be 4:5:5 for the color part (since human vision is typically more sensitive to blue shades).
The rods, which are responsible for determining the brightness of a colour, are more sensitive to red than blue (theyre most sensitive to green of course). This is why full blue looks darker than full red, which looks darker than full green
OwenS said...
The rods, which are responsible for determining the brightness of a colour, are more sensitive to red than blue (theyre most sensitive to green of course). This is why full blue looks darker than full red, which looks darker than full green
This may be true for full brightness, but the issue is different brightness levels of each. When the brightness drops the eyes color sensitivity shifts more towards the blue/greens. So you can perceive more different shades of green and blue than you can percieve different shades of red. Green is the most sensitive, followed by blue, then red for different shades. That is why 16bit computer setups usually use 5:6:5 for 16bit.
It was my understanding that the Prop 2 would have some form of DAC capability on each pin. Wouldn't this allow us to use less pins? I'm not really sure how it would work? Would you use PWM or something?
I hadn't considered an internal D/A converter with R2R setup before. But it does seem possible to have a particular Cog to set it's outputs to inputs then enable a weak resistor network instead. Getting everything in place seems a tad convoluted and will add a bunch of new configuration registers.
I'd always been thinking along the lines of having a built-in delta-sigma circuit (For lower sample rates) to match the new sigma-delta A/D converters. However, this could also work for video but you'd have to sacrifice display resolution to get any decent colour depth with this method on a 160 MHz part.
The rods, which are responsible for determining the brightness of a colour, are more sensitive to red than blue (theyre most sensitive to green of course). This is why full blue looks darker than full red, which looks darker than full green
This may be true for full brightness, but the issue is different brightness levels of each. When the brightness drops the eyes color sensitivity shifts more towards the blue/greens. So you can perceive more different shades of green and blue than you can percieve different shades of red. Green is the most sensitive, followed by blue, then red for different shades. That is why 16bit computer setups usually use 5:6:5 for 16bit.
But remember that sRGB is logarithmic. As such, you want to focus on sensitivity at the bright end of the spectrum, since thats where the extra bits matter most. Additionally, the point at which blue becomes dominant is arround about the point the cones become deactivated (As in, arround the point we stop seeing in colour). This is why the 3:3:2 8-bit encoding was used on some 8-bit home computer systems, like the MSX.
I remember the old 8bit 3x3x2 layout on the MSXII. [noparse]:)[/noparse]
Also a very standard 256 color VGA palette back in the days was the 3x3x2. It was called 8-bit True color.
Sorry I've been gone for a while. You guys are talking about some interesting things!
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?
Well, what about putting 8-bit linear interpolators on each R,G, and B? Would this make sense? Then, rather than needing three bytes on a pixel-by-pixel basis, we would send data to the video shifter on a change-related basis. To get sharp detail, you would have bursts of high-bandwidth data, while low detail, but rich color transition, would hardly cost anything in terms of display memory.
I would propose putting an 8-bit interpolator into each cog's video circuit. This would mean that in order to do 8:8:8 bit RGB, you would use three cogs, synchronized, each driving an 8-bit port with external R2R ladders. The problem with internal video DACs is that they cannot be built on every pin economically, so we would have to have dedicated pin groups for video, instead. This is against our religion, you know.
Some of you here can speak to the practical worth or worthlessness of this idea. Now's the time to add something like this to the design.
Would there be any way for the video machinery, via a programmable selection, to feed a FRQx register from the LUT instead a pin group? At 160MHz, a duty mode counter wouldn't need much filtering.
This would work great for baseband video where the luminance BW is less than 5MHz. Maybe all NTSC/PAL video could be single-pin-oversampled. At least, there could be such a·mode. At 160 MIPS, you could just use duty cycle, alone, modulated in software, to draw anything in NTSC/PAL. The video circuitry could help·maintain the timebase, though. I'll do some experiments with this oversampling idea. I'm sure it will work, but I'm not sure of the effects of the high-frequency·on the average NTSC/PAL display, especially if it has a tuner being used.
Phil Pilgrim (PhiPi) said...
Chip,
Would there be any way for the video machinery, via a programmable selection, to feed a FRQx register from the LUT instead a pin group? At 160MHz, a duty mode counter wouldn't need much filtering.
Comments
It's really about having more precise color control.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
For example, interlace gets a bad rap. Yet, it's superior to non-interlaced in every way when it comes to motion storage/transmission. Interlacing basically halves the bandwidth for a given resolution/framerate. This even applies to rasterisers where interlacing can be processed as half the vertical resolution per pass(frame).
Admittedly, since LCD is an always ON display technology, it's very difficult for LCD to correctly display interlaced video. Maybe this is what is causing all the marketing behind the reinvention of the terms progressive and interlace from two encoding systems into screen-mode labels.
If it's expensive then don't do it.
Also the RAM limit would make 24bit image space hard to store.
I don't know. Maybe it's overkill? If you could work around the CLUT and make the thing display every color per frame. You'd have enough RAM for a 320x240 24bit (8x8x8) bitmap space. With 31k left over for code.... This would also take up 24 output pins. (not including sync)
I've got mixed feelings on this one.
While having more of something is good. At what point is it overkill? Also if you needed more bit depth output would syncing two cogs together work better? One COG could output R(8) and G(8) and the other COG could output B(8) and Sync.
I'm more excited about the new NTSC video output honestly. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
Evan
Should the next Propeller be code-compatible?, does question relate to the source code or the binary image?
I would also ask (Parallax) what markets do you see (or want to target) for the PropII?
This relates to both. [noparse]:)[/noparse]
I think the conclusion has already been made to NOT keep compatibility to allow for new features and a more open design.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
http://forums.parallax.com/showthread.php?p=749719
Well started a new thread, as I don't have the admin access to move posts [noparse]:)[/noparse] lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
You said. "This would also take up 24 output pins"
""
I don't know. Maybe it's overkill? If you could work around the CLUT and make the thing display every color per frame. You'd have enough RAM for a 320x240 24bit (8x8x8) bitmap space. With 31k left over for code.... This would also take up 24 output pins. (not including sync)
""
If I understood Chip corectly. It is not 24 pins but only 3+2. 3 internal R2R DACs to 3 pins and 2 H,V sync pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/8/2008 2:30:45 PM GMT
Hello Sapieha. [noparse]:)[/noparse]
I'm not all that sure. But if there was a built in internal DAC that would help save some pins. [noparse]:)[/noparse]
The only thing is... I think if the DAC was internal, it would have to be built into each pin set configuration.
Since the propeller doesn't have dedicated pins for anything. All pins are the same and can be configured to any input or output.
Building a DAC inside the prop would mean every pin's in/out pad would have to have a DAC built into it... [noparse]:([/noparse]
Thanks Sapieha.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
It was one of my proposo to have R2R DACs on every pin.
But VIDEO if I understood Chip it will have DACs on VIDEO generator directly in COG.
Ps. 24+2 -5 Is more that SOME!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/8/2008 3:25:46 PM GMT
If I understood You corectly.
WR/RDLONGS cog_address,hub_address < will have Decitated Registers in COG.
If that is corect then I have one more sugestion to it.
WR/RDLONGS (RegIndexPair),cog_address,hub_address for nested posiblites
Ps. Very handy to move data HUB to HUB and much more.
With one more flag in.
··· TRLONGS count,increment flags < Increment only cog_address, hub_address else both
·············································· (Mostuseful·HUB_Addres with transfer block protocols
·············································· ·from and to I/O. With HUB flag on it is posible to fill block
··············································· with specific value
··· TRLONGS count,RELOADcount,increment flags
I have posiblites to Circular Bufer in only a few instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/8/2008 6:39:06 PM GMT
That's not my understanding matey, I almost certain it will use an external DAC as per Prop I.
If you think about it you would need a DAC for every cog, I don't think that's what Chip had in mind.....
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
Post Edited (Coley) : 9/8/2008 6:24:51 PM GMT
The rods, which are responsible for determining the brightness of a colour, are more sensitive to red than blue (theyre most sensitive to green of course). This is why full blue looks darker than full red, which looks darker than full green
lol, was gonna say, I always thought it was green shades the eyes were more sensitive to [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I'd always been thinking along the lines of having a built-in delta-sigma circuit (For lower sample rates) to match the new sigma-delta A/D converters. However, this could also work for video but you'd have to sacrifice display resolution to get any decent colour depth with this method on a 160 MHz part.
Evan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Also a very standard 256 color VGA palette back in the days was the 3x3x2. It was called 8-bit True color.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
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?
Well, what about putting 8-bit linear interpolators on each R,G, and B? Would this make sense? Then, rather than needing three bytes on a pixel-by-pixel basis, we would send data to the video shifter on a change-related basis. To get sharp detail, you would have bursts of high-bandwidth data, while low detail, but rich color transition, would hardly cost anything in terms of display memory.
I would propose putting an 8-bit interpolator into each cog's video circuit. This would mean that in order to do 8:8:8 bit RGB, you would use three cogs, synchronized, each driving an 8-bit port with external R2R ladders. The problem with internal video DACs is that they cannot be built on every pin economically, so we would have to have dedicated pin groups for video, instead. This is against our religion, you know.
Some of you here can speak to the practical worth or worthlessness of this idea. Now's the time to add something like this to the design.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Would there be any way for the video machinery, via a programmable selection, to feed a FRQx register from the LUT instead a pin group? At 160MHz, a duty mode counter wouldn't need much filtering.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
This would work great for baseband video where the luminance BW is less than 5MHz. Maybe all NTSC/PAL video could be single-pin-oversampled. At least, there could be such a·mode. At 160 MIPS, you could just use duty cycle, alone, modulated in software, to draw anything in NTSC/PAL. The video circuitry could help·maintain the timebase, though. I'll do some experiments with this oversampling idea. I'm sure it will work, but I'm not sure of the effects of the high-frequency·on the average NTSC/PAL display, especially if it has a tuner being used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.