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?
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:
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:
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:
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.
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 = 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
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.
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:
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:
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.
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
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:
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.
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.
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!"
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.
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.
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?
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.
Comments
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?
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.
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 = 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
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.
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:
No problem. I am almost ready to run that test. First, I have to finish fixing this pins-disabled-messes-up-DAC-values problem.
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.
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
After
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?
Jonathan
I wonder, though, if a display might reject a signal that is not encoded with the balance, too.
"Change the way you add scrambling to your private comms! Welcome to P2 C8T10BS!"
The rest are "collateral effects".
Henrique
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.
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.
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!!!