even if it was left as it currently is, it will still produce far better displays than it has now, because it will be 8 * faster, even doing a scanline renderer, just one single cog could fill the display line with more than the whole Prop1 could do, let alone putting multiple cogs on it.
I for one am really looking forward to having a play with the PropII when it's available, ( as long as the world doesn't get engulfed into a black hole, in the next few weeks once they start colliding those protons in the LHC lol especially since we don't have an escape planet to mass evacuate to! [noparse]:([/noparse] )
One thing I would really like to see is an increased resolution for luma for TV video serializer. I think on the current Prop that the number of colors is sufficient, but the shades of colors are really weak.· That way with more luma depth, it would round out the color values a little more, lose that 8-bit NES look, ·and still be able to keep video at 8 bits.
More control over chroma saturation would be nice, too. Right now, there are just two levels: weakly-saturated and oversaturated.
I'm really happy to hear the about more resolution in the chroma clock, though. (At least I think I read that somewhere. I'm starting to lose track, with new info coming so fast.) Perhaps it will be possible to get a nice-looking yellow, which has eluded the Prop I's NTSC.
It looks like we will just go to 16-bit colors, throughout, instead of the current 8. So, we can do 5:5:5 RGB and way better·composite signalling. I personally don't like the 5:6:5 RGB for the reasons demonstrated in the postings above. 5:5:5 is just cleaner.
I was talking to Andre again last night and he suggested ditching the current composite color definitions·of level/phase/modulation in favor of hardware RGB-to-YUV computation, so that all colors will be maintained in RGB format, better lending pixels to shading and blending computations. Plus, it means there would be no difference between VGA and TV pixel-color coding. We'd probably use a 6-bit R2R ladder for the composite signalling, or maybe Phil's 1-bit oversampled output.
It seems that 5:5:5 RGB to YUV would not be that complex of a circuit -- just a few 7 bit adders, some hardwired as constant multipliers. The next Prop is so fast that we could even resort to special instructions 'RGBNTSC D' and 'RGBPAL D' to do the color conversions on the 16-bit colors so that we get good old top/bottom/phase 5:5:6·values for the modulator. At 160 MIPS, with a composite pixel requirement of perhaps 5 MHZ, we'd have 32 instructions to get our WAITVID ready, which is not a problem, at all.
Also, I was adding DMA over the last few days to the architecture and it really complicated a lot of stuff, so I decided to get rid of it. One thing that was bugging me, anyway, was that unless we had sufficient RAM in the cogs to buffer TWO scan lines (one to display, one to build), there was no point in automating WAITVID. So, we're back to simple there.
I have added a RDOCTL/WROCTL instruction which can read and write 8 longs at a whack. This is important for getting 16 words in at a time for 4-bit pixels.
So, the video hardware is basically·growing in width, only.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 9/10/2008 8:51:25 PM GMT
In My opinion fine solution.
My one question Is it posible to construct VIDEO generator to have modes to continuos send 32 Bits wide Longs from HUB to PINs.
That posiblity means like extra posiblity and has many uses.
Ps. With variable freqency and maybe control to pin in 4 groups (1-4).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
I'd be inclined to ask the question, "How many people would be negatively affected by a compatibility break?" I can't see it being a huge number.
Most of the learning curve is about getting used to the architecture. If Spin II looks like Spin I with some new commands then you have not really hurt the programmers. MicroSoft is a great example about how maintaining the promise of compatibility always disappoints the customer in the end.
A code scanner to point out incompatibilities and suggested fixes would be really handy.
my 2c
Jim-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.
Don't ever let it out as it's·very difficult·to get it back in."
I'm also looking forward to the RDOCTL/WROCTL instructions!
Actually, I just realized that there's little point in doing 8 whole longs, since it takes other instructions to get/set them, throwing you past the 8-clock hub window. With 4-long R/Ws, you'd get the same hub throughput, as you could hit every hub opportunity. It takes way less silicon to do 4, too.·So, we'll have RDQUAD/WRQUAD, instead.
I'm also looking forward to the RDOCTL/WROCTL instructions!
Actually, I just realized that there's little point in doing 8 whole longs, since it takes other instructions to get/set them, throwing you past the 8-clock hub window. With 4-long R/Ws, you'd get the same hub throughput, as you could hit every hub opportunity. It takes way less silicon to do 4, too.·So, we'll have RDQUAD/WRQUAD, instead.
If 8 longs would have missed the hub window, then 4 longs is better. The main thing I like is the faster throughput of streaming between the cogs and hub memory.
I know this will be a bit late but I do prefer making Prop2 a new, and not to worry about compatibility too much. It's more important to make it solid and well build system than trying to keep it backwards compatible.
Thanks Chip for opening up this discussion. It has been a real chore to keep up with the posts, let alone follow some of the ideas. This wil have to go into the record books in years to come!!
The WDQLONG/RDQLONG or whatever it's called will be fantastic
So will the 5:5:5 video and wow, the conversion idea to NTSC/PAL or RGB to YUV also. Hope you can keep the design as flexable as possible. I am certain others will find uses you will never have thought of. I haven't even come to grips with the Prop I counters yet (other areas of the Prop have kept me fully occupied when time permits).
One color space for all is a great solution! I wonder if 5:5:5:1 could be used for the TV conversion, where the ":1" provides the black vs. sync level separately, thus preserving the full 5:5:5 dynamic range for the luma and chroma levels.
Oddly, nobody has mentioned that you can't accommodate two sync signals with 16 bits and 5:5:5 color. This could be a problem for VGA, which requires separate H and V syncs.
Finally, I assume you'll be ditching broadcast video, right? The equipment to receive it will soon be obsolete and out of production. It was a novelty to play with, but I won't miss it.
Just wondering if there will be any changes to the counters that will enable improved jitter performance for RF junkies?
Another option, could the phase accumulator high order bits be multiplexed out to pins?
If so perhaps the MSB could be used to complement the other bits so you could use an R2R ladder to get at least a triangle output that would be easy to filter.
It just seems such a waste to have what is essentially a 160MHz DDS (sans A/D and sine lookup) on each cog (times two) and no easy way to exploit it.
thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ian Mitchell
www.research.utas.edu.au
One color space for all is a great solution! I wonder if 5:5:5:1 could be used for the TV conversion, where the ":1" provides the black vs. sync level separately, thus preserving the full 5:5:5 dynamic range for the luma and chroma levels.
Oddly, nobody has mentioned that you can't accommodate two sync signals with 16 bits and 5:5:5 color. This could be a problem for VGA, which requires separate H and V syncs.
Finally, I assume you'll be ditching broadcast video, right? The equipment to receive it will soon be obsolete and out of production. It was a novelty to play with, but I won't miss it.
-Phil
Yes, that extra bit would do well as a SYNC level·in TV and as an HSYNC pin in VGA, as both must be·EXACTLY registered to the pixel timing. I am trying to get my head around the RGB to YIQ translation and what extra would have to be done to accomodate both NTSC and PAL. I·hope to·model the transform tonight in order to get some better understanding of it·and do some reality checks. Also, I must see if any 5:5:5 RGB combo will yield a colorburst pattern.
I don't know if we'll drop broadcast, or not.
Also, I came to the conclusion this afternoon that we really do need a color lookup table of 256 colors by 16 bits. There will be instructions to load it and read it, too (storage space). This way, you load up all your colors and do 'WAITVID pixels,vscl' (no more VSCL regsiter needed, which eliminates a frequent MOV instruction). The vscl can contain a scalar color-table·offset in the top bits, so that 1-bit, 2-bit, and 4-bit pixel·groups·can use distinct color groups within the 256. This also means that we'd have an 8-bit pixel mode which would use the whole table. For 16-bit pixels, the pixels are used literally, without any lookup. This mechanism will cover everything and be very simple. The only pain is that the color lookup table will have to be dual-ported since there are two separate clock domains at work, the cog's and video's. These dual-port RAMs·will add about $0.04 to the cost of the silicon.
You said.
""These dual-port RAMs will add about $0.04 to the cost of the silicon."
In My opinion all users accept that extra cost.
LevisD said.
"Also if you could add instructions to use this space as a stack ...- PUSH, POP with a stack pointer - would be awesome..."
Many others said that It would be well to have extra Data buffer in COG.
My question if You must have That Colortabelebufer Can You in all other cases will do him in general lines accessible
for data storage for different possibilities.
·
Ps. That construction eliminares use Stack space for Spin in HUB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
LevisD said.
"Also if you could add instructions to use this space as a stack ...- PUSH, POP with a stack pointer - would be awesome..."
Many others said that It would be well to have extra Data buffer in COG.
My question if You must have That Colortabelebufer Can You in all other cases will do him in general lines accessible
for data storage for different possibilities. Yes, it could·be used for general data storage and we could r/w 32 bits at a time, for 128 longs.·
Ps. That construction eliminares use Stack space for Spin in HUB. Almost. The problem is that Spin stack space can be very large if you declare many local variables, like an array.
I'm not an expert on the economics of chips -
but this seems very cheep to have a local buffer and/or stack on each COG that frees the executable COG space.
LevisD said.
"Also if you could add instructions to use this space as a stack ...- PUSH, POP with a stack pointer - would be awesome..."
Many others said that It would be well to have extra Data buffer in COG.
My question if You must have That Colortabelebufer Can You in all other cases will do him in general lines accessible
for data storage for different possibilities. Yes, it could·be used for general data storage and we could r/w 32 bits at a time, for 128 longs.·
Ps. That construction eliminares use Stack space for Spin in HUB. Almost. The problem is that Spin stack space can be very large if you declare many local variables, like an array.
I am only idea man and if You like one of my ideas Balance that·idea only·You can.
My ideas is only basic ideas and I have more detailed thinks on that ideas and use in practical constructions
If You have questions I can explain more I have plenty of time (I am pensionary)
I have read all threads on Forum and analyze PropI thoroughly and from here my suggestions (what funktion no good and what is missing)
If You will not discuss one of idea on Forum You have to write PM (no problem)
Christoffer Jönsson
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
Fantastic... Another 128 longs accessible as general storage per cog. (25% extra)
Where are all these new instuctions going to map into?
Chip: Is the silicon for routing the I/O pins around the cogs expensive ? I was wondering if it would be simple to add another 32 I/Os, but not brought out so no actual I/O pads, etc. This way we could do intercog communications with these. Just a thought.
The storage space idea opens up a lot of potential for what seems like a small cost! With the new instructions (rep, auto increment) the amount of code running in the COG will go way up, as working variables can now be outside the code address space.
IMHO, that should get everybody stoked, not just those who enjoy graphics.
Comments
I for one am really looking forward to having a play with the PropII when it's available, ( as long as the world doesn't get engulfed into a black hole, in the next few weeks once they start colliding those protons in the LHC lol especially since we don't have an escape planet to mass evacuate to! [noparse]:([/noparse] )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Post Edited (JT Cook) : 9/10/2008 6:16:10 PM GMT
I'm really happy to hear the about more resolution in the chroma clock, though. (At least I think I read that somewhere. I'm starting to lose track, with new info coming so fast.) Perhaps it will be possible to get a nice-looking yellow, which has eluded the Prop I's NTSC.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Baggars, yep! Wonder if a CAPCOM port can fit in the 256MB [noparse]:)[/noparse] Sure seems like the overall throughput will be at that level.
Now that I think about it, that much speed makes the priority suggestion I had a lot less of an advantage! Was still thinking Prop I speeds...
Oh well, if the black hole sucks us in, we won't be worried about it, right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
It looks like we will just go to 16-bit colors, throughout, instead of the current 8. So, we can do 5:5:5 RGB and way better·composite signalling. I personally don't like the 5:6:5 RGB for the reasons demonstrated in the postings above. 5:5:5 is just cleaner.
I was talking to Andre again last night and he suggested ditching the current composite color definitions·of level/phase/modulation in favor of hardware RGB-to-YUV computation, so that all colors will be maintained in RGB format, better lending pixels to shading and blending computations. Plus, it means there would be no difference between VGA and TV pixel-color coding. We'd probably use a 6-bit R2R ladder for the composite signalling, or maybe Phil's 1-bit oversampled output.
It seems that 5:5:5 RGB to YUV would not be that complex of a circuit -- just a few 7 bit adders, some hardwired as constant multipliers. The next Prop is so fast that we could even resort to special instructions 'RGBNTSC D' and 'RGBPAL D' to do the color conversions on the 16-bit colors so that we get good old top/bottom/phase 5:5:6·values for the modulator. At 160 MIPS, with a composite pixel requirement of perhaps 5 MHZ, we'd have 32 instructions to get our WAITVID ready, which is not a problem, at all.
Also, I was adding DMA over the last few days to the architecture and it really complicated a lot of stuff, so I decided to get rid of it. One thing that was bugging me, anyway, was that unless we had sufficient RAM in the cogs to buffer TWO scan lines (one to display, one to build), there was no point in automating WAITVID. So, we're back to simple there.
I have added a RDOCTL/WROCTL instruction which can read and write 8 longs at a whack. This is important for getting 16 words in at a time for 4-bit pixels.
So, the video hardware is basically·growing in width, only.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 9/10/2008 8:51:25 PM GMT
potatohead, which CAPCOM port are you wanting? lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
In My opinion fine solution.
My one question Is it posible to construct VIDEO generator to have modes to continuos send 32 Bits wide Longs from HUB to PINs.
That posiblity means like extra posiblity and has many uses.
Ps. With variable freqency and maybe control to pin in 4 groups (1-4).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/10/2008 9:12:17 PM GMT
Most of the learning curve is about getting used to the architecture. If Spin II looks like Spin I with some new commands then you have not really hurt the programmers. MicroSoft is a great example about how maintaining the promise of compatibility always disappoints the customer in the end.
A code scanner to point out incompatibilities and suggested fixes would be really handy.
my 2c
Jim-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A wise man told me; "All electronics are made to work by magic smoke.
Don't ever let it out as it's·very difficult·to get it back in."
I'm also looking forward to the RDOCTL/WROCTL instructions!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I do like the internal RGB->TV idea!
I know this will be a bit late but I do prefer making Prop2 a new, and not to worry about compatibility too much. It's more important to make it solid and well build system than trying to keep it backwards compatible.
Would having the color space instructions see any other potential uses?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
The WDQLONG/RDQLONG or whatever it's called will be fantastic
So will the 5:5:5 video and wow, the conversion idea to NTSC/PAL or RGB to YUV also. Hope you can keep the design as flexable as possible. I am certain others will find uses you will never have thought of. I haven't even come to grips with the Prop I counters yet (other areas of the Prop have kept me fully occupied when time permits).
Once again, thanks from all of us
One color space for all is a great solution! I wonder if 5:5:5:1 could be used for the TV conversion, where the ":1" provides the black vs. sync level separately, thus preserving the full 5:5:5 dynamic range for the luma and chroma levels.
Oddly, nobody has mentioned that you can't accommodate two sync signals with 16 bits and 5:5:5 color. This could be a problem for VGA, which requires separate H and V syncs.
Finally, I assume you'll be ditching broadcast video, right? The equipment to receive it will soon be obsolete and out of production. It was a novelty to play with, but I won't miss it.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Another option, could the phase accumulator high order bits be multiplexed out to pins?
If so perhaps the MSB could be used to complement the other bits so you could use an R2R ladder to get at least a triangle output that would be easy to filter.
It just seems such a waste to have what is essentially a 160MHz DDS (sans A/D and sine lookup) on each cog (times two) and no easy way to exploit it.
thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ian Mitchell
www.research.utas.edu.au
Post Edited (IanM) : 9/11/2008 4:23:56 AM GMT
I don't know if we'll drop broadcast, or not.
Also, I came to the conclusion this afternoon that we really do need a color lookup table of 256 colors by 16 bits. There will be instructions to load it and read it, too (storage space). This way, you load up all your colors and do 'WAITVID pixels,vscl' (no more VSCL regsiter needed, which eliminates a frequent MOV instruction). The vscl can contain a scalar color-table·offset in the top bits, so that 1-bit, 2-bit, and 4-bit pixel·groups·can use distinct color groups within the 256. This also means that we'd have an 8-bit pixel mode which would use the whole table. For 16-bit pixels, the pixels are used literally, without any lookup. This mechanism will cover everything and be very simple. The only pain is that the color lookup table will have to be dual-ported since there are two separate clock domains at work, the cog's and video's. These dual-port RAMs·will add about $0.04 to the cost of the silicon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Reading and Writing 16 bits at a time looks good for video.
Will there be a way to read and write 32 bits at a time as well?
Also if you could add instructions to use this space as a stack ...- PUSH, POP with a stack pointer - would be awesome...
LewisD
You said.
""These dual-port RAMs will add about $0.04 to the cost of the silicon."
In My opinion all users accept that extra cost.
LevisD said.
"Also if you could add instructions to use this space as a stack ...- PUSH, POP with a stack pointer - would be awesome..."
Many others said that It would be well to have extra Data buffer in COG.
My question if You must have That Colortabelebufer Can You in all other cases will do him in general lines accessible
for data storage for different possibilities.
·
Ps. That construction eliminares use Stack space for Spin in HUB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/11/2008 6:19:26 AM GMT
Chip Gracey
Parallax, Inc.
$0.04 seems very reasonable.
$0.08 = 256 longs ? [noparse]:)[/noparse]
$0.16 = 512 longs ? [noparse]:)[/noparse] [noparse]:)[/noparse]
I'm not an expert on the economics of chips -
but this seems very cheep to have a local buffer and/or stack on each COG that frees the executable COG space.
LewisD
/Henke
You answer I am only idea man and if You like one of my ideas Balance that·idea only·You can.
My ideas is only basic ideas and I have more detailed thinks on that ideas and use in practical constructions
If You have questions I can explain more I have plenty of time (I am pensionary)
I have read all threads on Forum and analyze PropI thoroughly and from here my suggestions (what funktion no good and what is missing)
If You will not discuss one of idea on Forum You have to write PM (no problem)
Christoffer Jönsson
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/11/2008 3:11:20 PM GMT
Where are all these new instuctions going to map into?
Chip: Is the silicon for routing the I/O pins around the cogs expensive ? I was wondering if it would be simple to add another 32 I/Os, but not brought out so no actual I/O pads, etc. This way we could do intercog communications with these. Just a thought.
The storage space idea opens up a lot of potential for what seems like a small cost! With the new instructions (rep, auto increment) the amount of code running in the COG will go way up, as working variables can now be outside the code address space.
IMHO, that should get everybody stoked, not just those who enjoy graphics.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Reread this thred maybe it is way to go with litle modification?
http://forums.parallax.com/forums/default.aspx?f=25&m=235126
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/11/2008 2:38:07 PM GMT