Hacker News new | ask | show | jobs
by anyfoo 1842 days ago
This is pretty cool.

For about two to three years now, I've leaned very heavily into analog video signals as a hobby. It culminated into me making not just a software PAL decoder, but my own fully compliant PAL "graphics card" with an FPGA and analog circuitry. PAL might be one of the most complicated analog video signals next to SECAM (though PAL is not that far from NTSC if you understand it well already), and I wanted to really understand every step in it, including all of the math.

I of course test everything with the once ubiquitous[1] PM5544 test pattern, which is described in noticeable detail here in case you were every wondering why it looks the way it does: https://web.archive.org/web/20190907170308/http://www.radios...

It's satisfying to really understand analog TV now. I watched a lot of TV through my life, and always had the thought that while I use it so much, I had no good idea how the TV in front of me actually worked. It's also a bit bittersweet, because while generating NTSC or PAL is still useful in existing composite video situations (the motivator for the PAL graphics card was another project where I needed composite output), there are almost no broadcasts left, and it seems rather outdated in general.

One day I might make a website that explains how NTSC and PAL work in detailed but understandable way, but I keep putting it off indefinitely.

[1] If you are from Europe or other PAL countries. In the US, I think simple SMTPE color bars were more common, and a lot of the elements in the PM5544 test card don't matter for NTSC.

2 comments

Kindred souls. About three years ago, I did the same, but with NTSC. In my case I actually built a digitization board that sampled the signal from a composite cable and dumped the raw samples over USB using the Cypress EZ-USB2 chip. I didn't want to "cheat" with a chip that did the synchronization etc. :)

I never really finished it, but I threw a little bit of it on GitHub: https://github.com/gabesk/tv_python is the prototyping version (the raw data is a picture of Lena on a Raspberry Pi composite output).

Also as an aside, if anyone ever wants an example of how to stream data from an isochronous endpoint on Windows, this took me way to long to figure out: https://github.com/gabesk/tv/blob/master/actual_implementati... (see usb_reading_thread routine) as well as this blog post: https://gabesk.blogspot.com/2018/08/streaming-from-isochrono... (that version does real-time black and white, but I never finished real-time color as my laptop at the time couldn't handle it with my poorly optimized decoding routines).

You all have inspired me to finish this properly and publish it. Maybe even as a top level post on HN.

Nice. I do know the feeling of "not wanting to cheat" by using existing solutions, where's the fun in that...

My PAL decoder is in Matlab, and so slow that it's mostly useless (because not realtime), but convenient for trying things out with the data, since you're already in Matlab... but the real goal was the eventually reached PAL generator anyway. That even found a practical use as well.

I think you should publish!

By the way, if you ever feel the itch to go back to it, try adding PAL support. It's NTSC with a few fun twists, nothing mind-bending though. The most "advanced" part of it is the delay line (which in practice will just be a line of memory).

> One day I might make a website that explains how NTSC and PAL work in detailed but understandable way, but I keep putting it off indefinitely.

I've been meaning to do the same thing.

I had to learn a lot about NTSC/PAL just so I could calculate the correct aspect ratios for GameCube/Wii games in Dolphin Emulator.

It was a little annoying because none of the standards actually seemed to define which part of the signal had a 4:3 aspect ratio.

I actually implemented a small idealized emulation of the flyback transformers so I could still produce results if a game (or more likely homebrew) was to reconfigure VI for a non-standard timings with non number of vertical lines.

Though you probably know more about color encoding than me.

The main thing I really want to explain to people is how the 240p signal that older consoles output work when the TV is "expecting" an interlaced signal.