Hackaday Prize Entry: An Open Source Graphics Card

For last year’s Hackaday Prize, [PK] tried to build a video card for microcontrollers and headless Linux systems. It was only 640×480 resolution VGA, but the entire project was designed around a CPLD communicating with a microcontroller over SPI. This prize entry was, by [PK]’s own admission, a failure. It was late, but now he’s had an entire year to perfect his design. That means he can enter version two of his VGATonic in The Hackaday Prize.

The VGATonic version 2 uses a Xilinx XC95144XL CPLD for the VGA timing, and an ATTiny 2313a to read the SPI bus. Video memory is four megabits of static RAM. That’ls pretty much all you need for the most basic VGA graphics card, and all of this is packed onto a 3×3 inch PCB.

You can do a lot with 640×480 8-bit graphics running at 25FPS. In the video below, [PK] has a ‘hello world’ of sorts, Doom, running on a Raspberry Pi 2 with his SPI graphics card. Yes, it’s a graphics card for the Raspberry Pi, and it looks really good.

Further refinements of the design will include some primitive graphics routines. Not OpenGL or anything fancy, just something to reduce the number of writes on the SPI bus. It’s a great project, and perfect if you want to add video out to an Intel Galileo or other microcontroller project. [PK] has a video demo, you can check that out below.


The 2015 Hackaday Prize is sponsored by:

22 thoughts on “Hackaday Prize Entry: An Open Source Graphics Card

      1. Sorry, temporary brain fart as a result of trying to do that same thing with the Papilio Pro’s SDRAM. That does, however, my question.

        This is why HAD needs a delete button as well :)

  1. Great to see this project.

    Is there space left in the CPLD to implement a seamless switchover between serial terminal, and gfx card mode or even an overlay of the terminal chars over the gfx?

    1. With the demo you’re seeing, the ATTiny is underused – all it’s doing is bitbanging SPI to the programmable oscillator to get us 2xthe VGA pixel clock. All of the SPI code is directly on the CPLD.

      I put serial mode (and of course, terminal emulation) as a stretch goal for this year because I am running short on macrocells, but I might be able to employ some tricks on the uC side to get some of them working.

  2. With 4Mbits of SRAM you could in theory increase the resolution to 800x600x8bits. Other than that I’m surprised that you can push data fast enough over SPI to manage 25 frames/second, I make that to be about 60Mbits/sec.

    1. I “Believe” because it’s not pushing video, it’s pushing sprites and manipulating them. It’s pushing instructions, that are then rendered by the card.

      Sorta the difference between trying to reproduce a Monet, and sending a black-and-white line drawing of a Monet with “paint-by-numbers”

      4Mbits would then be for the sprites and frame buffer

      P.S. is the Vsync issue the CCD on the camera or an issue with the video card

      1. No, there isn’t any room for sprites or much of any instructions with my implementation – I’ve only got 144 macrocells to mess with on the CPLD. It’s just saturating SPI, and every time I reset the chip select there is some logic on the CPLD to reset the memory writes to 0,0.

        So it’s painting the Monet a pixel at a time, in this case.

Leave a 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.