Seems encryption can be done with DVI too... So, I guess it's mainly sound that HDMI adds.
But, you can transmit video only over HDMI as it is backwards compatible with DVI...
I was reading something that made it sound like there were more possible control tokens defined...
I think video only needs two bits though for hsync and vsync, or something like that...
More tokens than the four for the syncs would require more hardware. They couldn't be done in software.
Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.
More tokens than the four for the syncs would require more hardware. They couldn't be done in software.
Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.
If more are needed, is there a simple bypass of the 8b:10b encode that can be used ?
with 32b in, it seems there could even be room to allow 2 bits to control direct pass thru of codes, up to 3 fields if needed (do these get used adjacent ?)
11b => 3 x 10b size from 30 bits
10b => 2 x 10b size from 20 bits
01b => 1 x 10b size from 10 bits
00_ccccccb => 8b:10b encode of 24 bits, 6 bits spare for specific HW codes if required.
In this 8-bit to 10-bit encoder, the TMDS state machine generates needed tokens from the input bytes. There are also four special control codes that can be sent which are different from the byte-data tokens. That is all that can be done. Something like audio would be at a higher level, where you would probably use control codes to signal the data. point is, I think we have all the hardware that would ever be needed.
Okay if it is just the regular 4 control preamble 10 bit values required for the H/V sync inputs on channel 0 plus the other 256 input combinations for 8 bits of video per channel that your streamer supports then I am not sure if any audio or other HDMI functions will be possible as they require special 10 bit values to be sent which might not be generated by 8 bits (but I didn't check that).
The data guard band needs to be able to send 10'b0100110011 for two of the channels.
The video guard band needs to be abled to send 10'b1011001100 and 10'b0100110011.
The actual 10bit values for the TERC4 4 bit mappings I believe are found in the code below.
DVI only is still okay, but not quite as flexible as full HDMI.
The data guard band needs to be able to send 10'b0100110011 for two of the channels.
The video guard band needs to be abled to send 10'b1011001100 and 10'b0100110011.
The actual 10bit values for the TERC4 4 bit mappings I believe are found in the code below.
Do those ever send adjacent ?
Could a optional direct 10b pathway, as I suggest above, cover those, without needing the extra verilog to hard-code them ?
More tokens than the four for the syncs would require more hardware. They couldn't be done in software.
Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.
If more are needed, is there a simple bypass of the 8b:10b encode that can be used ?
with 32b in, it seems there could even be room to allow 2 bits to control direct pass thru of codes, up to 3 fields if needed (do these get used adjacent ?)
11b => 3 x 10b size from 30 bits
10b => 2 x 10b size from 20 bits
01b => 1 x 10b size from 10 bits
00_ccccccb => 8b:10b encode of 24 bits, 6 bits spare for specific HW codes if required.
That's an interesting idea, jmg. This could reduce logic needed slightly.
The data guard band needs to be able to send 10'b0100110011 for two of the channels.
The video guard band needs to be abled to send 10'b1011001100 and 10'b0100110011.
The actual 10bit values for the TERC4 4 bit mappings I believe are found in the code below.
Do those ever send adjacent ?
Could a optional direct 10b pathway, as I suggest above, cover those, without needing the extra verilog to hard-code them ?
Video guard band has 10'b1011001100 on channels 0 (B) & 2 (R) and 10'b0100110011 on channel 1 (G) at the same time.
In terms of adjacency well you need to be able to switch from sending the SYNC preambles to a guard band pattern to a bunch of TERC4 encoded 10b symbols to guard band to preamble to guard band to active video on a minimum of 2 pixel boundaries if you want to support HDMI data packets being mixed with the video/sync stuff.
More accurately, the guard bands have to be 2 pixels wide (same symbol in both pixels). Packets and active video tend to be a multiple of 8 bits.
Would be great if could do dual-link DVI to get SVGA at 800x600.
Seems technically feasible but maybe no monitor would take it?
I think most older consumer grade DL-DVI monitors were built for higher resolutions such as 2560x1600 (I have a Dell one), and they don't use DL-DVI for their lower resolutions. Perhaps some monitors software would allow 800x600 using dual link but I don't think the market will be very big. DL-DVI didn't seem to last too long before Display port and HDMI monitor interfaces took over.
Video guard band has 10'b1011001100 on channels 0 (B) & 2 (R) and 10'b0100110011 on channel 1 (G) at the same time.
Ah ok, so my idea can always load 3 x 10b bypass codes for R,G,B and I presume any unused slot has a NOP form ?
That also simplifies streamer as the feed rate is always the same.
Video guard band has 10'b1011001100 on channels 0 (B) & 2 (R) and 10'b0100110011 on channel 1 (G) at the same time.
Ah ok, so my idea can always load 3 x 10b bypass codes for R,G,B and I presume any unused slot has a NOP form ?
That also simplifies streamer as the feed rate is always the same.
I wrote first sentence, expanding on what rogloh said.
If bit 0 of the long were used as the Display Enable (not_Blanking) signal, it could select either:
24-bit RGB data in bits 31-8 to be converted into three 10-bit symbols by TMDS, or
3 x 10-bit control symbols in bits 31-2, with no conversion required.
I wrote first sentence, expanding on what rogloh said.
If bit 0 of the long were used as the Display Enable (not Blanking) signal, it could select either:
24-bit RGB data in bits 8-31 to be converted into three 10-bit symbols by TMDS, or
3 x 10-bit control symbols in bits 2-31, with no conversion required.
Yup, does that cover all the bases, and save some logic at the same time ?
Sorry jmg, I misunderstood what you asked about adjacency, but now I know what you meant.
Yes I think allowing data being streamed out to be able to inject raw 10bit symbols on individual pixel boundaries (differently per channel) would fix all the HDMI formatting issues. If the streamer can do this that would be great. I guess you just need an extra mux to select between serially shifted raw 10bits for that channel read from the 32 bit word or the usual 8b10b mapped RGB output.
I am wondering if we could just use smart pins as a UART(s) with a variable number of bits (eg 10 bits). We would need to be able to sync the smart pins though.
We would effectively be sending 4 bits at 250MHz.
Should be able to test this out with the current P2 chip, even if it takes 4 cogs to try it.
Right. I was just looking over the murky details of audio inclusion and it seems we'd need to be able to put raw 10-bit packets down each lane. No problem, because we have the bits. Here's how it will work:
rrrrrrrr_gggggggg_bbbbbbbb_xxxxxx00 = 8b/10b pixel encoding
xxxxxxxx_xxxxxxxx_xxxxxxxx_rrggbb01 = 2b/10b control encoding
rrrrrrrrrr_gggggggggg_bbbbbbbbbb_1x = raw 10b encoding
Right. I was just looking over the murky details of audio inclusion and it seems we'd need to be able to put raw 10-bit packets down each lane. No problem, because we have the bits. Here's how it will work:
rrrrrrrr_gggggggg_bbbbbbbb_xxxxxx00 = 8b/10b pixel encoding
xxxxxxxx_xxxxxxxx_xxxxxxxx_rrggbb01 = 2b/10b control encoding
rrrrrrrrrr_gggggggggg_bbbbbbbbbb_1x = raw 10b encoding
Yes, that seems flexible.
Can the middle line, be swallowed into the bottom line, if that saves significant logic ?
Right. I was just looking over the murky details of audio inclusion and it seems we'd need to be able to put raw 10-bit packets down each lane. No problem, because we have the bits. Here's how it will work:
rrrrrrrr_gggggggg_bbbbbbbb_xxxxxx00 = 8b/10b pixel encoding
xxxxxxxx_xxxxxxxx_xxxxxxxx_rrggbb01 = 2b/10b control encoding
rrrrrrrrrr_gggggggggg_bbbbbbbbbb_1x = raw 10b encoding
Yes, that seems flexible.
Can the middle line, be swallowed into the bottom line, if that saves significant logic ?
This is sounding pretty cool. How many HDMI displays can a P2 drive at the same time?
Eight.
Wow! Maybe JRetSapDoog can make an HDMI version of his WordFire/Quby four screen game console. This is 640x480, right?
Yes, but to get unique screens at that resolution, you'd have to use a tile mode to conserve memory.
640*480 could be realized as 80x60 of 8x8-pixel tiles. That would only be 4800 bytes for 8-bit tile pointers or 9600 bytes for 16-bit tile pointers. 9600 bytes * 8 screens = 76,800 bytes. That's only ~15% of P2 hub RAM. Then, you'd need the tile definitions, which would be 64 bytes per for 8bpp tiles.
This is sounding pretty cool. How many HDMI displays can a P2 drive at the same time?
Eight.
Wow! Maybe JRetSapDoog can make an HDMI version of his WordFire/Quby four screen game console. This is 640x480, right?
Yes, but to get unique screens at that resolution, you'd have to use a tile mode to conserve memory.
640*480 could be realized as 80x60 of 8x8-pixel tiles. That would only be 4800 bytes for 8-bit tile pointers or 9600 bytes for 16-bit tile pointers. 9600 bytes * 8 screens = 76,800 bytes. That's only ~15% of P2 hub RAM. Then, you'd need the tile definitions, which would be 64 bytes per for 8bpp tiles.
That shouldn't be much of a problem since his console is primarily for word games. Tile graphics should be interesting as well.
Comments
https://www.fpga4fun.com/files/WP_TMDS.pdf
Seems encryption can be done with DVI too... So, I guess it's mainly sound that HDMI adds.
But, you can transmit video only over HDMI as it is backwards compatible with DVI...
There is also a data enable signal, DE.
If more are needed, is there a simple bypass of the 8b:10b encode that can be used ?
with 32b in, it seems there could even be room to allow 2 bits to control direct pass thru of codes, up to 3 fields if needed (do these get used adjacent ?)
11b => 3 x 10b size from 30 bits
10b => 2 x 10b size from 20 bits
01b => 1 x 10b size from 10 bits
00_ccccccb => 8b:10b encode of 24 bits, 6 bits spare for specific HW codes if required.
Okay if it is just the regular 4 control preamble 10 bit values required for the H/V sync inputs on channel 0 plus the other 256 input combinations for 8 bits of video per channel that your streamer supports then I am not sure if any audio or other HDMI functions will be possible as they require special 10 bit values to be sent which might not be generated by 8 bits (but I didn't check that).
The data guard band needs to be able to send 10'b0100110011 for two of the channels.
The video guard band needs to be abled to send 10'b1011001100 and 10'b0100110011.
The actual 10bit values for the TERC4 4 bit mappings I believe are found in the code below.
DVI only is still okay, but not quite as flexible as full HDMI.
Do those ever send adjacent ?
Could a optional direct 10b pathway, as I suggest above, cover those, without needing the extra verilog to hard-code them ?
That's an interesting idea, jmg. This could reduce logic needed slightly.
Video guard band has 10'b1011001100 on channels 0 (B) & 2 (R) and 10'b0100110011 on channel 1 (G) at the same time.
In terms of adjacency well you need to be able to switch from sending the SYNC preambles to a guard band pattern to a bunch of TERC4 encoded 10b symbols to guard band to preamble to guard band to active video on a minimum of 2 pixel boundaries if you want to support HDMI data packets being mixed with the video/sync stuff.
More accurately, the guard bands have to be 2 pixels wide (same symbol in both pixels). Packets and active video tend to be a multiple of 8 bits.
Seems technically feasible but maybe no monitor would take it?
I think most older consumer grade DL-DVI monitors were built for higher resolutions such as 2560x1600 (I have a Dell one), and they don't use DL-DVI for their lower resolutions. Perhaps some monitors software would allow 800x600 using dual link but I don't think the market will be very big. DL-DVI didn't seem to last too long before Display port and HDMI monitor interfaces took over.
Ah ok, so my idea can always load 3 x 10b bypass codes for R,G,B and I presume any unused slot has a NOP form ?
That also simplifies streamer as the feed rate is always the same.
I wrote first sentence, expanding on what rogloh said.
If bit 0 of the long were used as the Display Enable (not_Blanking) signal, it could select either:
24-bit RGB data in bits 31-8 to be converted into three 10-bit symbols by TMDS, or
3 x 10-bit control symbols in bits 31-2, with no conversion required.
Yup, does that cover all the bases, and save some logic at the same time
Yes I think allowing data being streamed out to be able to inject raw 10bit symbols on individual pixel boundaries (differently per channel) would fix all the HDMI formatting issues. If the streamer can do this that would be great. I guess you just need an extra mux to select between serially shifted raw 10bits for that channel read from the 32 bit word or the usual 8b10b mapped RGB output.
We would effectively be sending 4 bits at 250MHz.
Should be able to test this out with the current P2 chip, even if it takes 4 cogs to try it.
Yes, that seems flexible.
Can the middle line, be swallowed into the bottom line, if that saves significant logic ?
Good point! Yes, it can, and might as well be.
Or this?
Eight.
Yes, but to get unique screens at that resolution, you'd have to use a tile mode to conserve memory.
640*480 could be realized as 80x60 of 8x8-pixel tiles. That would only be 4800 bytes for 8-bit tile pointers or 9600 bytes for 16-bit tile pointers. 9600 bytes * 8 screens = 76,800 bytes. That's only ~15% of P2 hub RAM. Then, you'd need the tile definitions, which would be 64 bytes per for 8bpp tiles.