Generating PAL Video With A Heavily Overclocked Pi Pico

Barely a week goes by without another hack blessing the RP2040 with a further interfacing superpower. This time it’s the turn of the humble PAL standard composite video interface. As many of us of at least a certain vintage will be familiar with, the Phase Alternate Line (PAL to friends) standard was used mainly in Europe (not France, they used SECAM like Russia, China, and co) and Australasia, and is a little different from the much earlier NTSC standard those in the US may fondly recollect. Anyway, [Fred] stresses that this hack isn’t for the faint-hearted, as the RP2040 needs one heck of an overclock (up to 312 MHz, some 241% over stock) to be able to pull off the needed amount of processing grunt. This is much more than yet another PIO hack.

The dual cores of the RP2040 are really being pushed here. The software is split into high and low-level functions, with the first core running rendering the various still images and video demos into a framebuffer. The second core runs in parallel and deals with all the nitty-gritty of formatting the frame buffer into a PAL-encoded signal, which is then sucked out by the DMA and pushed to the outside world via the PIO. There may be a few opportunities for speeding the code up even more, but [Fred] has clearly already done a huge amount of work there, just to get it working at all. The PIO code itself is very simple but is instructive as a good example of how to use multiple chained DMA channels to push data through the PIO at the fastest possible rate.

Beyond the Pico PCB, the only extra hardware needed was a resistor-ladder DAC implemented on a solderless breadboard. [Fred] needed a couple of goes to get the correct DAC resistor values, the first version was built on a small prototyping PCB, but unfortunately, the peak voltage was only 1 V, so it was necessary to build a second version (hence the breadboard) to get it to the correct 1.25 V.

We’ve covered video hacks on diminutive hardware many a time, even going into some details of the various standards, like this piece on just why is NTSC so odd? But as time marches on, video standards have gone through vast changes to get to where we are now.

via Adafruit.

19 thoughts on “Generating PAL Video With A Heavily Overclocked Pi Pico

  1. PAL isn’t that different from NTSC, and indeed variations of PAL exist that have NTSC’s timing and colourburst frequency. The only real innovation of PAL was that the polarity of the colour signal flips every other line; while it eliminates the problem NTSC had with phase shifting causing chromatic shifts, it also halves the colour frequency.

    It also doesn’t need quite the resources used here to generate. Linus Åkesson got a PAL signal (…more or less) out of an ATmega88 clocked at 17.74MHz, with enough cycles left over to generate a soundtrack: https://www.linusakesson.net/scene/phasor/index.php

    1. Phasor requires an uncommon crystal, can only generate a small subset of the possible colours, and is not a general purpose engine (being an actual demo, all the effects are tuned to fit into the available resources.) It’s still awesome and I wish I still had the one I built years ago.

  2. with that speed it can do hdmi..
    composite pal **output** should be possible at 8mhz, running mostly on 1-3 of the PIO.
    I suspect like mpeg decoding, the pal **generation** uses most of its time color converting.

    have anyone ever tried to output composite pal video using pwm instead of a dac?

  3. France officially used SECAM, initially, but the reality is that most TV sets supported both standards and French people used PAL outputting computers all the time without problem. The Amiga for example outputs PAL and just ran fine on every French TV you could find at the time. That’s why most people will indicate that France used PAL/SECAM rather than just SECAM.

  4. Some thoughts on optimization:

    – Putting the speed-critical data structures such as pixel buffers & sample buffers in different SRAM blocks helps, because it reduces bus contention between the CPU cores and DMA.

    – This does full 24-bit YUV. If the U and V were reduced to 4-bit each (16-bit palette, consisting of 8 bit luminance + 8 bit color), a 256-entry lookup table could be used to get the combined sin/cos values, avoiding a lot of multiplications and additions.

    – For 8-bit palette (4-bit luminance, 2 bits for U / V), a lookup table could be used to directly drive the DAC using DMA.

  5. Even with the argument about color being harder, since color information has a lower bandwidth than the luma it seems more logical to just add an oscillator circuit externally for the color signal and modulate that with the Pico.
    Make me wonder if there aren’t ready-made chips for that, I mean there are decades of circuits and development behind the old TV standards and many chips were put on the market.
    Mind you, this is more about ‘see I did it!’ than any practical thing I imagine.

Leave a Reply to NickCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.