Hackaday.io: https://hackaday.io/project/190161-rp...
Github: https://github.com/TEC-IST/rp2040-hdm...

Microcontrollers have begun to rival early PCs and retro gaming consoles in measures like speed and memory capacity, and even leapfrog them with new capabilities like multiple cores and wireless connectivity. One area that still seems a bit lacking is video output. Sure, the ability to connect a smallish LCD via i2c or SPI is normal, but can these little marvels do more? With a little spicier circuit, I think so...

And, in fact, we know so: Wren6991 successfully bitbanged DVI on the RP2040 [ https://github.com/Wren6991/PicoDVI ] and validated the output up to 372Mbps (good enough for HD 720 @ 30Hz). That leaves some resolution milestones unxplored, for example FHD 1920 x 1080 @ 60Hz (1080p) x 24 bit color depth (i.e. 8 bits for each of the red, green, and blue subpixels, aka RGB888) = 2.985984Gbits/second not including control signals and blanking overhead -- approaching an order of magnitude larger. Back to Wren6991: the CPU cycles for QVGA (320 x 240) consume 60% of one of the RP2040's two M0+ cores, i.e. around 30% of its total processing power, so that means there's only headroom to about triple the processing rate. Maybe with a very aggressive overclock it could get in the ballpark, but it seemed like, considering we have up to 30 GPIO pins to play with and DVI's Transition Minimized Differential Signalling (TMDS) encoding uses only 6 pins, there had to be a way of using the 32-bit width to help escape the bottleneck. The RP2040's M0+ cores can execute 1 32-bit move instruction in 1 clock cycle, which means that if all 30 GPIO pins were tasked with sending this output, the theoretical maximum output from an ideal 1 core x 1 ipc code x 30 pins x 133Mhz 'normal' clock speed is around 3.99Gbits/second, although GPIOs are needed for other functions and some processing is necessary to work out what to send (and note that only 26 GPIO pins are exposed in the RPi Pico). I considered an overclock and a Ghz-speed capable shift register, specifically the very interesting MC100EP142FA. I considered a reduced color bit depth, like RGB565 or RGB666. Ultimately, it sememed like an RGB to HDMI encoder would be the best idea to offload the encoding functions, and one can be had cheaper than the ultra-fast shift registers.

Another problem: with only 260KB of RAM onboard, how would the RP2040 store even a single frame that is 1920 x 1080 x 24 bits/pixel = 49,766,400 bits / 8 bits/byte = 6.220800 MB? Display protocols require the frame transmitted many times per second. Clearly the RP2040 needs another ic in the mix: external RAM = 49.7664Mbits+. With this, the RP2040 could store the entire desired output for the current frame at all times, which frees the RP2040 from 'forgetting' and redrawing sections of each frame, i.e. it only has to deal with pixels that need to be updated and it can write those updates into memory over time, sending the current state of the frame in memory each time the video protocol needs a frame. The best part about an independent memory chip is that the RP2040 doesn't necessarily need the data returned to it (supposing the use case doesn't require acting upon the existing frame, but simply overwriting it). The RP2040 only needs to send the RAM the address of the next batch of pixels, which the RAM can then make available to the HDMI encoder/transmitter between their respective outputs and inputs.

...
[ text clipped -- see the full text via Hackaday.io or Github links above ]
...

So what does everyone think?

Maybe something like this would be of interest to retro gamers wanting to plug their RP2040-based emulator into a TV/monitor. Maybe piping a terminal to modern displays via hardware? As mentioned, PyDOS is interesting. Thinking about a GUI, the most feature complete one for microcontrollers I see out there is FabGL [ https://github.com/fdivitto/FabGL ] for the ESP32 with no clear option for the RP2040. If you're after 1024 x 768 @ 60 FPS or smaller, 'going bigger' with an Allwinner V3S has RAM in the SIP and outputs RGB888. For digital signage, a low end orange/banana/mango {insert tropical fruit here}/Rock pi/RADXA zero variant would be about the same price and validated. Sometimes it's just fun to explore the limits. I'm putting the board schematics and PCB files out there. If you do use these, please double-check EVERYTHING, as I have not had these built/tested!
---
Become a Channel Member:    / @tecist  
Patreon:   / tec_ist  
BTC: 3PVeqcvKoQqKRgGDhHvZJ49AumUhnVSqC9
ETH: 0xe74a8e8e76380d3E2048e25Bd927b7880E608Ac8

https://tec.ist
  / tec_ist  
   / tec_ist