composite video benefits with Propeller over digital VGA/HDMI

ngeneer

@cgracey , you mentioned on the monthly chat last night :

• some lament that displays didn't come with composite inputs anymore,
• and that there should be some interface chip that made HDMI easier,
• and that it was tough to get practically beyond VGA resolution with VGA interface....

could we get some benefit of using a display with an interface board like this for the benchtop scope that we spoke of?

this for $25 https://www.ebay.com/itm/155261814079
add cap touch for $25

evanh

What's difficult about HDMI on the Prop2? It seems pretty easy to setup to me.

msrobots

number of needed pins. composite is just one pin

ngeneer

@msrobots said:
number of needed pins. composite is just one pin

@evanh

there was also something about the high resolution and frame rate for driving pins directly. I guess the issue was driving pins direct (with only passives), which I was sort of going for.... but at these prices for common parts, it might be hard to justify. I just forget the particulars, and how composite might give unique capabilites.

cgracey

We can signal 640x480 at 60fps over HDMI. That requires a 250MHz clock speed.

Going higher resolution, we can signal 720p (1280x720) over HMDI, but must drop to a lower frame rate, like 30fps. That would require a system clock of 276.48MHz.

We cannot get to 1080-line resolution over HDMI, though, even at 24fps. 1080i at 24fps would still require a pixel rate of 49.7664MHz, needing a system clock of 497.664MHz for HDMI.

So, 720p is the top-end of what is practical.

evanh

Those are limits, not difficulties.

potatohead

Component displays offer basically a monochrome composite input on the Y channel. That's still one pin, and it can go all the way to 1080i on capable displays and a fair number will do 1080p. If you don't need color, this is a super nice option because a driver can basically drive just about any display from the early composite monitors we saw on computers in the 70's and 80's through just about all TV sets, with component ones offering high resolution.

That said, component is fading, and may be entirely gone on new sets. I've not looked. My preference for component over RGB / VGA, was having that one pin Y channel. It's easy, robust.

Seems to me, an analog to HDMI breakout board of some kind might be a good answer. Maybe there is a pretty flexible chip out there that can take a variety of analog signals. Drivers could be tuned to basically be pixel perfect for that particular board. And or maybe drop one onto the next P2 dev board too, just to solidify a standard.

Ideally, it's cheap.

Side note: Hey everyone! I'm still around, just busy.

potatohead

https://www.camius.com/cvbs-ahd-hd-tvi-hd-cvi-analog-camera-connection/

I was unaware there is actually higher resolution composite video!

HD TVI Camera
HD-CVI (High Definition Composite Video Interface) is an analog transmission standard-based over-coaxial cable delivering two HD video formats: 1920H or called otherwise, Full HD 1080P (1920×1080) & 1280H or called otherwise 720P (1280×720) through progressive scanning.

HD CVI camera
HD-CVI (High Definition Composite Video Interface) is an analog transmission standard-based over-coaxial cable delivering two HD video formats: 1920H or called otherwise, Full HD 1080P (1920×1080) & 1280H or called otherwise 720P (1280×720) through progressive scanning.

Looks like one is interlaced and one is progressive. What displays or chips decode this? The P2 should be able to modulate the signal.

https://www.walmart.com/ip/101AV-19-5-ECO-5MP-SUPER-HD-HD-TVI-AHD-CVI-CVBS-SECURITY-MONITOR-1-HDMI-AND-2-BNC-INPUTS-1-BNC-OUTPUTS/5267869793?wmlspartner=wlpa&selectedSellerId=6824

https://shopdelta.eu/test_l2_aid752.html

25 FPS @ 1080p

https://www.monoprice.com/product?p_id=16178&utm_term&utm_campaign=PMax | Offers | Too Many Sale | Monoprice&utm_source=google&utm_medium=cpc&gad_source=1

Hmmm

evanh

Good to see you Doug. How's the long term effects of that early Covid-19 going?

pik33

and that it was tough to get practically beyond VGA resolution with VGA interface....

Where was the problem? I have 1080p50 on VGA and I think 60 is also possible. The only problem is where to keep a framebuffer? Of course, it can be PSRAM on EC32, that gives 8bpp at this resolution. Without PSRAM, we can do 1bpp or tile/sprite/character drivers.

However, 1080p seems to be the real maximum for a vga. Maybe 2048x1152 if the monitor supports this, as there is 200 MHz upper limit for the pixel clock. I had mixed results trying to output 2560x1440. Even if I got a picture, it was unstable.

cgracey

@cgracey said:
We can signal 640x480 at 60fps over HDMI. That requires a 250MHz clock speed.

Going higher resolution, we can signal 720p (1280x720) over HMDI, but must drop to a lower frame rate, like 30fps. That would require a system clock of 276.48MHz.

We cannot get to 1080-line resolution over HDMI, though, even at 24fps. 1080i at 24fps would still require a pixel rate of 49.7664MHz, needing a system clock of 497.664MHz for HDMI.

So, 720p is the top-end of what is practical.

I wrote a 720p driver tonight, but my Samsung TV's won't display the signal. I am doing 720p at 24fps, which needs a clock of 297MHz, which is doable. I think I am generating the signal right, but it won't show. Seems like 640 x 480 is maybe the practical limit of P2 HDMI these days.

rogloh

I found a good way to go if you really want hi-res HDMI like 1080p60 is to use VGA output from the P2 at that resolution and then convert to HDMI with a cheapo converter like this which does a fairly reasonable job, (plus in theory they can add analog audio to the output too).
https://www.centrecom.com.au/simplecom-cm201-full-hd-1080p-vga-to-hdmi-converter-with-audio
If I can source the chip I might like to make a P2 breakout board for it one day....EDIT: HW appears to use a MacroSilicon MS9288A part or similar.

cgracey

@rogloh said:
I found a good way to go if you really want hi-res HDMI like 1080p60 is to use VGA output from the P2 at that resolution and then convert to HDMI with a cheapo converter like this which does a fairly reasonable job, (plus in theory they can add analog audio to the output too).
https://www.centrecom.com.au/simplecom-cm201-full-hd-1080p-vga-to-hdmi-converter-with-audio
If I can source the chip I might like to make a P2 breakout board for it one day....EDIT: HW appears to use a MacroSilicon MS9288A part or similar.

I have a component-to-HDMI converter that works pretty well. It was about the same price. VGA would be a little tidier.

cgracey

I have an idea...

What if we upped the clock signal frequency in the HDMI output by using smart pins to generate a pattern other than the normal HDMI clock pattern of:

CLK+ : 1111100000...
CLK- : 0000011111...

If we did something like...

CLK+ : 10...
CLK- : 01...

Could we then push more shorter (lower-res) data at 2 clocks/pixel, instead of 8-bit data at 10 clocks/pixel? Maybe we could do 1 effective bit for R, G, and B at 2 clocks/pixel. That would let us get up to 1080p over HDMI.

I wonder how strict the TMDS decoders are in TVs.

Thinking more about this, I think we wouldn't be able to convey SYNC information at that speed. If we slowed down for SYNC output, all the way back to normal HDMI rate (10 clocks/pixel), it would probably cause the PLL in the TV to lose lock and not see things properly.

cgracey

I am reading the CTA-861-G HDTV spec and the reason my 720p 24fps HDMI driver doesn't work is because the mode actually demands 2020 horizontal blanking pixels for each 1280 visible pixels! This needs a pixel rate of 59.4MHz. That means a 595MHz HDMI bit rate. Too bad.

Wuerfel_21

@cgracey said:
I wonder how strict the TMDS decoders are in TVs.

Not very. When I was doing some testing, I got very confused one time because I forget to disable the audio DAC pins on +6 and +7, which are the red TMDS channel. TVs don't care, just turned that into noise. Probably do need proper sync characters on the blue channel though. Will most likely not work with data islands at all.

The solution to such things would be an external TMDS encoder. Though that'd take up like a whole port for RGB parallel pins. Redigitizing the DAC output seems really janky and also probably the sort of thing where buying the entire external VGA converter box is cheaper than buying the IC.

cgracey

@Wuerfel_21 said:

@cgracey said:
I wonder how strict the TMDS decoders are in TVs.

Not very. When I was doing some testing, I got very confused one time because I forget to disable the audio DAC pins on +6 and +7, which are the red TMDS channel. TVs don't care, just turned that into noise. Probably do need proper sync characters on the blue channel though. Will most likely not work with data islands at all.

The solution to such things would be an external TMDS encoder. Though that'd take up like a whole port for RGB parallel pins. Redigitizing the DAC output seems really janky and also probably the sort of thing where buying the entire external VGA converter box is cheaper than buying the IC.

That seems to be the case.

I have got a good 16:9 HDMI display going at 320MHz. It's 860 x 484. That's about 416k pixels. I'm thinking RGB16 would be a good fit. A screen would take 832KB. Because the pixel rate is only 32MHz, that would leave a lot of time for the PSRAM to read and write for other purposes. I think RGB16 would be sufficient for alpha-blending, like in the DEBUG displays, but ON the P2, itself.

On the P2 Edge w/32MB of PSRAM, pins 32..39 could be the HDMI port. Some lower pins could be USB for mouse and keyboard, leaving lots for applications. I think HDMI is important because it's a compact solution that works on all modern TVs. I'm thinking of a small self-contained computer here. The best mouse/keyboard combo is the wireless dongle - only two pins and no cables needed, which is really clean. Bitmap graphics at all times would be nice.

One last piece of the puzzle needed is embedding audio packets in the HDMI stream. Then, we'd have all the basics:

1) Bitmap HDMI graphics w/sound
2) Wireless USB keyboard and mouse
3) Flash SSD - instantly ready on boot
4) uSD driver (still needed, actually)

Here's a picture of the 860 x 480 HDMI driver running on a 43" TV with 5x7 font.

iseries

Hey, I have one of those VGA to HDMI convertors that I bought a long time ago. It's from Adafruit and only cost $14.95. Have never used it though.

Mike

Wuerfel_21

@cgracey said:
One last piece of the puzzle needed is embedding audio packets in the HDMI stream. Then, we'd have all the basics:

Done already, sortof. See later posts in https://forums.parallax.com/discussion/175594/true-hdmi-with-data-packets.

Still need to integrate that into a non-testbed program (like the game emulators), but didn't do any work on that lately (it's troublesome because I need to sit on the floor in the living room with my thinkpad). Also it just doesn't work for Roger and has whacky plasma TV.

cgracey

@Wuerfel_21 said:

@cgracey said:
One last piece of the puzzle needed is embedding audio packets in the HDMI stream. Then, we'd have all the basics:

Done already, sortof. See later posts in https://forums.parallax.com/discussion/175594/true-hdmi-with-data-packets.

Still need to integrate that into a non-testbed program (like the game emulators), but didn't do any work on that lately (it's troublesome because I need to sit on the floor in the living room with my thinkpad). Also it just doesn't work for Roger and has whacky plasma TV.

That is great!!

pik33

I wrote a 720p driver tonight, but my Samsung TV's won't display the signal. I am doing 720p at 24fps, which needs a clock of 297MHz, which is doable. I think I am generating the signal right, but it won't show. Seems like 640 x 480 is maybe the practical limit of P2 HDMI these days.

If you reduce the refresh rate to 50 Hz, 1024x600 is possible on HDMI at ~340 MHz. All monitors I tried this on work OK, although timings are somewhat stretched over limits - 1024x576 may be more stable, but there are 1024x600 HDMI LCD displays. We tested this with Waveshare touch display and even got touch reports from the usbnew driver.The example of using this resolution is my Basic interpreter for EC32 ( https://github.com/pik33/P2-Retromachine-Basic )

cgracey

@pik33 said:

I wrote a 720p driver tonight, but my Samsung TV's won't display the signal. I am doing 720p at 24fps, which needs a clock of 297MHz, which is doable. I think I am generating the signal right, but it won't show. Seems like 640 x 480 is maybe the practical limit of P2 HDMI these days.

If you reduce the refresh rate to 50 Hz, 1024x600 is possible on HDMI at ~340 MHz. All monitors I tried this on work OK, although timings are somewhat stretched over limits - 1024x576 may be more stable, but there are 1024x600 HDMI LCD displays. We tested this with Waveshare touch display and even got touch reports from the usbnew driver.The example of using this resolution is my Basic interpreter for EC32 ( https://github.com/pik33/P2-Retromachine-Basic )

That would be great, but I worry it's very close to the timing limis of the P2. That's amazing you are able to achieve that. Do you feel confident enough in it that you would sell it as a commercial product?

cgracey

960 x 540, in theory, would be really good, because it would map integrally to 2K and 4K 16:9 displays, needing only ~309MHz for 50fps..

SaucySoliton

@cgracey said:
I have an idea...

What if we upped the clock signal frequency in the HDMI output by using smart pins to generate a pattern other than the normal HDMI clock pattern of:

CLK+ : 1111100000...
CLK- : 0000011111...

If we did something like...

CLK+ : 10...
CLK- : 01...

Could we then push more shorter (lower-res) data at 2 clocks/pixel, instead of 8-bit data at 10 clocks/pixel? Maybe we could do 1 effective bit for R, G, and B at 2 clocks/pixel. That would let us get up to 1080p over HDMI.

I wonder how strict the TMDS decoders are in TVs.

Thinking more about this, I think we wouldn't be able to convey SYNC information at that speed. If we slowed down for SYNC output, all the way back to normal HDMI rate (10 clocks/pixel), it would probably cause the PLL in the TV to lose lock and not see things properly.

Funny that the transition minimization part doesn't seem to apply to the sync words.

.sync_000       long    %1101010100_1101010100_1101010100_10    '
.sync_001       long    %1101010100_1101010100_0010101011_10    '        hsync
.sync_002       long    %1101010100_1101010100_0101010100_10    'vsync
.sync_003       long    %1101010100_1101010100_1010101011_10    'vsync + hsync

Maybe there would be a small and cheap FPGA to build our own TMDS serializer. That way we wouldn't need as many pins as most encoder chips do. It could even have a palette ram. Maybe 1 pin clock, 7 pins data. Out of the 128 combos, 4 would be for sync, 16 for TERC4 for audio. That would leave 108 colors.

Too bad AHD to HDMI converters weren't as cheap as component and VGA. https://forums.parallax.com/discussion/175430/p2-outputting-hi-def-using-ahd-video-camera-format

I think it would be possible to generate an ATSC signal on channel 3, with much effort. Then the MPEG "encoder" looks up a pre-encoded macroblock for each character on the screen. Scrolling could be done with motion vectors. Basically the MPEG decoder in the TV would become our graphics processor. Might work for DVB-T too https://github.com/steve-m/fl2k-examples/tree/master/DVB-T I've ran an ATSC transmitter with a PC and SDR before. Almost maxed out a Phenom II quad core. That didn't include the MPEG encoder. It was just streaming a pre-recorded MPEG-TS file. Chances are most of that load was a polyphase sample rate converter. If we are using a direct cable connection the P2 could skip the filtering that is required for on-air use. The data into RF modulator stage is 3 bits (for 8 VSB levels) at 10.76MHz sample rate. The P2 streamer could just run at that rate.

Wuerfel_21

@SaucySoliton said:
Maybe there would be a small and cheap FPGA to build our own TMDS serializer. That way we wouldn't need as many pins as most encoder chips do. It could even have a palette ram. Maybe 1 pin clock, 7 pins data. Out of the 128 combos, 4 would be for sync, 16 for TERC4 for audio. That would leave 108 colors.

That would be rather inefficient. You really want 8 data pins so you can actually stream pixel data directly into it at high resolution. Also, TERC4 mode has 4096 states since all three channels transmit together (though 3 bits of channel 0 are somewhat redundant (sync state and start bit (?)). You also didn't think about guard bands. Really, such a thing needs to be modal. That is, it is in sync mode by default and then is sent something like "1920 video characters follow", then it emits the guard band and starts serializing pixels in the given format until it's done.

cgracey

There are some cheap FPGAs which could serve as HDMI drivers.

The P2 can stream data out via the streamer, 8 bits at a time, if you want. That could go right into the FPGA in 2 clocks for a 16-bit 5:6:5 pixel. Better yet, do 5:5:5 and use the other bit for sync. Then, we could do a pixel in two clocks, instead of 10, having the FPGA do the TMDS encoding and output. That would get us to 297Mhz (P2 freq) / 2 for a 148.5MHz pixel rate, which would do 1080p.

4k (2160p) requires a pixel rate of 594MHz. I suppose we could stream nibbles at that rate, which could go though a palette lookup and result in a TMDS signal of 5.94Ghz.

cgracey

It seems my Samsung 4k TV won't go below 60Hz on refresh rate. Maybe this is an issue with TV's sold in North America. I can see on the back of my TV that there is an 'HDMI' panel that could have also been a 'Component' panel. It's the same basic TV dressed out for different markets.

Any idea if TV's sold in Europe won't do 60Hz refresh?

Wuerfel_21

@cgracey said:
Better yet, do 5:5:5 and use the other bit for sync.

But then you couldn't use RGBSQZ for rendering, which would slow things down a huge lot (imagine the equivalent instructions) when doing blending or shading operations (on top of already slow pixel ops). Though in some ways 5:5:5 is a superior format - true grays and ability to use the extra bit as alpha. (Speaking of, there's a really clever RGBA format that I'm pretty sure was invented by ArtX for the Gamecube GPU and never made it anywhere else - when the MSB is set, it's a 5:5:5:0 solid color, when the MSB is clear it's a 4:4:4:3 translucent color)

@cgracey said:
It seems my Samsung 4k TV won't go below 60Hz on refresh rate. Maybe this is an issue with TV's sold in North America. I can see on the back of my TV that there is an 'HDMI' panel that could have also been a 'Component' panel. It's the same basic TV dressed out for different markets.

Any idea if TV's sold in Europe won't do 60Hz refresh?

All TVs should be able to do 50 and 60. 50Hz may only be supported on certain modes if your TV is fussy (try 720x576). But 60Hz is super definitely supported everywhere.

cgracey

Ada, some of these modes call for inverted SYNC polarities.

Do I just change this:

sync_000    long    %1101010100_1101010100_1101010100_10    '
sync_001    long    %1101010100_1101010100_0010101011_10    '        hsync
sync_222    long    %0101010100_0101010100_0101010100_10    'vsync
sync_223    long    %0101010100_0101010100_1010101011_10    'vsync + hsync

to this?

sync_000    long    %0101010100_0101010100_1010101011_10    '!vsync + !hsync
sync_001    long    %0101010100_0101010100_0101010100_10    '!vsync
sync_222    long    %1101010100_1101010100_0010101011_10    '         !hsync
sync_223    long    %1101010100_1101010100_1101010100_10    '

Wuerfel_21

Maybe? Is that a thing even? Just try it without and see how that goes.

cgracey

@Wuerfel_21 said:
Maybe? Is that a thing even? Just try it without and see how that goes.

It seems to not really care.

I also found that I can minimize blanking times down to minimums. The only thing that seems to matter is if there are sufficient blank lines before the image starts. The VSYNC can be done right after the last visible line.