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

HDMI added to Prop2

1679111221

Comments

  • cgracey wrote: »
    TonyB_,

    If we use d[1] then we avoid conflict with d[0] which may be in use by the same driver, in order to generate a concurrent set of VGA signals. It is our only option.

    Chip, could you say a bit more? Where is d[0] in use and what does it do?

    Also, have the 8-pin groupings for HDMI been posted?
  • cgraceycgracey Posts: 14,133
    edited 2018-10-20 23:16
    TonyB_ wrote: »
    cgracey wrote: »
    TonyB_,

    If we use d[1] then we avoid conflict with d[0] which may be in use by the same driver, in order to generate a concurrent set of VGA signals. It is our only option.

    Chip, could you say a bit more? Where is d[0] in use and what does it do?

    Also, have the 8-pin groupings for HDMI been posted?

    D[0] is used in VGA mode to assert HSYNC. D[1] is not used in VGA mode.

    D[1] is used in HDMI mode to signify a custom/raw 10-bit pattern to output. D[0] is not used in HDMI mode.

    By keeping D[0] and D[1] independent of each other. You can code for VGA, HDMI, or both concurrently.

    The current Google doc covers the VGA modes, under "Colorspace Converter". I'll update the doc to cover HDMI later on. Right now, I need to prove that it works. I wish there was something on the web that showed what proper patterns look like for various R/G/B data. This all seems to be working, but I'd like to know that it is correct.

    The 8-pin relative groupings for HDMI are as follows:

    +7 = RED+
    +6 = RED-
    +5 = GRN+
    +4 = GRN-
    +3 = BLU+
    +2 = BLU-
    +1 = CLK+
    +0 = CLK-
  • cgracey wrote: »
    TonyB_ wrote: »
    cgracey wrote: »
    TonyB_,

    If we use d[1] then we avoid conflict with d[0] which may be in use by the same driver, in order to generate a concurrent set of VGA signals. It is our only option.

    Chip, could you say a bit more? Where is d[0] in use and what does it do?

    Also, have the 8-pin groupings for HDMI been posted?

    D[0] is used in VGA mode to assert HSYNC. D[1] is not used in VGA mode.

    D[1] is used in HDMI mode to signify a custom/raw 10-bit pattern to output. D[0] is not used in HDMI mode.

    By keeping D[0] and D[1] independent of each other. You can code for VGA, HDMI, or both concurrently.

    The current Google doc covers the VGA modes, under "Colorspace Converter". I'll update the doc to cover HDMI later on. Right now, I need to prove that it works. I wish there was something on the web that showed what proper patterns look like for various R/G/B data. This all seems to be working, but I'd like to know that it is correct.

    The 8-pin relative groupings for HDMI are as follows:

    +7 = RED+
    +6 = RED-
    +5 = GRN+
    +4 = GRN-
    +3 = BLU+
    +2 = BLU-
    +1 = CLK+
    +0 = CLK-

    Thanks for the info, Chip.

    I've done TMDS encoding and decoding in software:
    http://forums.parallax.com/discussion/comment/1449960/#Comment_1449960
    The table is in hex to make it all fit in one post. Does it help?
  • cgracey wrote: »
    The current Google doc covers the VGA modes, under "Colorspace Converter". I'll update the doc to cover HDMI later on.

    I did look at the doc first. Should this line on p.46
    FS[7:0]	= {8{DAC[0] ^ CMOD[0]}} (VGA H-Sync) 
    

    be this?
    FS[7:0] = {8{DAC0[0] ^ CMOD[0]}} (VGA H-Sync) 
    

  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    cgracey wrote: »
    The current Google doc covers the VGA modes, under "Colorspace Converter". I'll update the doc to cover HDMI later on.

    I did look at the doc first. Should this line on p.46
    FS[7:0]	= {8{DAC[0] ^ CMOD[0]}} (VGA H-Sync) 
    

    be this?
    FS[7:0] = {8{DAC0[0] ^ CMOD[0]}} (VGA H-Sync) 
    

    Yes! Good eye. I just fixed it.
  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    cgracey wrote: »
    TonyB_ wrote: »
    cgracey wrote: »
    TonyB_,

    If we use d[1] then we avoid conflict with d[0] which may be in use by the same driver, in order to generate a concurrent set of VGA signals. It is our only option.

    Chip, could you say a bit more? Where is d[0] in use and what does it do?

    Also, have the 8-pin groupings for HDMI been posted?

    D[0] is used in VGA mode to assert HSYNC. D[1] is not used in VGA mode.

    D[1] is used in HDMI mode to signify a custom/raw 10-bit pattern to output. D[0] is not used in HDMI mode.

    By keeping D[0] and D[1] independent of each other. You can code for VGA, HDMI, or both concurrently.

    The current Google doc covers the VGA modes, under "Colorspace Converter". I'll update the doc to cover HDMI later on. Right now, I need to prove that it works. I wish there was something on the web that showed what proper patterns look like for various R/G/B data. This all seems to be working, but I'd like to know that it is correct.

    The 8-pin relative groupings for HDMI are as follows:

    +7 = RED+
    +6 = RED-
    +5 = GRN+
    +4 = GRN-
    +3 = BLU+
    +2 = BLU-
    +1 = CLK+
    +0 = CLK-

    Thanks for the info, Chip.

    I've done TMDS encoding and decoding in software:
    http://forums.parallax.com/discussion/comment/1449960/#Comment_1449960
    The table is in hex to make it all fit in one post. Does it help?

    Thanks, TonyB_! I will check what the circuit spits out against your predictions. This should be sufficient before wiring up a cable and giving it a real go.
  • TonyB_TonyB_ Posts: 2,107
    edited 2018-10-22 21:00
    cgracey wrote: »
    TonyB_ wrote: »
    Thanks for the info, Chip.

    I've done TMDS encoding and decoding in software:
    http://forums.parallax.com/discussion/comment/1449960/#Comment_1449960
    The table is in hex to make it all fit in one post. Does it help?

    Thanks, TonyB_! I will check what the circuit spits out against your predictions. This should be sufficient before wiring up a cable and giving it a real go.

    The outputs in the link above are independent with fixed disparity. It might be more useful to have a sequence or two of outputs in which the disparity propagates.

    Here are the TMDS data for 00-FF ascending:

    8b = 8-bit input
    10b = 10-bit output
    dispi = disparity input from previous stage
    dispo = disparity output to next stage
    disparity = number of '1' bits - number of '0' bits for 8-bit value
    #8b,10b,dispi,dispo
    00,100, 0,-8
    01,1FF,-8, 0
    02,1FE, 0,+6
    03,101,+6, 0
    04,1FC, 0,+4
    05,103,+4, 0
    06,102, 0,-6
    07,1FD,-6, 0
    08,1F8, 0,+2
    09,107,+2, 0
    0A,106, 0,-4
    0B,1F9,-4, 0
    0C,104, 0,-6
    0D,1FB,-6, 0
    0E,1FA, 0,+4
    0F,105,+4, 0
    10,1F0, 0, 0
    11,10F, 0, 0
    12,10E, 0,-2
    13,1F1,-2, 0
    14,10C, 0,-4
    15,1F3,-4, 0
    16,1F2, 0,+2
    17,10D,+2, 0
    18,108, 0,-6
    19,1F7,-6, 0
    1A,1F6, 0,+4
    1B,109,+4, 0
    1C,1F4, 0,+2
    1D,10B,+2, 0
    1E,25F, 0,+4
    1F,2A0,+4, 0
    20,1E0, 0,-2
    21,11F,-2, 0
    22,11E, 0, 0
    23,1E1, 0, 0
    24,11C, 0,-2
    25,1E3,-2, 0
    26,1E2, 0, 0
    27,11D, 0, 0
    28,118, 0,-4
    29,1E7,-4, 0
    2A,1E6, 0,+2
    2B,119,+2, 0
    2C,1E4, 0, 0
    2D,11B, 0, 0
    2E,24F, 0,+2
    2F,2B0,+2, 0
    30,110, 0,-6
    31,1EF,-6, 0
    32,1EE, 0,+4
    33,111,+4, 0
    34,1EC, 0,+2
    35,113,+2, 0
    36,247, 0, 0
    37,2B8, 0, 0
    38,1E8, 0, 0
    39,117, 0, 0
    3A,243, 0,-2
    3B,2BC,-2, 0
    3C,241, 0,-4
    3D,2BE,-4, 0
    3E,2BF, 0,+6
    3F,240,+6, 0
    40,1C0, 0,-4
    41,13F,-4, 0
    42,13E, 0,+2
    43,1C1,+2, 0
    44,13C, 0, 0
    45,1C3, 0, 0
    46,1C2, 0,-2
    47,13D,-2, 0
    48,138, 0,-2
    49,1C7,-2, 0
    4A,1C6, 0, 0
    4B,139, 0, 0
    4C,1C4, 0,-2
    4D,13B,-2, 0
    4E,26F, 0,+4
    4F,290,+4, 0
    50,130, 0,-4
    51,1CF,-4, 0
    52,1CE, 0,+2
    53,131,+2, 0
    54,1CC, 0, 0
    55,133, 0, 0
    56,267, 0,+2
    57,298,+2, 0
    58,1C8, 0,-2
    59,137,-2, 0
    5A,263, 0, 0
    5B,29C, 0, 0
    5C,261, 0,-2
    5D,29E,-2, 0
    5E,29F, 0,+4
    5F,260,+4, 0
    60,120, 0,-6
    61,1DF,-6, 0
    62,1DE, 0,+4
    63,121,+4, 0
    64,1DC, 0,+2
    65,123,+2, 0
    66,277, 0,+4
    67,288,+4, 0
    68,1D8, 0, 0
    69,127, 0, 0
    6A,273, 0,+2
    6B,28C,+2, 0
    6C,271, 0, 0
    6D,28E, 0, 0
    6E,28F, 0,+2
    6F,270,+2, 0
    70,1D0, 0,-2
    71,12F,-2, 0
    72,27B, 0,+4
    73,284,+4, 0
    74,279, 0,+2
    75,286,+2, 0
    76,287, 0, 0
    77,278, 0, 0
    78,27D, 0,+4
    79,282,+4, 0
    7A,283, 0,-2
    7B,27C,-2, 0
    7C,281, 0,-4
    7D,27E,-4, 0
    7E,27F, 0,+6
    7F,280,+6, 0
    80,180, 0,-6
    81,17F,-6, 0
    82,17E, 0,+4
    83,181,+4, 0
    84,17C, 0,+2
    85,183,+2, 0
    86,182, 0,-4
    87,17D,-4, 0
    88,178, 0, 0
    89,187, 0, 0
    8A,186, 0,-2
    8B,179,-2, 0
    8C,184, 0,-4
    8D,17B,-4, 0
    8E,22F, 0,+2
    8F,2D0,+2, 0
    90,170, 0,-2
    91,18F,-2, 0
    92,18E, 0, 0
    93,171, 0, 0
    94,18C, 0,-2
    95,173,-2, 0
    96,227, 0, 0
    97,2D8, 0, 0
    98,188, 0,-4
    99,177,-4, 0
    9A,223, 0,-2
    9B,2DC,-2, 0
    9C,221, 0,-4
    9D,2DE,-4, 0
    9E,2DF, 0,+6
    9F,220,+6, 0
    A0,160, 0,-4
    A1,19F,-4, 0
    A2,19E, 0,+2
    A3,161,+2, 0
    A4,19C, 0, 0
    A5,163, 0, 0
    A6,237, 0,+2
    A7,2C8,+2, 0
    A8,198, 0,-2
    A9,167,-2, 0
    AA,233, 0, 0
    AB,2CC, 0, 0
    AC,231, 0,-2
    AD,2CE,-2, 0
    AE,2CF, 0,+4
    AF,230,+4, 0
    B0,190, 0,-4
    B1,16F,-4, 0
    B2,23B, 0,+2
    B3,2C4,+2, 0
    B4,239, 0, 0
    B5,2C6, 0, 0
    B6,2C7, 0,+2
    B7,238,+2, 0
    B8,23D, 0,+2
    B9,2C2,+2, 0
    BA,2C3, 0, 0
    BB,23C, 0, 0
    BC,2C1, 0,-2
    BD,23E,-2, 0
    BE,23F, 0,+4
    BF,2C0,+4, 0
    C0,140, 0,-6
    C1,1BF,-6, 0
    C2,1BE, 0,+4
    C3,141,+4, 0
    C4,1BC, 0,+2
    C5,143,+2, 0
    C6,217, 0, 0
    C7,2E8, 0, 0
    C8,1B8, 0, 0
    C9,147, 0, 0
    CA,213, 0,-2
    CB,2EC,-2, 0
    CC,211, 0,-4
    CD,2EE,-4, 0
    CE,2EF, 0,+6
    CF,210,+6, 0
    D0,1B0, 0,-2
    D1,14F,-2, 0
    D2,21B, 0, 0
    D3,2E4, 0, 0
    D4,219, 0,-2
    D5,2E6,-2, 0
    D6,2E7, 0,+4
    D7,218,+4, 0
    D8,21D, 0, 0
    D9,2E2, 0, 0
    DA,2E3, 0,+2
    DB,21C,+2, 0
    DC,2E1, 0, 0
    DD,21E, 0, 0
    DE,21F, 0,+2
    DF,2E0,+2, 0
    E0,1A0, 0,-4
    E1,15F,-4, 0
    E2,20B, 0,-2
    E3,2F4,-2, 0
    E4,209, 0,-4
    E5,2F6,-4, 0
    E6,2F7, 0,+6
    E7,208,+6, 0
    E8,20D, 0,-2
    E9,2F2,-2, 0
    EA,2F3, 0,+4
    EB,20C,+4, 0
    EC,2F1, 0,+2
    ED,20E,+2, 0
    EE,20F, 0, 0
    EF,2F0, 0, 0
    F0,205, 0,-4
    F1,2FA,-4, 0
    F2,2FB, 0,+6
    F3,204,+6, 0
    F4,2F9, 0,+4
    F5,206,+4, 0
    F6,207, 0,-2
    F7,2F8,-2, 0
    F8,2FD, 0,+6
    F9,202,+6, 0
    FA,203, 0,-4
    FB,2FC,-4, 0
    FC,201, 0,-6
    FD,2FE,-6, 0
    FE,2FF, 0,+8
    FF,200,+8, 0
    
  • TonyB_TonyB_ Posts: 2,107
    edited 2018-10-22 20:57
    And here are the TMDS data for FF-00 descending:

    8b = 8-bit input
    10b = 10-bit output
    dispi = disparity input from previous stage
    dispo = disparity output to next stage
    disparity = number of '1' bits - number of '0' bits for 8-bit value
    #8b,10b,dispi,dispo
    FF,200, 0,-8
    FE,2FF,-8, 0
    FD,2FE, 0,+6
    FC,201,+6, 0
    FB,2FC, 0,+4
    FA,203,+4, 0
    F9,202, 0,-6
    F8,2FD,-6, 0
    F7,2F8, 0,+2
    F6,207,+2, 0
    F5,206, 0,-4
    F4,2F9,-4, 0
    F3,204, 0,-6
    F2,2FB,-6, 0
    F1,2FA, 0,+4
    F0,205,+4, 0
    EF,2F0, 0, 0
    EE,20F, 0, 0
    ED,20E, 0,-2
    EC,2F1,-2, 0
    EB,20C, 0,-4
    EA,2F3,-4, 0
    E9,2F2, 0,+2
    E8,20D,+2, 0
    E7,208, 0,-6
    E6,2F7,-6, 0
    E5,2F6, 0,+4
    E4,209,+4, 0
    E3,2F4, 0,+2
    E2,20B,+2, 0
    E1,15F, 0,+4
    E0,1A0,+4, 0
    DF,2E0, 0,-2
    DE,21F,-2, 0
    DD,21E, 0, 0
    DC,2E1, 0, 0
    DB,21C, 0,-2
    DA,2E3,-2, 0
    D9,2E2, 0, 0
    D8,21D, 0, 0
    D7,218, 0,-4
    D6,2E7,-4, 0
    D5,2E6, 0,+2
    D4,219,+2, 0
    D3,2E4, 0, 0
    D2,21B, 0, 0
    D1,14F, 0,+2
    D0,1B0,+2, 0
    CF,210, 0,-6
    CE,2EF,-6, 0
    CD,2EE, 0,+4
    CC,211,+4, 0
    CB,2EC, 0,+2
    CA,213,+2, 0
    C9,147, 0, 0
    C8,1B8, 0, 0
    C7,2E8, 0, 0
    C6,217, 0, 0
    C5,143, 0,-2
    C4,1BC,-2, 0
    C3,141, 0,-4
    C2,1BE,-4, 0
    C1,1BF, 0,+6
    C0,140,+6, 0
    BF,2C0, 0,-4
    BE,23F,-4, 0
    BD,23E, 0,+2
    BC,2C1,+2, 0
    BB,23C, 0, 0
    BA,2C3, 0, 0
    B9,2C2, 0,-2
    B8,23D,-2, 0
    B7,238, 0,-2
    B6,2C7,-2, 0
    B5,2C6, 0, 0
    B4,239, 0, 0
    B3,2C4, 0,-2
    B2,23B,-2, 0
    B1,16F, 0,+4
    B0,190,+4, 0
    AF,230, 0,-4
    AE,2CF,-4, 0
    AD,2CE, 0,+2
    AC,231,+2, 0
    AB,2CC, 0, 0
    AA,233, 0, 0
    A9,167, 0,+2
    A8,198,+2, 0
    A7,2C8, 0,-2
    A6,237,-2, 0
    A5,163, 0, 0
    A4,19C, 0, 0
    A3,161, 0,-2
    A2,19E,-2, 0
    A1,19F, 0,+4
    A0,160,+4, 0
    9F,220, 0,-6
    9E,2DF,-6, 0
    9D,2DE, 0,+4
    9C,221,+4, 0
    9B,2DC, 0,+2
    9A,223,+2, 0
    99,177, 0,+4
    98,188,+4, 0
    97,2D8, 0, 0
    96,227, 0, 0
    95,173, 0,+2
    94,18C,+2, 0
    93,171, 0, 0
    92,18E, 0, 0
    91,18F, 0,+2
    90,170,+2, 0
    8F,2D0, 0,-2
    8E,22F,-2, 0
    8D,17B, 0,+4
    8C,184,+4, 0
    8B,179, 0,+2
    8A,186,+2, 0
    89,187, 0, 0
    88,178, 0, 0
    87,17D, 0,+4
    86,182,+4, 0
    85,183, 0,-2
    84,17C,-2, 0
    83,181, 0,-4
    82,17E,-4, 0
    81,17F, 0,+6
    80,180,+6, 0
    7F,280, 0,-6
    7E,27F,-6, 0
    7D,27E, 0,+4
    7C,281,+4, 0
    7B,27C, 0,+2
    7A,283,+2, 0
    79,282, 0,-4
    78,27D,-4, 0
    77,278, 0, 0
    76,287, 0, 0
    75,286, 0,-2
    74,279,-2, 0
    73,284, 0,-4
    72,27B,-4, 0
    71,12F, 0,+2
    70,1D0,+2, 0
    6F,270, 0,-2
    6E,28F,-2, 0
    6D,28E, 0, 0
    6C,271, 0, 0
    6B,28C, 0,-2
    6A,273,-2, 0
    69,127, 0, 0
    68,1D8, 0, 0
    67,288, 0,-4
    66,277,-4, 0
    65,123, 0,-2
    64,1DC,-2, 0
    63,121, 0,-4
    62,1DE,-4, 0
    61,1DF, 0,+6
    60,120,+6, 0
    5F,260, 0,-4
    5E,29F,-4, 0
    5D,29E, 0,+2
    5C,261,+2, 0
    5B,29C, 0, 0
    5A,263, 0, 0
    59,137, 0,+2
    58,1C8,+2, 0
    57,298, 0,-2
    56,267,-2, 0
    55,133, 0, 0
    54,1CC, 0, 0
    53,131, 0,-2
    52,1CE,-2, 0
    51,1CF, 0,+4
    50,130,+4, 0
    4F,290, 0,-4
    4E,26F,-4, 0
    4D,13B, 0,+2
    4C,1C4,+2, 0
    4B,139, 0, 0
    4A,1C6, 0, 0
    49,1C7, 0,+2
    48,138,+2, 0
    47,13D, 0,+2
    46,1C2,+2, 0
    45,1C3, 0, 0
    44,13C, 0, 0
    43,1C1, 0,-2
    42,13E,-2, 0
    41,13F, 0,+4
    40,1C0,+4, 0
    3F,240, 0,-6
    3E,2BF,-6, 0
    3D,2BE, 0,+4
    3C,241,+4, 0
    3B,2BC, 0,+2
    3A,243,+2, 0
    39,117, 0, 0
    38,1E8, 0, 0
    37,2B8, 0, 0
    36,247, 0, 0
    35,113, 0,-2
    34,1EC,-2, 0
    33,111, 0,-4
    32,1EE,-4, 0
    31,1EF, 0,+6
    30,110,+6, 0
    2F,2B0, 0,-2
    2E,24F,-2, 0
    2D,11B, 0, 0
    2C,1E4, 0, 0
    2B,119, 0,-2
    2A,1E6,-2, 0
    29,1E7, 0,+4
    28,118,+4, 0
    27,11D, 0, 0
    26,1E2, 0, 0
    25,1E3, 0,+2
    24,11C,+2, 0
    23,1E1, 0, 0
    22,11E, 0, 0
    21,11F, 0,+2
    20,1E0,+2, 0
    1F,2A0, 0,-4
    1E,25F,-4, 0
    1D,10B, 0,-2
    1C,1F4,-2, 0
    1B,109, 0,-4
    1A,1F6,-4, 0
    19,1F7, 0,+6
    18,108,+6, 0
    17,10D, 0,-2
    16,1F2,-2, 0
    15,1F3, 0,+4
    14,10C,+4, 0
    13,1F1, 0,+2
    12,10E,+2, 0
    11,10F, 0, 0
    10,1F0, 0, 0
    0F,105, 0,-4
    0E,1FA,-4, 0
    0D,1FB, 0,+6
    0C,104,+6, 0
    0B,1F9, 0,+4
    0A,106,+4, 0
    09,107, 0,-2
    08,1F8,-2, 0
    07,1FD, 0,+6
    06,102,+6, 0
    05,103, 0,-4
    04,1FC,-4, 0
    03,101, 0,-6
    02,1FE,-6, 0
    01,1FF, 0,+8
    00,100,+8, 0
    
  • cgraceycgracey Posts: 14,133
    edited 2018-10-21 19:55
    Right on, TonyB_!!! Those lists are exactly what I need. Thanks a lot for making those.
  • TonyB_TonyB_ Posts: 2,107
    edited 2018-10-22 17:05
    Re Verilog, the DVI/HDMI specs say that cnt = 0 when the display is not active so that it's always zero for the first pixel on a line, which means d[1] should clear cnt, if it doesn't do so now.
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    The new digital DAC mode works fine. For high-speed digital signalling, I don't think 8-bit precision is needed. 4-bit will be just fine.

    I like it. And I think having both levels of equal programming is worth going down to 4-bit.

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    cgracey wrote: »
    The new digital DAC mode works fine. For high-speed digital signalling, I don't think 8-bit precision is needed. 4-bit will be just fine.

    I like it. And I think having both levels of equal programming is worth going down to 4-bit.

    If I think how toggling can occur at 250MHz, 4 bits seems probably sufficient.
  • I found a bug in my TMDS software and 35 byte values were not encoded properly (but decoded fine). All the TMDS data have now been corrected. Chip, apologies if you started to use the wrong data.

    The total disparity for each of the sequences is now zero. They both end with disparity out = 0 so can be joined together to test 512 pixels.

    Below is the disparity distribution, which is the same for ascending and descending sequences:
    disparity: -8, -6, -4, -2,  0, +2, +4, +6, +8
    frequency:  1,  8, 18, 24,154, 24, 18,  8,  1
    
  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    I found a bug in my TMDS software and 35 byte values were not encoded properly (but decoded fine). All the TMDS data have now been corrected. Chip, apologies if you started to use the wrong data.

    The total disparity for each of the sequences is now zero. They both end with disparity out = 0 so can be joined together to test 512 pixels.

    Below is the disparity distribution, which is the same for ascending and descending sequences:
    disparity: -8, -6, -4, -2,  0, +2, +4, +6, +8
    frequency:  1,  8, 18, 24,154, 24, 18,  8,  1
    

    No problem. I am almost ready to run that test. First, I have to finish fixing this pins-disabled-messes-up-DAC-values problem.
  • cgraceycgracey Posts: 14,133
    TonyB_,

    I used your test data and our HDMI circuit puts out the same sequence. Thanks for doing that. Next, I'll wire up a connector and make sure we can run a monitor with it. I'll just use the P2 silicon to stream out an identical byte pattern that our new HDMI circuit would produce.
  • cgraceycgracey Posts: 14,133
    TonyB_,

    In order to fake HDMI on the P2 silicon, I made a routine to convert an 8-bit color into a 10-bit TMDS stream. The weird thing is that it seems to work fine when I get rid of the balance logic. When it's off, I match your pattern. When it's on, I get impossible values, like $3xx.

    Do you see the problem in this code? I don't get it.

    '
    '
    ' Convert R/G/B in color[7:0] into TMDS in color[9:0]
    '
    color_tmds	ones	bal_m,color		'ones > 4 || ones == 4 && !color[0]?
    		cmp	bal_m,#4	wcz
    	if_z	testb	color,#0	wc	'c=0 for XNOR
    
    		testb	color,#0	wz
      if_z_eq_c	bitnot	color,#1
    	
    		testb	color,#1	wz
      if_z_eq_c	bitnot	color,#2
    	
    		testb	color,#2	wz
      if_z_eq_c	bitnot	color,#3
    	
    		testb	color,#3	wz
      if_z_eq_c	bitnot	color,#4
    	
    		testb	color,#4	wz
      if_z_eq_c	bitnot	color,#5
    	
    		testb	color,#5	wz
      if_z_eq_c	bitnot	color,#6
    	
    		testb	color,#6	wz
      if_z_eq_c	bitnot	color,#7
    
    		bitc	color,#8
    
    		ones	bal_m,color		'get bal_m
    		sub	bal_m,#4	wcz	'sign of bal_m into c, (bal_m == 0) into z
    
    	if_nz	cmp	bal,#0		wz	'get (bal_m == 0 || bal == 0) into z
    
    		testbn	bal,#31		xorc	'get (bal_m[31] == bal[31]) into c
    		wrc	bal_sign		'get (bal_m[31] == bal[31]) into bal_sign
    
    	if_z	testbn	color,#8	wc	'inv_m = bal_zero ? !m[8] : bal_sign
    
    		bitc	color,#9		'finalize TMDS pattern
    	if_c	xor	color,#$FF
    ret  'STOPPING IT HERE MAKES IT WORK!
    		shl	bal_m,#1		'adjust bal
    
    		testbn	color,#8	wc	
    	if_z	jmp	#.sum
    
    		testb	bal_sign,#0	wc
    		testb	color,#8	wz
      if_c_eq_z	sumnc	bal,#2
    .sum	_ret_	sumc	bal,bal_m
    '
    '
    ' Data
    '
    color		res	1
    bal		res	1
    bal_m		res	1
    bal_sign	res	1
    
  • cgracey wrote: »
    TonyB_,

    In order to fake HDMI on the P2 silicon, I made a routine to convert an 8-bit color into a 10-bit TMDS stream. The weird thing is that it seems to work fine when I get rid of the balance logic. When it's off, I match your pattern. When it's on, I get impossible values, like $3xx.

    Do you see the problem in this code? I don't get it.

    Chip, I haven't looked at all the code because I don't really have time now for about five hours but I think I've spotted an error. After the XOR/XNOR-ing, you need to get bal_m using color[7:0], not color[8:0]. Swapping the order of two instructions might do the trick:

    Before
    ...
    		bitc	color,#8
    		ones	bal_m,color		'get bal_m
    ...
    

    After
    ...
    		ones	bal_m,color		'get bal_m
    		bitc	color,#8
    ...
    
  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    cgracey wrote: »
    TonyB_,

    In order to fake HDMI on the P2 silicon, I made a routine to convert an 8-bit color into a 10-bit TMDS stream. The weird thing is that it seems to work fine when I get rid of the balance logic. When it's off, I match your pattern. When it's on, I get impossible values, like $3xx.

    Do you see the problem in this code? I don't get it.

    Chip, I haven't looked at all the code because I don't really have time now for about five hours but I think I've spotted an error. After the XOR/XNOR-ing, you need to get bal_m using color[7:0], not color[8:0]. Swapping the order of two instructions might do the trick:

    Before
    ...
    		bitc	color,#8
    		ones	bal_m,color		'get bal_m
    ...
    

    After
    ...
    		ones	bal_m,color		'get bal_m
    		bitc	color,#8
    ...
    

    Wow! Good eye. I never noticed that. It would have taken me a long time to figure that out. Thank you.

    How can it be explained that without maintaining the balance, I get proper results?
  • I think the 2 extra bits in the 10-bit encoding are strictly to get DC balanced signal...you can have values that decode correctly, you just might miss the goal of a DC balanced signal.

    Jonathan
  • cgraceycgracey Posts: 14,133
    edited 2018-10-24 22:36
    lonesock wrote: »
    I think the 2 extra bits in the 10-bit encoding are strictly to get DC balanced signal...you can have values that decode correctly, you just might miss the goal of a DC balanced signal.

    Jonathan

    I wonder, though, if a display might reject a signal that is not encoded with the balance, too.
  • cgraceycgracey Posts: 14,133
    edited 2018-10-24 22:39
    While it doesn't take much hardware to encode HDMI, it gets quite obtuse in software.
  • Cluso99Cluso99 Posts: 18,066
    HDMI has a lot of patents. I wonder if the balancing is covered by one?
  • So, name that feature as C8T10BS (for Configurable 8 To 10 Bit Scrambler) , craft a way to upload the table (even serialy) into some dual-port ram bank, and give a gift to every software defined radio designer (Phil Pilgrim first, any others are welcome too) to use it and make P2 shine a little bit more.

    "Change the way you add scrambling to your private comms! Welcome to P2 C8T10BS!"

    The rest are "collateral effects".

    Henrique
  • cgraceycgracey Posts: 14,133
    We are using the 8b-->10b encoding shown in the 1999 spec from the "Digital Display Working Group". I think any patent on that would have expired after 19 years.
  • Cluso99Cluso99 Posts: 18,066
    Great. Hate these basic patents when there is nothing clever.
  • Ever heard of the one where they patented drawing mouse cursors using XOR?
  • TonyB_TonyB_ Posts: 2,107
    edited 2018-10-25 00:50
    cgracey wrote: »
    TonyB_ wrote: »
    cgracey wrote: »
    TonyB_,

    In order to fake HDMI on the P2 silicon, I made a routine to convert an 8-bit color into a 10-bit TMDS stream. The weird thing is that it seems to work fine when I get rid of the balance logic. When it's off, I match your pattern. When it's on, I get impossible values, like $3xx.

    Do you see the problem in this code? I don't get it.

    Chip, I haven't looked at all the code because I don't really have time now for about five hours but I think I've spotted an error. After the XOR/XNOR-ing, you need to get bal_m using color[7:0], not color[8:0]. Swapping the order of two instructions might do the trick:

    Before
    ...
    		bitc	color,#8
    		ones	bal_m,color		'get bal_m
    ...
    

    After
    ...
    		ones	bal_m,color		'get bal_m
    		bitc	color,#8
    ...
    

    Wow! Good eye. I never noticed that. It would have taken me a long time to figure that out. Thank you.

    How can it be explained that without maintaining the balance, I get proper results?

    Chip, is the routine working now, with the same outputs and disparities as the ascending and descending sequences?

    If you look at the sequences here or here, you can see a non-zero disparity is always followed by zero disparity. I think this is due to the consecutive inputs and doesn't apply when they are more random, e.g.
    0E,1FA, 0,+4
    0F,105,+4, 0
    10,1F0, 0, 0
    
    0E,1FA, 0,+4
    10,1F0,+4,+4
    

    10h is one of 52 byte values that encode to a single 10-bit value, no matter what the disparity input, which is output unchanged. The very regular nature of an up or down counter might explain in part why the erroneous routine had the correct outputs.
  • cgraceycgracey Posts: 14,133
    TonyB_, maybe ascending and descending sequences shelter us from seeing some of the balancer's effects. Could you make a random byte sequence converted into 10b TMDS?
  • cgraceycgracey Posts: 14,133
    I've been running errands and haven't had time to try these new ideas out, yet.
  • cgraceycgracey Posts: 14,133
    TonyB_, switching those two instructions around fixed the problem.

    I just found that, indeed, the ascending/descending values are unaffected by the balancer. However, when I make a random sequence from XORO32, the balancer makes a big difference. So, those ascending/descending patterns don't completely exercise the encoder like random data does.

    Could you please make a random pattern that I could verify against? My balancer is doing something, but I'm not sure if it's correct, yet.

    Thanks!!!
Sign In or Register to comment.