Component Video For The Commodore 64

Of all the retro systems, the Commodore 64 had the best video system. The VIC-II chip in the C64 was the best example of why Commodore was the best, but in terms of video output, the C64 was still a consumer device: the only output was S-video, or composite video, or something like it. The professional stuff uses YPbPr, an RGB video signal that separates the red, green, and blue colors. On a modern LCD, the difference between composite and YPbPr is noticeable, and if you’re going to run your C64 on the big screen, it would be very helpful to use a professional video standard.

In an effort to bring the C64 into the future, [c0pperdragon] created an FPGA-based modification for the VIC-II chip. The end result is getting YPbPr signals directly from the computer, and outputting it to a TV in glorious 480p.

Inside the Commodore 64, the VIC-II creates the chrominance signal in a way that is impossible to convert it back to any form of RGB. The solution to get RGB out of this information is to listen in to 22 pins of the VIC-II to determine what signals it intends to generate. This is done with a smallish Altera FPGA connected to the VIC-II through a ribbon cable. On the FPGA, the luminescence and all the color information is generated, then converted into true YPbPr. For the complete mod, the RF modulator is removed, and the original A/V jack is still functional. This is effectively a very in-depth mod that rids the C64 of the TV connector and channel selector (that no one uses anymore) and replaces it with a professional-grade video output.

When it comes to C64 mods, we thought we’ve seen it all. We’ve seen C64s resurrected from the dead, and we’ve seen drop-in replacements for the SID that still don’t have working filters oh my god. This is on another level. This is using FPGAs to drag the C64 into the modern era, and if you don’t care about the rusting RF box, it’s a reversible mod.

31 thoughts on “Component Video For The Commodore 64

    1. Yeah, at least some information on how the colour data is reconstructed would be nice. From the description, it could be doing anything from emulating a VIC-II, through to guided sampling the video signal and regenerating from a digitised model. Without some meat on the bones, this can hardly be called cool.

      1. I pleaded guilty, full source code is indeed available (see links in comments below) and to make it up for it, I will try to answer those points and summarize my own observations for the interested readers :

        As expected for this kind of modern replacement of such a video chip, while it obviously implements the digital logic for graphic modes decoding (in VIC2Emulation.vhd), each analog component channel is generated with “a simple 5-bit DAC (5 bit plus sync in case of the Y signal made from resistors and that feed into a video amplifier to drive the outgoing line” (as stated in doc/videotimings.txt), and those DACs are fed by the FPGA with a precomputed YPbPr palette (in C64mod.vhd) which is rougly based on the results of color calculations that are used by most C64 emulators, and coming from this well-known reverse-engineering work presented in 2001 : https://www.pepto.de/projects/colorvic/2001/

        But digging more, back in time, into the repository, at one point in this project there was a “C64 to YPbPr converter” (requiring an add-on board for the “A-VideoBoard” discussed here, and equipped with two ADCs for sampling the chroma and luma outputs from the orignal VIC-II chip) only aimed at transcoding the original C64 video signal towards the same YPbPr outputs, with the FPGA digitally demodulating the analog video source into parameters directly used for calculation of the corresponding YPbPr values sent to the DACs. See c64converter.vhd in : https://github.com/c0pperdragon/A-VideoBoard/tree/1932e609f702feaafc21ff590347ef4cdd332955/c64converter

        In that light, the linked description on GitHub gives, right in its introduction, the reasons why the latter method was abandonned in favor of the former, which is then (unlike in the report) clearly described.

    2. I’d imagine, that if it was open source, the man would get a lot of questions and suggestions, special requests. Sounds like he plans on selling them, and not expecting to make a profit, just keep the hassles to a minimum, got to pay, to play, on his time.

      I don’t know why I keep reading these C64 stories, all my Commodore stuff has been in a box for a couple of decades. I first saved them with thoughts of using them for robot brains, but microcontrollers got interesting, and a better choice. As far as computing, most hook directly to the big TV, if you wish, and you can download a C64 emulator. They were great at the time, but not sure of the value of digging them out, and investing much time or money with them.

      1. Please spare us the liberalistic clichés and innuendo, I just pointed out the kind of funny incongruity of a project sharing no code, published on the most famous OSS platform (of course, its author graciously shared some files there, like its presentation, schematic and gerber files), it has nothing to do with his choices, or your assumption of these.
        But as you just gave your point of view, mine is that if it was open source, those who care would have a chance to look at the implementation. In this regard, it’s more a matter of content choice and preference, still many people come to read this blog not just to learn that something cool was done, but expecting to learn “how” it was actually done.

    1. There seems to be Ypbpr to hdmi converters for sale so it shouldn’t be a problem, but haven’t tried myself. Oh btw Ypbpr isn’t rgb, it’s luminance + sync (Y) and two signals that describe the difference between luminance and the color (pb and pr).

      1. Way ahead is a bit of a stretch, but it had the best video capabilities at the times (1985). 32 color from a 4096 palette when other 8-bit or 16-bit computers where limited to 16 simultaneous colors. But where the Amiga 1000 shined is in the overall hardware architecture that used several specific chips (Agnus, Denise, Paula) that were very well integrated together. Also it had genlocking capabilities which explains why it was also used for video.

        Still, the Commodore 64 also had probably the best video capabilities at the times (1982). 320×200 in 16 colors with 16 hardware sprites per scanline and hardware scrolling.

  1. So is this technically emulating the VICII chip for the purpose of outputting via rgb? we can already emulate it via code, how hard would it to upconvert it to a fpga (he says staring at his unused fpga on his desk). open up the brains of the VICII by piggy back it’s signals with your own emulated chip to do conversion of signals, maybe even add hdmi and upscaling, filtering etc. I think there was a gameboy fpga mod that did the same trick.

    1. It’s not about how hard things are. It’s about actually doing something. There are a lot of people saying many things are possible, but that’s not really worth anything untill somebody really does it.

      1. I didnt mean to ‘demean the effort, workmanship, ingenuity involved as i did note my efforts are collecting dust somewhere on my nightmare of a desk. I was more thinking out aloud & asking a question, maybe i should have added punctuation and such. No edit Button :-( .The reason I have a FPGA on my table was I wanted to see if I could add a graphics card to a C64, This proves the theory works, I pulled the gerber files as this saves me that madness which would remove the fun part for me. never did enjoy rats nests designs at college , anywahoo i digress, adding spi stream to esp for streaming C64 or is that stretching the goal posts a little too far ? Also after watching this video https://www.youtube.com/watch?v=5UX-gqylYgQ , It again got me thinking could you build a “updated C64” , like amiga had graphics upgrades, C64 needs one for the 2019’s . Something like the sam coupé was ment to be for the speccy world.

    1. Sorry, the palette is currently hardcoded in the FPGA firmware. I chose a palette that I liked most and that also would make some sense for PAL and NTSC users. As the firmware already totally reached the capacity limit of this FPGA, there is not much I can add to it.

  2. In theory, S-Video is separable back into RGB or Y/Pb/Pr, which is why it is so superior to composite video. But the source here says that that is not quite the case for the Commodore 64.

    1. C64s in France were often upgraded with a “Procep PAL-RVB” based on a TDA3510 PAL decoder IC. It was the easiest way to have color from a PAL-C64 on a SECAM-TV. (almost all TVs in Europe had RGB inputs on a SCART/Peritel connector).

    2. Decomposing the chroma signal into proper RGB is not really possible on the C64. Mainly because the color can switch back and forth pretty fast compared to the color subcarrier frequency. So having single pixels of some color does not leave the ensuing chrominace signal enough time to settle down on the proper frequency shift to be reliably converted back. Also the output of the VIC is pretty noisy on both the luma and chroma lines, so there would be some noise in the output anyway.
      I tried very hard to quantify the Y/C signal back into the 16 colors of the C64, but there are always some miss-detections somewhere and the picture has flickering pixels all over the place.

  3. The version of the TI-99/4A sold in PAL countries output component video, but most people used the included RF modulator to connect to a TV because monitors or TVs with component input were rare and expensive in the early 80’s.

    TI didn’t even bother making a component NTSC version of the VDP, which would have been the 9928A where the PAL version was the 9929A. A composite 9919A existed but was never used in a TI computer.

    If you want a vintage microcomputer hack, look up what people had to do to adapt PAL TI-99/4A component to a SECAM TV or monitor.

  4. This is nothing new – this mod works very much in the same way the Chameleon (http://wiki.icomp.de/wiki/Chameleon) does, except Chameleon outputs VGA (ie actual RGB) and doesnt require to open the C64 (it uses the signals available at the expansion port instead). Both have to emulate (at least partially) the VICII – which this new mod still has to prove how good it really is, and if it can keep up with all the quirks that are used all over the place.

    1. Sorry but this is not a products review site, nor the buyer’s feedback section of your favorite retrocomputing webshop.
      But what is already totally new and remarkable compared to your $200 product is that everything neeeded to build this one yourself is provided, including an open source firmware, so this is the kind of real DIY stuff that new hackers love to learn from. Because another great thing (thanks to the author’s generosity and cleverness) is that anyone can really understand how it is done by reading the enlightning technical documentation, and if need be, looking at the code, all directly viewable on the web repository.

      Obvisously, this means more for people looking to understand how it was implemented exactly, than for happy ignorant customers usually undermining such sharing of knowledge in the community with their “shut up and take my money” philosophy…

    1. Sorry for the late reply.
      576p is supported out of the box. The mod determines if it is running in a PAL or NTSC machine and adjusts itself accordingly. Using the slider switch at the back of the machine you can select 288p or 576p, with or without scanline effect.
      But I did not manage to support the very old NTSC VIC chips, as I could not distinguish them from the newer ones, as
      both have the same pixel frequency. Also I did not have such a device to develop the firmware with (and I feel, such early devices should not be modded anyway but preserved in their original state).

Leave a Reply

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