4 ms·

VGA was designed for CRTs. I am amazed how well it has been supported by digital monitors. Still, I am left wondering, how hard would it be to make something si

VGA was designed for CRTs. I am amazed how well it has been supported by digital monitors. Still, I am left wondering, how hard would it be to make something similar for a modern digital interface, say, DVI?

jshap70 6y ago
DVI is a very large spec. It supports everything from pure VGA over it's analog pins as well as full fledged HDMI (its actually the other way around, HDMI is secretly just DVI). Finding monitors which support all of the simpler modes is an issue, whereas finding monitors which support old school VGA is fairly easy.
- garaetjjte 6y ago
  >its actually the other way around, HDMI is secretly just DVI HDMI signalling is actually extension of DVI, it embeds TERC4 data islands containing extra metadata and PCM audio during blanking interval. (yes, I was surprised at beginning but HDMI/DVI also have blanking periods just as VGA) https://warmcat.com/hardware%20design/hdmi/fpga/2015/10/21/hdmi-capture-and-analysis-fpga-project-2.html https://warmcat.com/hardware%20design/hdmi/fpga/2015/10/21/h...
  - deelowe 6y ago
    Thank you! I've been looking for something like this for ages. It's extremely difficult to find decent resources on the hdmi/dvi protocol.
    - garaetjjte 6y ago
      hamsterworks VHDL implementation might be also useful: https://web.archive.org/web/20190520020308/http://hamsterworks.co.nz/mediawiki/index.php/Minimal_DVI-D https://web.archive.org/web/20190520020308/http://hamsterwor... https://web.archive.org/web/20190520020602/http://hamsterworks.co.nz/mediawiki/index.php/Minimal_HDMI https://web.archive.org/web/20190520020602/http://hamsterwor...
    - Koshkin 6y ago
      Wikipedia has a link to this: https://web.archive.org/web/20120813201146/http://www.ddwg.org/lib/dvi_10.pdf https://web.archive.org/web/20120813201146/http://www.ddwg.o...
  - londons_explore 6y ago
    It's a "barely digital" standard. It doesn't have any error detection or correction. The timing of the signal is still based on CRT TV's. Really the whole lot should be done away with and replaced with something properly bidirectional, and preferably IP based so it can be routed anywhere.
    - garaetjjte 6y ago
      I think DisplayPort done away with this legacy and uses packetized transmission.
      - rasz 6y ago
        Packets that still have to encode and adhere to strict VGA timings (Hsync/Vsync/blanking), and you arent allowed to send anything useful between the packets unless its a blanking period.
garaetjjte 6y ago
Interesting idea. Basic DVI is somewhat VGA with analog signal replaced with TDMS. I think if you limit yourself to only few predefined colors with 8b10b encoding hardwired in shift registers, it's doable. (for signal integrity you can only pick colors that have balanced encoding) edit: as pointed in other comment, lowest bit clock is 250MHz, which might be a problem, it seems fastest discrete logic chips are topping out at ~150MHz
formerly_proven 6y ago
Technically less different than you might think, but it is much higher speed due to being bit-serial. The lowest pixel clock that must be supported by all devices is around 25 MHz (for VGA), which results in a bit rate of 250 MHz (8 payload bits per pixel per TMDS pair, encoded as 10 bits on the wire).
duskwuff 6y ago
The TMDS signals are a little too fast to implement in breadboarded logic, but DVI/HDMI are pretty easy to implement on an FPGA, especially if you restrict the colors used.
rasz 6y ago
DVI just encodes VGA signal in digital form :( Same for HDMI. Both are still sending pixels at VGA timings, Hsync/Vsync/blanking and all, with clocking locked to PixelClock. DisplayPort is packetized, but not in a 100% sane way. You would expect that clean slate purely digital interface designers would at least optionally allow sending whole screen update at a time. Alas you are still sending same VGA formatted pixel stream (Hsync/Vsync/blanking), just chopped into TUs (32-64 symbol Transfer Units) with stuffing (aka never used garbage) between them, even when connected to eDP display supporting Panel Self-Refresh (own frame buffer inside display).
- phire 6y ago
  Sending the whole screen update at once is less than optimal, as it pushes bandwidth requirements through the roof. Better to stretch the transfer out over the entire frame to lower bandwidth requirements as much as possible. The timings aren't 100% vga anymore. DVI and HDMI support reduced blanking mode, which shortens vblank to lower the wasted time lower the dotclock requirements for a given resolution. Also, lcd panels are still scanned out pixel by pixel, line by line. There is no reason to put a much wider interface between the panel and the LCD controller.
  - rasz 6y ago
    How would it change BW requirements when 1 you are sending same data but without the stuffing garbage in between, and 2 DP link is already above the Pixelclock speed. If anything you could put link to sleep more often instead of sending garbage.

jshap70 6y ago

DVI is a very large spec. It supports everything from pure VGA over it's analog pins as well as full fledged HDMI (its actually the other way around, HDMI is secretly just DVI). Finding monitors which support all of the simpler modes is an issue, whereas finding monitors which support old school VGA is fairly easy.

garaetjjte 6y ago
>its actually the other way around, HDMI is secretly just DVI HDMI signalling is actually extension of DVI, it embeds TERC4 data islands containing extra metadata and PCM audio during blanking interval. (yes, I was surprised at beginning but HDMI/DVI also have blanking periods just as VGA) https://warmcat.com/hardware%20design/hdmi/fpga/2015/10/21/hdmi-capture-and-analysis-fpga-project-2.html https://warmcat.com/hardware%20design/hdmi/fpga/2015/10/21/h...
- deelowe 6y ago
  Thank you! I've been looking for something like this for ages. It's extremely difficult to find decent resources on the hdmi/dvi protocol.
  - garaetjjte 6y ago
    hamsterworks VHDL implementation might be also useful: https://web.archive.org/web/20190520020308/http://hamsterworks.co.nz/mediawiki/index.php/Minimal_DVI-D https://web.archive.org/web/20190520020308/http://hamsterwor... https://web.archive.org/web/20190520020602/http://hamsterworks.co.nz/mediawiki/index.php/Minimal_HDMI https://web.archive.org/web/20190520020602/http://hamsterwor...
  - Koshkin 6y ago
    Wikipedia has a link to this: https://web.archive.org/web/20120813201146/http://www.ddwg.org/lib/dvi_10.pdf https://web.archive.org/web/20120813201146/http://www.ddwg.o...
- londons_explore 6y ago
  It's a "barely digital" standard. It doesn't have any error detection or correction. The timing of the signal is still based on CRT TV's. Really the whole lot should be done away with and replaced with something properly bidirectional, and preferably IP based so it can be routed anywhere.
  - garaetjjte 6y ago
    I think DisplayPort done away with this legacy and uses packetized transmission.
    - rasz 6y ago
      Packets that still have to encode and adhere to strict VGA timings (Hsync/Vsync/blanking), and you arent allowed to send anything useful between the packets unless its a blanking period.

garaetjjte 6y ago

Interesting idea. Basic DVI is somewhat VGA with analog signal replaced with TDMS. I think if you limit yourself to only few predefined colors with 8b10b encoding hardwired in shift registers, it's doable. (for signal integrity you can only pick colors that have balanced encoding) edit: as pointed in other comment, lowest bit clock is 250MHz, which might be a problem, it seems fastest discrete logic chips are topping out at ~150MHz

formerly_proven 6y ago

Technically less different than you might think, but it is much higher speed due to being bit-serial. The lowest pixel clock that must be supported by all devices is around 25 MHz (for VGA), which results in a bit rate of 250 MHz (8 payload bits per pixel per TMDS pair, encoded as 10 bits on the wire).

duskwuff 6y ago

The TMDS signals are a little too fast to implement in breadboarded logic, but DVI/HDMI are pretty easy to implement on an FPGA, especially if you restrict the colors used.

rasz 6y ago

DVI just encodes VGA signal in digital form :( Same for HDMI. Both are still sending pixels at VGA timings, Hsync/Vsync/blanking and all, with clocking locked to PixelClock. DisplayPort is packetized, but not in a 100% sane way. You would expect that clean slate purely digital interface designers would at least optionally allow sending whole screen update at a time. Alas you are still sending same VGA formatted pixel stream (Hsync/Vsync/blanking), just chopped into TUs (32-64 symbol Transfer Units) with stuffing (aka never used garbage) between them, even when connected to eDP display supporting Panel Self-Refresh (own frame buffer inside display).

phire 6y ago
Sending the whole screen update at once is less than optimal, as it pushes bandwidth requirements through the roof. Better to stretch the transfer out over the entire frame to lower bandwidth requirements as much as possible. The timings aren't 100% vga anymore. DVI and HDMI support reduced blanking mode, which shortens vblank to lower the wasted time lower the dotclock requirements for a given resolution. Also, lcd panels are still scanned out pixel by pixel, line by line. There is no reason to put a much wider interface between the panel and the LCD controller.
- rasz 6y ago
  How would it change BW requirements when 1 you are sending same data but without the stuffing garbage in between, and 2 DP link is already above the Pixelclock speed. If anything you could put link to sleep more often instead of sending garbage.