RP2040 a good candidate for cheaper version?

[raszpl]

https://github.com/Wren6991/picodvi 480p60 and 720p30 possible with ~half the resources utilized, additionally deterministic PIO state machines mean there is no longer any need for CPLD.

[IanSB]

I have already looked at that project and it is interesting as it may well be possible to implement a cut down version of RGBtoHDMI on it. However one of the main attractions of RGBtoHDMI is the integer scaling which requires a high resolution output matching the LCD's native resolution and the Pico can only support 640x480@60Hz so would have to rely on interpolated scaling in the monitor. Also 50Hz computers might be a problem as 640x480@50Hz is usually too low for most monitors to lock to so the next highest resolution would have to be used which is 720x576@50Hz and that has a higher pixel clock (27Mhz vs 25Mhz) so that might not work either.

[hoglet67]

The other issue is memory: the PICO only has 256KB (ish) of RAM and a 640x480 8-bit frame buffer needs 300KB.

The PICO DVI project supports 720p, but only has a QVGA (320x240) frame buffer.

So you would have to either reduce the bit depth stored, or dispense with the frame buffer and "chase the beam", which is only possible in certain circumstances.

It's a lot of work for something that's ultimately much more limited than the current platform.

[bzuidgeest]

What you are talking about is already being done https://sites.google.com/view/lorentek-rgb2hdmi/home It has its limitations but it works and is indeed based on work from wren6991. The firmware is not open-source yet, but the author recently mailed me he plans to open it up around august after presenting it on some convention

Its highest output mode is about 720p and it does not need a cpld. It uses a normal ADC.

[IanSB]

@bzuidgeest

It has its limitations but it works and is indeed based on work from wren6991.

Thanks for the link. Looking at the specifications on the site it does seem to have the sort of limitations we pointed out above (i.e. not enough memory for a full size frame buffer, limited HDMI resolutions so not much scope for integer scaling etc) but it is an interesting project and maybe I will contribute if it is open sourced. It also appears to use a fixed frequency HDMI output (60Hz) which likely means no genlocking so any video is going to have judder (frame drops or repeats) and tears on any motion especially from 50Hz sources. Genlocking the Pico is very difficult because the Pico's internal phase locked loops have very coarse adjustment so you can't make the small frequency adjustments necessary to accurately track the incoming video signal. (That might also makes sampling digital video like CGA directly by the Pico without any external hardware equally difficult as the sampling PLL might not be able to be adjusted with enough precision)

[bzuidgeest]

@IanSB Personally I was looking at it because of the fact that giving some of the more vintage consoles like the videopac/odysee2 en the pong stuff a full pi to digitize the video to display on a HDMI only TV is a little insane. Something cost effective like the pico feels more acceptable to me. Upscaling to 4K makes no sense in those cases. Just getting a progressive signal would be enough for me. Cerntainly for the two times I feel nostalgic. (I could use a single rgbtohdmi and analogue swithers, but that also feels clunky)

The videopac is ttl-rgb i believe. So I hoped I could strip out everything but the conversion and get a real small dedicated solution, that is easy to reproduce by getting a rp2040 base board and programming it. No fpga's, no cpld's, no dacs. I don't care in that case if timing is a little wonky, the RF signal is worse.

p.s. I also noticed that is seems difficult to find very small fpga's that can do Full HD HDMI, with a low pin count that is easy to solder.

[raszpl]

Genlocking the Pico is very difficult because the Pico's internal phase locked loops have very coarse adjustment

Would massively oversampling help? PIO/Pico wont have problem sampling at 160MHz and figuring out phase in software.

Another option mighty be reusing whatever is generating video clock in the computer to directly clock RP2040 (max clock input 50MHz).

How capturing video was done back in the day: 1995 Snappy Video Snapshot, afaik designed by one of NewTek engineers (Video Toaster) after Paul Montgomery left and founded Play inc (https://en.wikipedia.org/wiki/Paul_Montgomery#Play_Inc.)

https://www.youtube.com/watch?v=CwzDjR-Vcyw https://mobile.twitter.com/TubeTimeUS/status/1301991371947925504 reverse engineered diagram https://mobile.twitter.com/TubeTimeUS/status/1302704667143544833

Amiga flickerfixers also used field memories https://gitlab.com/MHeinrichs/multifix-aga

[IanSB]

@raszpl

Would massively oversampling help? PIO/Pico wont have problem sampling at 160MHz and figuring out phase in software.

The current Pi zero also does massive oversampling in order to find the centre of each pixel but it still requires an accurate lock. Using a non synchronous oversampling clock probably even higher than 160Mhz might work but the phase is going to vary across each line and be different on every line so keeping track of the fractional variations might be difficult.

Another option mighty be reusing whatever is generating video clock in the computer to directly clock RP2040 (max clock input 50MHz).

That would likely work for systems where signals have to be picked up internally anyway but not much use as a general solution.

How capturing video was done back in the day: 1995 Snappy Video Snapshot, afaik designed by one of NewTek engineers (Video Toaster) after Paul Montgomery left and founded Play inc (https://en.wikipedia.org/wiki/Paul_Montgomery#Play_Inc.)

I designed a slow scan video digitiser something like that back in 1983 for the BBC micro, see here: https://www.beebmaster.co.uk/CheeseWedges/VideoDig.html

... and used it to make this demo back in 1984: https://www.youtube.com/watch?v=5fDHjmke2sU

(Not my web page or youtube upload - looks like the flag one got corrupted)

I will probably have another play with the Pico after finishing the current RGBtoHDMI development cycle (mainly improved CGA artifact decoding on the Pi zero which only works on multicore Pi models like the zero 2W at the moment)

[raszpl]

How about clocking rp2040 with Si5351A? $2 in small quantities, $5 whole dev board. Available for cheap manufacturing at jlcpcb https://jlcpcb.com/parts/componentSearch?searchTxt=SI5351A same as $1 rp2040.

[raszpl]

"working" example https://blog.qiqitori.com/2022/09/raspberry-pi-pico-15-6-khz-analog-rgb-to-vga-adapter-part-1-poc-wip/