Exploring FPGA Graphics

I’ve done nand2tetris a couple times (taking good notes the second time) and coincidentally played through nandgame.com for the first time this weekend. I’ve been trying out what people have done with bare metal Forth on a raspberry pi using a frame buffer and using C libraries to get input from a USB keyboard. I don’t really like having such dependencies so I was just thinking I should get out my Arty FPGA with the same VGA module he uses and just make my own computer instead. It’s hard to find stuff that works how I want and is in stock and is actually understandable.

This is definitely going to be my next project. It even uses Arty and the VGA module for it which I already happen to have (it only has a few bits for R, G, and B color though so it’s not perfect for images and gradients). There was example code[1] to use with it and it generates an image but I wasn’t sure how to make a frame buffer for it which this tutorial has!

I recently reviewed graphics rendering techniques (Computer Graphics from Scratch from No Starch Press) so that fits too. This’ll be fun!

[1] https://digilent.com/reference/learn/programmable-logic/tuto...

(They have a different board with HDMI in and out and a framebuffer example to go with it: https://digilent.com/reference/learn/programmable-logic/tuto...

Also I just ran across someone who did HDMI output directly from the pins of yet another variety of Arty board https://domipheus.com/blog/hdmi-over-pmod-using-the-arty-spa...

On second thought, I’d rather stick with understandable VGA and hooking up a keyboard in a matrix… could use some other microcontroller and interface between the two with fewer pins, just not USB. Or PS/2 keyboard… Ben Eater has a tutorial as always)

Nice work :) I think implementing a VGA controller controller seems a lot nicer in Verilog/VHDL than on an MCU.

The Ti chip you're using for DVI looks interesting too, not heard of that before.

It looks like you're going to use the FPGAs BRAM for double buffering? I started implementing double buffering for led strips in VHDL, but need to get back to finishing the SPI controller for it.

Just here to say thanks for this, it looks awesome and is well in my reading list :)

Nice! How about a chapter on ray-tracing?

metagripe, the font you are using is too thin, top 10% of hard to read websites.

> "游ゴシック", YuGothic, "ヒラギノ角ゴ Pro", "Hiragino Kaku Gothic Pro", "メイリオ", Meiryo, sans-serif;

do you think with a customized analog board, CRT displays could have a function similar to G-Sync? what would be involved?

The big disadvantage of not having a real FPGA is that you won't be concious of the very real LUT/gate limits. A simulation will happily allow you to apply all sorts of nice compartmentalizations and abstractions, without making your understand that they will cost significant money if you tried to find an FPGA to fit them into.

This was my biggest shock when first working with FPGAs, while naively using a software mentality. Most everything had to be re-written once the simulations were done.

Have you writing an spec compatibile HDMI/DP controller in HDL? It's insanely complex.

VGA is a walk in the park that's sane and easy to understand for beginners. You just need to modulate the 3 primary colors between 0-255 for 8 bit color, and two clock signals, and the monitor will display a picture.

VGA is also very simple to debug since as long as there's some signal on the color and clock lines, the monitor will display something allowing you visually see what's wrong, while on digital, if some part of the handshake failed, you get no picture on the monitor so there's no way to figure out what's wrong without specialized knowledge and equipment.

A CRT is basically it's own oscilloscope of the signals on the VGA cable making development a joy.

The purpose of this site is to teach the fundamentals of creating graphics and having them show up on an external display. Driving a VGA signal is extremely straightforward compared to the complexity of HDMI. Generating an HDMI signal is arguably not the main goal of the site, so using VGA makes total sense imo.

I think from a hardware perspective this would be non-trivial, despite sounding like an obvious thing in principle.

In sending the entire frame with every refresh you get pixel addressing "for free", since you just send the data for each pixel sequentially in a predefined order. If you only wanted to update a single pixel, you would need to effectively send an instruction saying "set pixel x to rgb: a, b, c" or whatever, including both the pixel colour values and the pixel address. You'd also need some sort of edge detection for when a pixel is supposed to change which adds a delay.

This is fine for one pixel, but if every pixel on the screen changes at once then suddenly you are going to be sending a hell of a lot of instructions that not only contain the colour values as in the "old crt style" method, but also the address of every individual pixel too, which will then have to be decoded by the screen-side hardware.

All in all, you'll be using a lot more bandwidth and will need a much faster clock to do all of that in the same period of time. In the old school way, you just have a pixel clock that matches the pixel rate and some serdes for serialisation/deserialisation on each end which imo is considerably simpler.

VGA is incredibly easy to generate - you can do it via bitbanging (carefully turning on and off) GPIO pins on an Arduino [1], simply because the tolerances are insanely huge. A step above is SD-SDI [2], which uses less pins but has stricter requirements on timing, and equipment accepting SDI is usually only found in the professional-grade TV production space.

DVI, HDMI, DisplayPort or heaven forbid Thunderbolt are a hot mess - to generate a signal out of these without the usage of dedicated chips, you need a ton of logic and parts: output format negotiation, extremely strict timing requirements that completely rule out bitbanging, signal conditioning, specially shielded cables, shielded traces on the circuit board.

[1] https://hackaday.com/2014/06/10/640x480-vga-on-an-arduino/

[2] https://en.wikipedia.org/wiki/Serial_digital_interface

Because VGA is fundamentally an analogue standard built around how a CRT works. Each bit of the signal serves a very defined purpose based on how a CRT and thus a vacuum tube works. This is also why VGA is so crazy to do digital capture for, because there are a lot of things that are "VGA" that are well outside the IBM standard. Monitors don't often care because as long as they can adjust their pixel clock, something they can do based on detecting the blanking intervals, they can display the signal because CRTs don't fundamentally have a "resolution" they have "Dot pitch" which is different. But for a digital monitor like an LCD it has to detect and verify the stability of the signal, then try to decode it into something that makes sense. That can take multiple attempts to get right. Most hardware also makes assumptions based on the common resolutions because there is no resolution information... just blanking. So without EDID it can be a real challenge to deal with VGA capture. IIRC you can have multiple resolutions at approximately the same pixel clock because of how VGA works that's fine, a CRT doesn't care... but digital capture needs to know how many times per second to sample so it can make pixels.

https://en.wikipedia.org/wiki/Cathode-ray_tube#Construction_...

https://en.wikipedia.org/wiki/Video_Graphics_Array

https://en.wikipedia.org/wiki/Extended_Display_Identificatio...

> Why are we still generating video signals as if there is a CRT on the other end?

Because it's extremely simple electronically. It was designed to be simple to work with very slow electronic hardware made of discrete components. So it's basically child's play to generate it with a modern FPGA as there are huge error bars even if you make some small mistakes.

Also blanking areas are still important because at the end of a pixel row there is still some amount of extra electronic stuff happening that is slightly slower than jumping to the next pixel. Even on LCDs or OLEDs.

Even 4K HDR HDMI 2.1 still has something akin to blanking intervals.

Displayport has two features that allow this, Panel-self-refresh and Panel Replay. Otherwise if you don't send the entire frame every sync cycle, the display will lose signal and go blank.

Because those systems are orders of magnitude simpler, without all the copy-protection and control-plane "features" in modern display systems.

Is https://hackaday.com/2013/10/11/an-open-source-gpu/ what you mean out of interest, there's a link to a kickstarter, which links to - https://github.com/asicguy/gplgpu

Not the same guy, but if you're interested in the subject https://github.com/xenowing/xenowing is also worth a look.