You said...
""I know this will be a bit late but I do prefer making Prop2 a new, and not to worry about compatibility to much.·It's more important to make it solid and well build system than trying to keep it backwards compatible.""
It is only post in this thread that fully answer Chips question in Threads Title.
I wil see more pople that think this wis way.
My point.
Chip announced Prop Ia to be compatible with Prop I.
Prop II·is New construction and I also has same think "I do prefer making Prop2 a new, and not to worry about compatibility" alls.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
I like the 15 bit color, I like using the left over bit for sync level for NTSC/PAL... as far as Hsync, why not just set what bit it is in some control register? It does not really have to be in the color register...
I also really like the 256 color CLUT, however are you having one per PropII, or one per cog?
If its one per cog, how about making them 32 bits wide, and addressing them only with mov indirect, at cog addresses $0200-$027F? That way creative people could also use them as scan line buffers, fast data acquisition buffers etc [noparse]:)[/noparse]
The other option is to put the CLUT's in HUB address space, or ofcourse, a separate "CLUT" space.
EDIT: I like Sapieha's suggestion for using it as a cog-based stack [noparse]:)[/noparse]
I'd also immensely like it if the video sub-system could output component video [noparse]:)[/noparse]
Chip Gracey (Parallax) said...
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 9/11/2008 3:14:57 PM GMT
"I'd also immensely like it if the video sub-system could output component video [noparse]:)[/noparse]"
It already does. It's called RGB/VGA [noparse];)[/noparse]
(Admittedly, this isn't most people's definition of component video; but in Europe we get component video quality via SCART - and we got it before the US even developed S-Video. It's not fair on you people accross the pond [noparse]:([/noparse] )
Litle of topic.
In Sweden broadcast TV is only Digital and it is more diffictulty to Buy smal LCD TV with analog Input.
And I think that SCART/S-Video compatiblity will be welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
Bill Henning said...
I like the 15 bit color, I like using the left over bit for sync level for NTSC/PAL... as far as Hsync, why not just set what bit it is in some control register? It does not really have to be in the color register...
Well, It has to be synchronized with the pixel data, so if it could ride along with the pixels somehow, it makes it simple. Otherwise, there would need to be some extra mechanism for controlling it.
I also really like the 256 color CLUT, however are you having one per PropII, or one per cog?
One per cog.
If its one per cog, how about making them 32 bits wide, and addressing them only with mov indirect, at cog addresses $0200-$027F? That way creative people could also use them as scan line buffers, fast data acquisition buffers etc [noparse]:)[/noparse]
This is a great idea! I was thinking of separate conduits, but to exploit INDA·or INDB would be much cleaner. Because this RAM is only single-ported from the cog's perspective, you could read or write it each instruction, but not move data within it.
The other option is to put the CLUT's in HUB address space, or ofcourse, a separate "CLUT" space.
If we had only one per chip, this would be the way to go.
EDIT: I like Sapieha's suggestion for using it as a cog-based stack [noparse]:)[/noparse]
I'd also immensely like it if the video sub-system could output component video [noparse]:)[/noparse]
Cluso99 said...
Fantastic... Another 128 longs accessible as general storage per cog. (25% extra)
Where are all these new instuctions going to map into?
They ALL map into %000110, believe it, or not.
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.
It is costly, yes. It seems a lot of you out there want this very badly, though. I haven't been on board yet, myself, because I've never needed this in all my programming. I'm not sure why, either. I've just always used the CNT to get cogs working together and I guess I don't think 'event-driven' as much as other people do. Can someone cite a really compelling reason why this feature would be important?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 9/11/2008 6:34:55 PM GMT
I understand what you're saying here. Extra executable cog RAM could even be single-ported, making it very small. The trouble is, I really am burned out on programming around banks and pages, as we did on the PIC and on the SX.·Banking and paging·certainly works as a mechanism to increase memory, but it slowly drives the programmer·to chronic distraction·and spoils his fun, ultimately burning him out on·the architecture. We don't want our drug to have bad side effects like that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 9/11/2008 5:55:30 PM GMT
A virtual I/O port is useful for 2 cases
1. linking counters together, an example is Phils demodulator code.
2. Inter-cog where power saving is needed. Normal using hub memory is much faster than I/O ports. I have found using I/O ports useful if you want to stop the cog while waiting for the data from another cog. I still sent the data via hub memory but wait on the I/O pin is the data is not available and have the other cog set the pin after putting the data in to the shared hub memory.
OwenS said...
... in Europe we get component video quality via SCART ...
You might want to recheck that. I've noticed a lot of digital decodes here in NZ have a definite trend toward piping actual YCbCr out on the old RGB pins of SCART connectors. So, assuming you are referring to a digital decoder, it's highly likely you are getting the real Component signals.
1) Memory bank switching is a pain as Chip said, no thanks.
2) Virtual I/O pins great for synchronization.
3) Virtual I/O great for linking counters
4) Virtual I/O great for auto power saving (WAITPE, WAIT PNE)
Item 4) above is why I was suggesting having a wait mechanism built into the locks, WAITLOCK.
Item 2) above may be done to some degree with WAITLOCK as well.
By the way, how can I get video out of a Prop I into a PAL TV SCART connection?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
1) Memory bank switching is a pain as Chip said, no thanks.
Although that isn't far off what we're talking about when it comes to multiple task selection within Cogs. Perhaps the pros and cons depend on how it's being sold and how it's implemented ?
Truth is ( as with everything else the Propeller offers ) no one needs to use bank switching if they don't want it. If they want it, "tough, live with any complexity and pain which comes with that", is my feeling. Hopefully bank switching would be implemented elegantly and cause as little pain as possible although that may not always be the case with other processors.
heater said...
By the way, how can I get video out of a Prop I into a PAL TV SCART connection?
There's a few ways you can do PAL TV SCART, one way, is to use the 8bit mode like the vga uses, and use one for sync, and the other 7 can be used for RGB 222, or 232, up to you. but you'd have to make your own driver etc to control the sync timing.
or you could manually bitbang the data to the sync and RGB then you can have as many bits as you want to use up on your prop, ie, you could have your usual 4 (28-31 for programming + i2c) + 1 (for sync) + 24 (for RGB) leaving you with 3 pins for whatever, (keyboard? or input? etc).
heater said...
1) Memory bank switching is a pain as Chip said, no thanks.
For me it dosent really matter what kind of extra memory thats going to be used, only that it works
to have Stacks, High speed protocol bufers, COG Variables of any kind.
Variable I/O has many uses and frees Physical PINs
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stuipid question there is atleast one inteligent awnser
OwenS said...
... in Europe we get component video quality via SCART ...
You might want to recheck that. I've noticed a lot of digital decodes here in NZ have a definite trend toward piping actual YCbCr out on the old RGB pins of SCART connectors. So, assuming you are referring to a digital decoder, it's highly likely you are getting the real Component signals.
Evan
All my digital equipment (DVD players, satelite receiver, etc) pipes out RGB on the RGB pins, as intended. Theres no reason to use component over the RGB pins; if anything it will degrade the quality (Sync on luma vs sync extracted from the composite video pin)
heater said...
By the way, how can I get video out of a Prop I into a PAL TV SCART connection?
For RGB over SCART, you need 4 pins:
R, G, B and CSYNC.
R, G and B are the same as for VGA. CSYNC is HSYNC XOR VSYNC.
CSYNC is then sent along the composite video pin. If you have composite video output in sync (E.G. using one of those AD RGB-to-composite chips) then it will function as CSYNC (The TV will use it's sync seperator to extract the sync from the composite and use it with the RGB data)
No need for bank switching at all. LMM is great for memory extending. In this context, Cog memory acts like a really big data scratch pad (Correct me if I'm wrong).
And 2 kbyte of fast execution space is already enough for I/O controller type apps.
OwenS said...
All my digital equipment (DVD players, satelite receiver, etc) pipes out RGB on the RGB pins, as intended.
Cool, that's not an easy option here, sadly. The display's simply don't use SCART at all, the only RGB inputs are VGA connectors and those appear to have restrictions. The display's pretty much all have the three RCA Component connectors on them.
I have one stupid/controversial idea but will not Write it on forum.
Can I PM it?.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stuipid question there is atleast one inteligent awnser If you dont ask you wont know
@ Sapieha : You may as well post it. You never know, it may not be stupid but have a lot of support and if it is controversial then in all likelihood it will end up being discussed here anyway. If it really is stupid then you probably don't need to even PM it, you'll already know the answer
Since the topic of possibly dumb posts being submitted here has come up, i will give it my best shot.
All the emphasis on the video has me wondering where this is all going. Anyone consider the analog tv is near its' demise, in a short while they won't be manufactured at all. True, an analog signal can still be used with a digital tv, but hardly justifies the output. Whether it is an issue to be considered is hard to say. It does lead me to think, why not upgrade the video driver now for digital use, aside from or combined with the vga.
This is where the dumb part starts. Would it be possible to include a digital video compression in rom? And would a seperate ram buffer for video not make it easier to deal with for memory constraints?
I realize the complexity of trying to accomplish this in chip design, but thought i would ask anyway for interests sake.
I say break a few eggs, this omlet sounds alot better!!
Besides, it'll give the guys a welcome challenge to push the prop II to it's limits and beyond like they already have achieved with the 1st gen... calling all demo coders! calling all demo coders!!
BTW speaking of SRAM, is the quartz material of a·FRAM·incomatable with the current substrate?
kelvin james said...
Anyone consider the analog tv is near its' demise, in a short while they won't be manufactured at all.
While this is true of analog broadband TV, it's certainly not the case for analog baseband (i.e. closed circuit) TV, which enjoys a thriving market in the security field and will for a good many years to come. So there's no reason, just yet, to play Taps for NTSC and PAL!
Phil is correct, there are millions of consumer products that output via analog baseband. It is highly likely the composite in jack will be on televisions for years to come to support all the legacy devices out there.
For viewing, I think NTSC video would be obsolete shortly... Except If it weren't for recording... There's not much out there that can record VGA, but plenty that can record video.
But, IMHO, I think Parallax should focus on DVI/HDMI output. That is where the new and exciting stuff is...
There is also the internal LCD connections of modern LCD displays, these are simpler than DVI/HDMI. The basic signalling is 24 bit colour pins, Dot Clock, HSync, Display Enable (Optional) and VSync. There can be multiple power supplies required and some other odd signals but that is old tech now so +5 volt and the above signals is usually all.
Most of that is obvious in meaning but the timing details will be important, like there is not normally any blanking time, the moment the last pixel of the display is clocked out the first one the new refresh is clocked straight after. However, there is the DE pin for blanking time if desired.
And clocking must be maintained as the whole LCD functions synchronously from the dot clock. If the clock stops the LCD collapses into a faded ugly mess.
Next is the newer LVDS connection that was invented for external digital video cameras but has become the de facto for internal as well. This is just an extension to the LCD system in that the interface/driver chips accept the exact same signals and up clocks them onto a seven signal differential cable (I think), and the reverse at the other end. Making the LVDS part transparent I believe.
There is a good chance that Plasma's are the same. Can't think why not.
Comments
You said...
""I know this will be a bit late but I do prefer making Prop2 a new, and not to worry about compatibility to much.·It's more important to make it solid and well build system than trying to keep it backwards compatible.""
It is only post in this thread that fully answer Chips question in Threads Title.
I wil see more pople that think this wis way.
My point.
Chip announced Prop Ia to be compatible with Prop I.
Prop II·is New construction and I also has same think "I do prefer making Prop2 a new, and not to worry about compatibility" alls.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/11/2008 3:11:54 PM GMT
I also really like the 256 color CLUT, however are you having one per PropII, or one per cog?
If its one per cog, how about making them 32 bits wide, and addressing them only with mov indirect, at cog addresses $0200-$027F? That way creative people could also use them as scan line buffers, fast data acquisition buffers etc [noparse]:)[/noparse]
The other option is to put the CLUT's in HUB address space, or ofcourse, a separate "CLUT" space.
EDIT: I like Sapieha's suggestion for using it as a cog-based stack [noparse]:)[/noparse]
I'd also immensely like it if the video sub-system could output component video [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 9/11/2008 3:14:57 PM GMT
It already does. It's called RGB/VGA [noparse];)[/noparse]
(Admittedly, this isn't most people's definition of component video; but in Europe we get component video quality via SCART - and we got it before the US even developed S-Video. It's not fair on you people accross the pond [noparse]:([/noparse] )
Litle of topic.
In Sweden broadcast TV is only Digital and it is more diffictulty to Buy smal LCD TV with analog Input.
And I think that SCART/S-Video compatiblity will be welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/11/2008 6:13:18 PM GMT
Chip Gracey
Parallax, Inc.
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 9/11/2008 6:34:55 PM GMT
One of Use with 32 I/Os can was Floating Point Procesor directly talk to Spin COG.
Ps ... It is only one of many.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I understand what you're saying here. Extra executable cog RAM could even be single-ported, making it very small. The trouble is, I really am burned out on programming around banks and pages, as we did on the PIC and on the SX.·Banking and paging·certainly works as a mechanism to increase memory, but it slowly drives the programmer·to chronic distraction·and spoils his fun, ultimately burning him out on·the architecture. We don't want our drug to have bad side effects like that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 9/11/2008 5:55:30 PM GMT
I understand.
It was only one idea mayby BAD.
It is You that decide what is Good
Ps ... If > You ofer extra memory available to COG it has not such value
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/12/2008 11:33:56 AM GMT
1. linking counters together, an example is Phils demodulator code.
2. Inter-cog where power saving is needed. Normal using hub memory is much faster than I/O ports. I have found using I/O ports useful if you want to stop the cog while waiting for the data from another cog. I still sent the data via hub memory but wait on the I/O pin is the data is not available and have the other cog set the pin after putting the data in to the shared hub memory.
Evan
2) Virtual I/O pins great for synchronization.
3) Virtual I/O great for linking counters
4) Virtual I/O great for auto power saving (WAITPE, WAIT PNE)
Item 4) above is why I was suggesting having a wait mechanism built into the locks, WAITLOCK.
Item 2) above may be done to some degree with WAITLOCK as well.
By the way, how can I get video out of a Prop I into a PAL TV SCART connection?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Although that isn't far off what we're talking about when it comes to multiple task selection within Cogs. Perhaps the pros and cons depend on how it's being sold and how it's implemented ?
Truth is ( as with everything else the Propeller offers ) no one needs to use bank switching if they don't want it. If they want it, "tough, live with any complexity and pain which comes with that", is my feeling. Hopefully bank switching would be implemented elegantly and cause as little pain as possible although that may not always be the case with other processors.
or you could manually bitbang the data to the sync and RGB then you can have as many bits as you want to use up on your prop, ie, you could have your usual 4 (28-31 for programming + i2c) + 1 (for sync) + 24 (for RGB) leaving you with 3 pins for whatever, (keyboard? or input? etc).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
heater said...
1) Memory bank switching is a pain as Chip said, no thanks.
For me it dosent really matter what kind of extra memory thats going to be used, only that it works
to have Stacks, High speed protocol bufers, COG Variables of any kind.
Variable I/O has many uses and frees Physical PINs
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stuipid question there is atleast one inteligent awnser
Sapieha
Post Edited (Sapieha) : 9/13/2008 12:23:29 AM GMT
All my digital equipment (DVD players, satelite receiver, etc) pipes out RGB on the RGB pins, as intended. Theres no reason to use component over the RGB pins; if anything it will degrade the quality (Sync on luma vs sync extracted from the composite video pin)
For RGB over SCART, you need 4 pins:
R, G, B and CSYNC.
R, G and B are the same as for VGA. CSYNC is HSYNC XOR VSYNC.
CSYNC is then sent along the composite video pin. If you have composite video output in sync (E.G. using one of those AD RGB-to-composite chips) then it will function as CSYNC (The TV will use it's sync seperator to extract the sync from the composite and use it with the RGB data)
And 2 kbyte of fast execution space is already enough for I/O controller type apps.
Evan
Evan
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
I have one stupid/controversial idea but will not Write it on forum.
Can I PM it?.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stuipid question there is atleast one inteligent awnser
If you dont ask you wont know
Sapieha
Post Edited (Sapieha) : 9/13/2008 1:22:13 PM GMT
Of course you can PM me. And like Hippy said, you can post it, too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
All the emphasis on the video has me wondering where this is all going. Anyone consider the analog tv is near its' demise, in a short while they won't be manufactured at all. True, an analog signal can still be used with a digital tv, but hardly justifies the output. Whether it is an issue to be considered is hard to say. It does lead me to think, why not upgrade the video driver now for digital use, aside from or combined with the vga.
This is where the dumb part starts. Would it be possible to include a digital video compression in rom? And would a seperate ram buffer for video not make it easier to deal with for memory constraints?
I realize the complexity of trying to accomplish this in chip design, but thought i would ask anyway for interests sake.
Besides, it'll give the guys a welcome challenge to push the prop II to it's limits and beyond like they already have achieved with the 1st gen... calling all demo coders! calling all demo coders!!
BTW speaking of SRAM, is the quartz material of a·FRAM·incomatable with the current substrate?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
But, IMHO, I think Parallax should focus on DVI/HDMI output. That is where the new and exciting stuff is...
Post Edited (Rayman) : 9/14/2008 12:29:41 AM GMT
Most of that is obvious in meaning but the timing details will be important, like there is not normally any blanking time, the moment the last pixel of the display is clocked out the first one the new refresh is clocked straight after. However, there is the DE pin for blanking time if desired.
And clocking must be maintained as the whole LCD functions synchronously from the dot clock. If the clock stops the LCD collapses into a faded ugly mess.
Next is the newer LVDS connection that was invented for external digital video cameras but has become the de facto for internal as well. This is just an extension to the LCD system in that the interface/driver chips accept the exact same signals and up clocks them onto a seven signal differential cable (I think), and the reverse at the other end. Making the LVDS part transparent I believe.
There is a good chance that Plasma's are the same. Can't think why not.
Evan