Shop OBEX P1 Docs P2 Docs Learn Events
HDMI added to Prop2 - Page 13 — Parallax Forums

HDMI added to Prop2

1101113151621

Comments

  • I believe they will do a 2nd run after the first batch is sent out

    Ok then. I'll be watching.
  • potatohead wrote: »
    I believe they will do a 2nd run after the first batch is sent out

    Ok then. I'll be watching.

    We all will be watching! :)
  • Right?
  • 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
  • pik33pik33 Posts: 2,347
    I have a qustion after reading this.

    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).

  • potatoheadpotatohead Posts: 10,253
    edited 2018-10-30 20:31
    The streamers are not driven by PLLs like P1
    waitvid.

  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    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.
  • RaymanRayman Posts: 13,800
    I’m not sure about #4
    Is that really there?
  • cgracey wrote: »
    TonyB_ wrote: »
    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.
  • Publison wrote: »
    potatohead wrote: »
    I believe they will do a 2nd run after the first batch is sent out

    Ok then. I'll be watching.

    We all will be watching! :)

    Almost there.
    The only person I miss here is Leon: https://forums.parallax.com/profile/Leon
  • RaymanRayman Posts: 13,800
    edited 2018-10-30 22:58
    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

  • jmgjmg Posts: 15,140
    pik33 wrote: »
    Does HDMI need 250 MHz CLK on P2?

    Yes, nominally 250MHz if you want direct connections
    pik33 wrote: »
    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.

  • Publison wrote: »
    potatohead wrote: »
    I believe they will do a 2nd run after the first batch is sent out

    Ok then. I'll be watching.

    We all will be watching! :)

    Almost there.
    The only person I miss here is Leon: https://forums.parallax.com/profile/Leon

    And Sapieha, Pullmoll... :(
    Anybody is in contact with them?

  • PublisonPublison Posts: 12,366
    edited 2018-10-30 23:06
    Publison wrote: »
    potatohead wrote: »
    I believe they will do a 2nd run after the first batch is sent out

    Ok then. I'll be watching.

    We all will be watching! :)

    Almost there.
    The only person I miss here is Leon: https://forums.parallax.com/profile/Leon

    And Sapieha, Pullmoll... :(
    Anybody is in contact with them?
    Unfortuatley, Sapieha has not be around since his last login on October 2015. He was in ill health at the time.

    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. :)
  • Someone special is Brad, creator of BST.

    http://www.fnarfbargle.com/bst.html
    I only use Linux.

    Sorry Parallax for this off topic, Propeller 2 is like a new reborn.
  • Someone special is Brad, creator of BST.

    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,
  • TonyB_TonyB_ Posts: 2,108
    edited 2018-10-31 00:56
    Here's the link to the 52 byte values that always encode to a single 10-bit value:
    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.
    | R | G | B |CLK| R | G | B |CLK| R | G | B |CLK| R | G | B |CLK| HDMI
    |+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -|+ -| output
    |               |               |               |               |
    |3 3 2 2 2 2 2 2|2 2 2 2 1 1 1 1|1 1 1 1 1 1    |               | Bit
    |1 0 9 8 7 6 5 4|3 2 1 0 9 8 7 6|5 4 3 2 1 0 9 8|7 6 5 4 3 2 1 0|
    |               |               |               |               |    Pixel
     0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0  a     0
     1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0  b     0
     0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0/-r+ -g+ -b+ 0 1 +r- +g- +b- 0 1  ?   1/0
     1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0  c   1
     -r+ -g+ -b+ 0 1 +r- +g- +b- 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1  !   1
     0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0  a     2
     1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0  b     2
     0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0/-r+ -g+ -b+ 0 1 +r- +g- +b- 0 1  ?   3/2
     1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0  c   3
     -r+ -g+ -b+ 0 1 +r- +g- +b- 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1  !   3
     0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0  a     4
     1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0  b     4
     0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0/-r+ -g+ -b+ 0 1 +r- +g- +b- 0 1  ?   5/4
     1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0  c   5
     -r+ -g+ -b+ 0 1 +r- +g- +b- 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1  !   5
     0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0  a     6
     1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0  b     6
     0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0/-r+ -g+ -b+ 0 1 +r- +g- +b- 0 1  ?   7/6
     1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 1 0  c   7
     -r+ -g+ -b+ 0 1 +r- +g- +b- 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1  !   7
    
    a,b,c are constant longs
    ? & ! are variable longs (only one word varies)
    

    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.
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    I’m not sure about #4
    Is that really there?

    Whoops! You are right. It doesn't do that last part of serially putting out the four bytes.
  • cgraceycgracey Posts: 14,133
    Yes. Leon. Huge XMOS proponent. I remember him well. Also, Sapieha. I believe he passed away, though.
  • 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.)
  • cgraceycgracey Posts: 14,133
    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.)

    How old is Leon? I figured he was about 60.
  • cgracey wrote: »

    How old is Leon? I figured he was about 60.

    Way off. Leon is 76. (Curiously we share the same birthday, day not year.)
  • ColeyColey Posts: 1,108
    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.
  • cgraceycgracey Posts: 14,133
    Coley wrote: »
    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.

    I do, too.
  • 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.
  • Cluso99Cluso99 Posts: 18,066
    TonyB_ wrote: »
    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.
  • I have interest, but need to wait until we get the Parallax evaluation boards.

  • Interested for sure, but neck deep in other P2 Rev A testing at the moment.
  • 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!

  • jmgjmg Posts: 15,140
    TonyB_ wrote: »
    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.
Sign In or Register to comment.