Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring FPGA Graphics

projectf.io

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Exploring FPGA Graphics

#21

Post by benrow »

I'm just getting started on my hardware journey by working through the nand2tetris course. This has its own simplified hardware description language which works in the simulator they provide.

Looking through the linked site, it's nice to see that the verilog snippets are very similar to the simplified HDL in nand2tetris - almost identical in how pins and parts are composed.

I'm looking forward to getting hold of an ice40 board as mentioned (with the SRAM). There's a project out there which implements nand2tetris on ice40, and these seem available at the moment for a reasonable price.

So now with this VGA project, that's two reasons to order that nice ice40 board :-)

Re: Exploring FPGA Graphics

#22

Post by leeter »

amelius wrote: post #7

Why are we still generating video signals as if there is a CRT on the other end? E.g. we could save power by only sending parts of the display image that change.

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

Re: Exploring FPGA Graphics

#23

Post by scoutt »

NextHendrix wrote: post #13
amelius wrote: post #7

Why are we still generating video signals as if there is a CRT on the other end? E.g. we could save power by only sending parts of the display image that change.

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 whate…

If you don't send the entire buffer then a monitor should have at least 6220800 bytes of RAM dedicated to the frame buffer (1920x1080 resolution), do auto refresh (standard 60Hz) on the panel, and accept commands to overwrite said memory with new data, partially or completely.

That solution is far from what we have now, and much more like a serial LCD controller.

Re: Exploring FPGA Graphics

#24

Post by drivers99 »

benrow wrote: post #21

I'm just getting started on my hardware journey by working through the nand2tetris course. This has its own simplified hardware description language which works in the simulator they provide. Looking through the linked site, it's nice to see that the verilog snippets are very similar to the simplified HDL in nand2tetris - almost identical in how pins and parts are composed. I'm looking forward to getting hold of an i…

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)

Re: Exploring FPGA Graphics

#25

Post by mlindner »

amelius wrote: post #7

Why are we still generating video signals as if there is a CRT on the other end? E.g. we could save power by only sending parts of the display image that change.

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

Re: Exploring FPGA Graphics

#26

Post by benrow »

drivers99 wrote: post #24
benrow wrote: post #21

I'm just getting started on my hardware journey by working through the nand2tetris course. This has its own simplified hardware description language which works in the simulator they provide. Looking through the linked site, it's nice to see that the verilog snippets are very similar to the simplified HDL in nand2tetris - almost identical in how pins and parts are composed. I'm looking forward to getting hold of an i…

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…

This sounds very cool - it's interesting to hear what projects lie further down this trail.

I was initially looking at the Arty board, as it was referenced by a text book - all the exercises were based on it. It's a bit more pricey than the ice40 (enough to force a comparison against other boards), but it certainly looks more capable.

Re: Exploring FPGA Graphics

#27

Post by amelius »

NextHendrix wrote: post #13
amelius wrote: post #7

Why are we still generating video signals as if there is a CRT on the other end? E.g. we could save power by only sending parts of the display image that change.

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 whate…

I think people can come up with more efficient protocols than sending x,y,rgb for every pixel. What you call "edge detection" is not necessary if you use shadow buffers. Yes, the display would need some memory, but this is measured in tens of megabytes which is not much by today's standards.

Re: Exploring FPGA Graphics

#28

Post by garaetjjte »

ChuckNorris89 wrote: post #8
amelius wrote: post #7

Why are we still generating video signals as if there is a CRT on the other end? E.g. we could save power by only sending parts of the display image that change.

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…

DVI is almost literally digitized VGA, with analog signals replaced by differential signalling and symbol encoding to keep it DC-balanced. HDMI extends it by encoding audio and extra metadata (eg. used colorspace) inside blanking intervals (yes, they still use blanking intervals that were originally required for CRT displays). It doesn't do any handshake. Main difficulty is just high clocks required, and necessity to dynamically pick symbols (unless you only use few preselected DC-balanced values). DisplayPort and HDMI 2.1 are different, with packet-based transmission.

Re: Exploring FPGA Graphics

#29

Post by dahart »

amelius wrote: post #27
NextHendrix wrote: post #13

Earlier quoted context omitted.

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 whate…

I think people can come up with more efficient protocols than sending x,y,rgb for every pixel. What you call "edge detection" is not necessary if you use shadow buffers. Yes, the display would need some memory, but this is measured in tens of megabytes which is not much by today's standards.

Seems like having memory embedded in the display for a shadow buffer, and the diffing algorithm you’re proposing, could easily undo any power savings you’d get, and then some. Why are you certain that saving power is simple? How much power does the data protocol consume compared to the display itself? Isn’t the data transmission power in the noise margin of the power requirements for an active display, CRT or LCD?
Post reply on HN