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?
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).
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.
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.
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).
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.
>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)
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.
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.
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
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.
