Going through VGA would be a bit weird as it’s an analog signal; doable, but worth the hassle? (Compsite / CVBS is even worse as it contains modulated signals).
(In 8-color mode, VGA can probably be thought of as digital, but then, the same can be achieved with a parallel-to-HDMI converter (like the linked one) by soldering all pins to a single rail.)
All bit-banging etc is nice and good fun, but ultimately limits what the device can do (or asks the programmer to be very smart, and while it’s good to have tools for smart people, I’m more interested in software that’s maintainable, and as a rule of thumb you gotta be twice as smart to maintain as you were when you wrote, so don’t write on a smart streak ).
Without live generation, parallel output (or DAC to VGA or GPIO via DMA if that works / maybe through SPI peripheral?) necessitates an uncompressed video buffer; 640x480 in non-paletted RGB is about 1MB; we have few devices with even that much, let alone space left for the application. (Black-and-white single-bit would be 38k, that’s somewhat managable).
So, do we have alternatives?
- Live generation per row: That’d be a high-priority interrupt, can we afford that when we also do 6LoWPAN on the same system? (Whatever runs in that interrupt would define our graphics engine; does it do color palettes? sprites? revive the ghost of long gone generations of consoles?).
- External video memory? A classic; I don’t know a chip off my head. (IIUC these work by exposing a parallel writable memory extension, and allow you to clock out data as configured through a double buffer).
- It’s HDMI, and we’re a long way from cathode ray tubes any more. We shouldn’t really have to send the image 60 times per second any more, and the outputs have video buffers anyway.
- Unfortunately, depending on “ignore MSA” / “adaptive sync” makes the range of usable devices limited; plus the easy options to generate HDMI are unlikely to support it.
- Still probably requires the display to be updated in full.