Is there are a streamer mode that repeatedly does the following?
1. Read a long from hub RAM
2. Send each byte of hub long in turn to LUT address input
3. Read a long from LUT
4. Send each byte of LUT long in turn to same 8 output pins
Does HDMI need 250 MHz CLK on P2?
Aren't there any PLL driven serializer like P1 video encoder whcih outputs 32 bits it got with waitvid as serial bits, clocked by PLL, and not CLK (I got experimental 1920x1200 VGA out of P1 # 154 MHz some time ago).
Is there are a streamer mode that repeatedly does the following?
1. Read a long from hub RAM
2. Send each byte of hub long in turn to LUT address input
3. Read a long from LUT
4. Send each byte of LUT long in turn to same 8 output pins
Is there are a streamer mode that repeatedly does the following?
1. Read a long from hub RAM
2. Send each byte of hub long in turn to LUT address input
3. Read a long from LUT
4. Send each byte of LUT long in turn to same 8 output pins
Yes. Lots of modes like that.
If there is a mode exactly as above, then I think 640x480xRGB(3bpp) HDMI on the P2 rev A might need only two cogs to write the line buffer on the fly. If not, then it would be four cogs. For every 80 bits output during the active display, only six would be variable and 74 constant.
Well, there is a streamer mode where it grabs longs from HUB and then shifts in units of 1,2,4,or 8 bits to decode a LUT address.
So, you can get 8 bits of HDMI output from one rflong in 4-bit mode.
4-bits would let you do 8-color graphics, I think.
a 640 pixel line needs 6400 bits --> 800 longs in HUB for one line.
You have 6400 clocks to create these 800 longs. 8 clocks/long with one cog.
Maybe with 5 cogs it could be done...
Wait, I'm thinking about the color output wrong... Maybe better to think in grayscale mode. There are only 4 output conditions in this case and you can be in rflong LUT 2-bit mode.
Get 16 bits in each HUB long.
Need 6400 bits per line --> 400 longs for one line.
6400 clocks for 400 longs, 16 clocks/long with one cog.
Seems could be done with 4 cogs... (?)
Let's say just monochrome color mode. RFLong from hub gets you 32 pixels. You shift once for each pixel and use carry to pick 10 bit output. You shift some amount and then or with output long. If output long is full, start new long and add remaining bits to new long. WFlong them all when done...
Seems like ~10 instructions per output long
Aren't there any PLL driven serializer like P1 video encoder whcih outputs 32 bits it got with waitvid as serial bits, clocked by PLL, and not CLK (I got experimental 1920x1200 VGA out of P1 # 154 MHz some time ago).
Yes, there are parallel to DVI chips, and IIRC Rayman did one on P1 ?
Adding one of those can push the pixel clocks much higher, to the P2 RAM limits.
There are 26 byte pairs {p,q} for which p ^ q = FF and the low 8 bits of the two 10-bit TMDS codes are identical. For example, bytes 10 and EF are encoded to 1F0 and 2F0, respectively. 10 and EF are the lowest and highest byte values with a single 10-bit code and thus are good choices for an 8-colour RGB HDMI mode, with one bit for each of red, green and blue. As only the high two encoded bits vary, either 01 or 10, the majority (80%) of the bytes sent to the eight HDMI outputs are static, as shown below.
Each row above represents four bytes that are shifted right by one byte at a frequency of 10x the pixel clock, i.e. 250MHz for 640x480. I think it should be possible to generate this HDMI output on the P2 rev A with four cogs writing to a line buffer at the same time "racing the beam". The job of each of these cogs is simply to read its next pixel nibble (one bit unused) and write one of eight words to hub RAM within 40 clock cycles. A line of 640 pixels uses 320 bytes or 80 longs, which could be streamed into each cog's RAM during the horizontal blanking. One line lasts 800 pixel clocks and therefore a complete line buffer including horizontal sync would use 8000 bytes. A second buffer, fully static, could be used during the vertical sync. A 640x480x3bpp frame buffer would require 150K, making a total of ~166K of hub RAM.
EDIT:
CLK- is shown as bit 0 of the output byte, but the order could be reversed easily.
Leon was hit and severely crippled by a car a few years ago. Last update I can find about him was him being moved into hospice care of some sort. (Details are vague.)
Leon was hit and severely crippled by a car a few years ago. Last update I can find about him was him being moved into hospice care of some sort. (Details are vague.)
Leon is a great guy, Baggers and me met him at the Maker faire in Newcastle UK a number of years ago.
For a Septuagenarian he was very spritely and definitely forthright in his views ;-)
Last I heard he'd been knocked over by a van and had a shattered pelvis, I hope he pulled though OK.
Leon is a great guy, Baggers and me met him at the Maker faire in Newcastle UK a number of years ago.
For a Septuagenarian he was very spritely and definitely forthright in his views ;-)
Last I heard he'd been knocked over by a van and had a shattered pelvis, I hope he pulled though OK.
Mmm, no comments on my last post. After more study, I think three cogs on the P2 rev A could implement HDMI output of 640x480x4bpp RGBI. More details available, if there is any interest.
Mmm, no comments on my last post. After more study, I think three cogs on the P2 rev A could implement HDMI output of 640x480x4bpp RGBI. More details available, if there is any interest.
Would be nice to try it out so depends on how much work. Don't really have anything I want to do with it tho, for now anyway.
Thanks for the interest. It would be good if someone with a P2 could test this out. I've done all the really hard work - the thinking. One cog would stream out bytes from a line buffer at 250 MHz, which Chip has proven already. The other two would read from the frame buffer and write to the line buffer. There are 8000 clock cycles per line at 250 MHz and during this time the two cogs must do the following:
1. Read 80 longs from hub RAM to cog RAM.
2. For each of these 80 longs, read each even or odd nibble in turn and use it as an index to a table of 16 longs containing TMDS data.
3. Write the TMDS long to hub RAM and add 5 to the hub RAM pointer.
The hub RAM write will always cross a long boundary for one cog but never for the other. If the above is feasible, then I'll post further details tomorrow. If not, I won't!
Thanks for the interest. It would be good if someone with a P2 could test this out. I've done all the really hard work - the thinking. One cog would stream out bytes from a line buffer at 250 MHz, which Chip has proven already. The other two would read from the frame buffer and write to the line buffer. There are 8000 clock cycles per line at 250 MHz and during this time the two cogs must do the following:
1. Read 80 longs from hub RAM to cog RAM.
2. For each of these 80 longs, read each even or odd nibble in turn and use it as an index to a table of 16 longs containing TMDS data.
3. Write the TMDS long to hub RAM and add 5 to the hub RAM pointer.
The hub RAM write will always cross a long boundary for one cog but never for the other. If the above is feasible, then I'll post further details tomorrow. If not, I won't!
This does sound a very good way to encourage test coverage over many brands of HDMI displays, & once Chip has mounted the larger batch of packaged P2.a's (onto Eval's & P2D2's?), a lot more P2 boards will be in circulation.
Comments
Ok then. I'll be watching.
We all will be watching!
1. Read a long from hub RAM
2. Send each byte of hub long in turn to LUT address input
3. Read a long from LUT
4. Send each byte of LUT long in turn to same 8 output pins
Does HDMI need 250 MHz CLK on P2?
Aren't there any PLL driven serializer like P1 video encoder whcih outputs 32 bits it got with waitvid as serial bits, clocked by PLL, and not CLK (I got experimental 1920x1200 VGA out of P1 # 154 MHz some time ago).
waitvid.
Yes. Lots of modes like that.
Is that really there?
If there is a mode exactly as above, then I think 640x480xRGB(3bpp) HDMI on the P2 rev A might need only two cogs to write the line buffer on the fly. If not, then it would be four cogs. For every 80 bits output during the active display, only six would be variable and 74 constant.
Almost there.
The only person I miss here is Leon: https://forums.parallax.com/profile/Leon
So, you can get 8 bits of HDMI output from one rflong in 4-bit mode.
4-bits would let you do 8-color graphics, I think.
a 640 pixel line needs 6400 bits --> 800 longs in HUB for one line.
You have 6400 clocks to create these 800 longs. 8 clocks/long with one cog.
Maybe with 5 cogs it could be done...
Wait, I'm thinking about the color output wrong... Maybe better to think in grayscale mode. There are only 4 output conditions in this case and you can be in rflong LUT 2-bit mode.
Get 16 bits in each HUB long.
Need 6400 bits per line --> 400 longs for one line.
6400 clocks for 400 longs, 16 clocks/long with one cog.
Seems could be done with 4 cogs... (?)
Let's say just monochrome color mode. RFLong from hub gets you 32 pixels. You shift once for each pixel and use carry to pick 10 bit output. You shift some amount and then or with output long. If output long is full, start new long and add remaining bits to new long. WFlong them all when done...
Seems like ~10 instructions per output long
Yes, nominally 250MHz if you want direct connections
Yes, there are parallel to DVI chips, and IIRC Rayman did one on P1 ?
Adding one of those can push the pixel clocks much higher, to the P2 RAM limits.
And Sapieha, Pullmoll...
Anybody is in contact with them?
Pullmoll just seemed to disappear in September 2010. He had a good run March through September of that year. No reason I can find why he left..
Loen was last signed on August 17. I'm sure he still lurking.
http://www.fnarfbargle.com/bst.html
I only use Linux.
Sorry Parallax for this off topic, Propeller 2 is like a new reborn.
True. MIA for 8 years,
http://forums.parallax.com/discussion/comment/1451163/#Comment_1451163
There are 26 byte pairs {p,q} for which p ^ q = FF and the low 8 bits of the two 10-bit TMDS codes are identical. For example, bytes 10 and EF are encoded to 1F0 and 2F0, respectively. 10 and EF are the lowest and highest byte values with a single 10-bit code and thus are good choices for an 8-colour RGB HDMI mode, with one bit for each of red, green and blue. As only the high two encoded bits vary, either 01 or 10, the majority (80%) of the bytes sent to the eight HDMI outputs are static, as shown below.
Each row above represents four bytes that are shifted right by one byte at a frequency of 10x the pixel clock, i.e. 250MHz for 640x480. I think it should be possible to generate this HDMI output on the P2 rev A with four cogs writing to a line buffer at the same time "racing the beam". The job of each of these cogs is simply to read its next pixel nibble (one bit unused) and write one of eight words to hub RAM within 40 clock cycles. A line of 640 pixels uses 320 bytes or 80 longs, which could be streamed into each cog's RAM during the horizontal blanking. One line lasts 800 pixel clocks and therefore a complete line buffer including horizontal sync would use 8000 bytes. A second buffer, fully static, could be used during the vertical sync. A 640x480x3bpp frame buffer would require 150K, making a total of ~166K of hub RAM.
EDIT:
CLK- is shown as bit 0 of the output byte, but the order could be reversed easily.
Whoops! You are right. It doesn't do that last part of serially putting out the four bytes.
How old is Leon? I figured he was about 60.
Way off. Leon is 76. (Curiously we share the same birthday, day not year.)
For a Septuagenarian he was very spritely and definitely forthright in his views ;-)
Last I heard he'd been knocked over by a van and had a shattered pelvis, I hope he pulled though OK.
I do, too.
1. Read 80 longs from hub RAM to cog RAM.
2. For each of these 80 longs, read each even or odd nibble in turn and use it as an index to a table of 16 longs containing TMDS data.
3. Write the TMDS long to hub RAM and add 5 to the hub RAM pointer.
The hub RAM write will always cross a long boundary for one cog but never for the other. If the above is feasible, then I'll post further details tomorrow. If not, I won't!
This does sound a very good way to encourage test coverage over many brands of HDMI displays, & once Chip has mounted the larger batch of packaged P2.a's (onto Eval's & P2D2's?), a lot more P2 boards will be in circulation.