FPGA VGA Controller for 8-bit computer

[asmi]

With "effort", that Max10's PLL and LVDS transmitters are fast enough to directly drive 480p DVI. (HDMI compatible, but, no sound or EDID support)  Though, you will still need proper ESD protection on the HDMI port. with load termination resistors to adapt the voltages.

Spartan-7 and Artix-7 support TMDS natively, easily outputting 720p and (with some effort) even 1080p on almost any pins (48 out of 50 pins in a bank can be used as differential pairs, and each pair has a pair of ISERDES/OSERDES bound to them).
As for ESD, I love TPD12S521 - it combines ESD protection for main data lanes, and voltage level translator 5 V <-> 3.3 V for DDC, CEC and HPD lines.

[Berni]

Yep i recommend using the DVI serialiser chip that BrianHG suggested. It makes DVI as simple as VGA since you just put the RGB data into the chip rather than into a DAC, all happening at nice low clockspeed parallel speeds, so its easy to even do 1080p 60Hz

As for memory organization i would recommend you keep the color pallete and character ROM inside the FPGA block RAM. These memories are accessed pretty much on every pixel and are small enough to fit easily fit into it, so it will save you a lot of accesses to external memory. Only keep the large stuff that wont fit inside in the external memory such as framebuffers, tilemaps, drawcall tables...

As for graphics modes id say you could combine modes because you have plenty of bandwidth. Like for example having a 640x480 text mode overlayed across a 640x480 graphics mode with 16 or even 256 colors. Gives you a easy fast way to show text on top of graphics. Tho for any sort of games you probably don't want a oldchool PC CGA like graphics mode anyway as the Z80 might be kinda slow at drawing to it. To make good looking games you probably want tilemap modes like the SNES. The video hardware in that game system has 4 layered tilemaps each using its own color pallete with an additional sprite layer on top. The layers are transparently blended together and can be independently moved around in pixel granularity. This is how the SNES does parallax scrolling that gives 2D platform games the impressive visuals.

EDIT:
Here is a good example of parallax scrolling put to good use: https://www.youtube.com/watch?v=VL7jR1NN4p0&feature=youtu.be&t=837
Its on a Sega Genesis/Megadrive so it has similarly powerful graphics hardware to the SNES but works a bit differently.
The impressive things on the SNES generally use the famed Mode 7: https://www.youtube.com/watch?v=H6u7Nk6_L50&feature=youtu.be
The hardware behind that is actually not that advanced, its just so called Affine transfromation in the video chip combined with some clever game programming. These transformation just need multiply and addition operations so a FPGA can calculate them in a single clock cycle at high speed using hardware multiplier blocks.

[nockieboy]

...Go for the 1.28mbit Max10 as it is only 3$ more than the 512kbit.  With this, you will be able to superimpose color text ontop of the 320x240x256 color paletted graphics as well as full vertical height colored sprites.

Thank you - I appreciate the guidance as one thing I've come to realise during this discussion is that there is so much choice in FPGAs alone, not counting the different ways of interfacing to the system and connecting additional memory, that I'm getting quite confused by it all.

The only question I have about the Max10 is will be able to output direct to HDMI at 720x480?  I know the Spartans I've been looking at have SERDES support built-in.

In fact, there is enough in this Max 10 to make an entire Atari 130xe with 6502 emulation & graphics and sound...

Well, that's the next thing - with all that space left over, it would be remiss of me NOT to put an AY-3-8910 sound generator (or something else) in there.  That would save me an entire (troublesome) PCB in my system... but where does that stop, I guess? 

how many are you going to build? when you can get FPGA,RAM,PSU and flash on a board for ~$20 I'd think you'll have to make quite a few to make it cheaper

A handful initially - one or two, maybe.  The whole thing is a one-off prototype at the moment, but I have intentions down the line to open the design up for people who want to have a go at building it and maybe try to make some of my costs back.

Why do you need such a large package? Spartan-7 devices up to S50 are available in a FTGB196 package, which was specifically designed to be fully broken out on a 4 layer board, which are very cheap nowadays. This package has 100 user IO pins (2 banks containing 50 pins each), which should be plenty for your needs. And you can easily solder it using just a hot air gun.

Purely to have enough internal RAM to hold the frame buffer.  If it has the RAM I need and can drive an HDMI output without too much hassle, it sounds like a good idea.

With "effort", that Max10's PLL and LVDS transmitters are fast enough to directly drive 480p DVI. (HDMI compatible, but, no sound or EDID support)

It would be nice to have sound too. 

Though, you will still need proper ESD protection on the HDMI port. with load termination resistors to adapt the voltages.

OR:
http://www.ti.com/product/TFP410/samplebuy

Spartan-7 and Artix-7 support TMDS natively, easily outputting 720p and (with some effort) even 1080p on almost any pins (48 out of 50 pins in a bank can be used as differential pairs, and each pair has a pair of ISERDES/OSERDES bound to them).
As for ESD, I love TPD12S521 - it combines ESD protection for main data lanes, and voltage level translator 5 V <-> 3.3 V for DDC, CEC and HPD lines.

Okay, so the TFP410 and a MAX FPGA are starting to look like the best option (the issues soldering the Spartan packages are a big hurdle, unfortunately) - will I need something like the TPD12S521 for ESD protection if I'm using a TFP410?

As for memory organization i would recommend you keep the color pallete and character ROM inside the FPGA block RAM. These memories are accessed pretty much on every pixel and are small enough to fit easily fit into it, so it will save you a lot of accesses to external memory. Only keep the large stuff that wont fit inside in the external memory such as framebuffers, tilemaps, drawcall tables...

Yes, that makes sense.  I think I'm going to try my best to keep it ALL in the internal block RAM if I can, with a view to expanding into external RAM as I get more experienced and comfortable with the design, VHDL and FPGAs in general.

I think I mentioned several times that I intend to keep the charset in ROM and copy it to RAM when the FPGA is turned on - just to clarify, now I understand a little more about the FPGA architecture, as I understand it the charset will be in RAM anyway, just re-instated to its default data every time the FPGA is turned on, so changing the charset/symbol table will be possible from the get-go.

To make good looking games you probably want tilemap modes like the SNES. The video hardware in that game system has 4 layered tilemaps each using its own color pallete with an additional sprite layer on top. The layers are transparently blended together and can be independently moved around in pixel granularity. This is how the SNES does parallax scrolling that gives 2D platform games the impressive visuals.

Yes, that sounds like an achievable goal - though I'm going to take baby steps getting there, building on the basic text-only mode and improving it as I learn.

Here is a good example of parallax scrolling put to good use: https://www.youtube.com/watch?v=VL7jR1NN4p0&feature=youtu.be&t=837

I thought you were going to link me to something like Shadow of the Beast on the Amiga.   Do you think what I'm designing would be capable of that sort of output (perhaps at a lower resolution?) 

The impressive things on the SNES generally use the famed Mode 7: https://www.youtube.com/watch?v=H6u7Nk6_L50&feature=youtu.be
The hardware behind that is actually not that advanced, its just so called Affine transfromation in the video chip combined with some clever game programming. These transformation just need multiply and addition operations so a FPGA can calculate them in a single clock cycle at high speed using hardware multiplier blocks.

That's impressive stuff - some might say almost black magic for a Z80 to be able to pull off?!  (I know it's the power of the FPGA doing the gruntwork, but still, the Z80 would get the credit) 

[Berni]

Yeah you will be able to fit it all into internal block RAM no problem as long as you keep framebuffers small since those tend to be the largest. Indeed taking baby steps is the way to go. The VGA using 74xxx series logic is an excellent video to demonstrate how you would also develop video output on a FPGA. First you need to build a video timing generator, then once that is working set up pixel coordinate counters, feed the counters directly into the RGB data lines to make sure they generate the counting color pattern you expect, then hook up some memory between the counters and RGB lines to actually generate some images. Once you have that you essentially have a working video card where you can slowly tack on features such as a text mode, or tilemaps. This sort of progressive workflow is excellent especially for starting out since you will have enough to learn as it is and probably won't be interested in design validation trough simulators and timing analysis from the start. But once you had enough headaches debugging a non working design on real hardware you start to see why HDL simulators and writing test benches are a good idea. But still getting a cheap FPGA devboard and just having at it with simple projects is the best way to start.

As for what is possible, all the videos i have linked are perfectly possible on a Z80 with grunty enough video hardware. This also includes "Shadow of the Beast" for the Amiga, all the pretty multi-layer scrolling is the hard work of the video hardware. Each layer is its own image that is being transparently overlayed by the video chip. Additionally the Amiga has bitblit functionality so this is essentially a crude 2D GPU that can move and draw images in memory on its own while the CPU is free for other tasks. So the CPU here has very little work to do as its only running the game logic, updating positions of all enemies, changing coordinates of the layers to make them move in that sweet parallax way and commanding the bitlit to fill in the edges with more of the level as needed.

This video hardware is the reason why graphics on consoles looked so impressive while PC games looked like crap in comparison despite having faster CPUs. The PCs for a long time had very dumb video hardware that could only barf out a framebuffers contents to the monitor and that's it(ignoring text mode). So the CPU had to work hard and draw every single pixel. To get 3D graphics on PCs they had to cheat in all sorts of ways using raycasting, so early 3D games like Wolfenstein3D, Doom, Quake etc. are not actually rendering in 3D, but is actually a 2D world made to look 3D trough graphics trickery. By the time PCs got fast enough to render proper textured polygon 3D graphics, the consoles already had hardware accelerated 3D chips in the Sony PS1 and Nintendo N64 that could look way better and run smoother. Its when PCs got hardware 3D accelerator cards like the Voodoo, that's when they could finnaly rival console graphics.

Even today graphics cards are the ones driving 3D towards looking ever more impressive. Even as CPUs hit the clock speed barrier 15 year ago they kept getting faster at an exponential rate, mainly thanks to the inherently parallel nature of graphics tasks, while 15 years ago graphics cards might have had 16 processing cores in them today they have >1000 cores being fed data from a huge array of DDR memory chips at terabits per second. For a modern PC to render a beautiful highly detailed 3D scene all the CPU has to do is load in all the models and textures, give it the draw call instruction list and say "Hey GPU please render this for me". A few miliseconds later using trillions of math operations and gigabytes of data moved around out pops the finished image while the CPU was doing absolutely nothing.

EDIT:
Oh and if you wan to learn about the various graphics tricks that are used everywhere this is one of the best youtube channels for it:
https://www.youtube.com/watch?v=nBzCS-Y0FcY&feature=youtu.be&t=2310
The linked video is one of his more impressive things where he created a polygonal 3D rendering engine in pure C++ code running on the CPU, so it guides you trough all the ideas and math that are used under the hood to generate 3D graphics. Its completely impractical because its slow, but it shows exactly how it works because its coded from the ground up without any graphics library. In his other videos he goes into all sorts of other really common graphics algorithms that are used everywhere like for example the affine transform, vector drawing, pathfinding, colision detection, game physics, edge detection, image processing... etc

[jhpadjustable]

Well, that's the next thing - with all that space left over, it would be remiss of me NOT to put an AY-3-8910 sound generator (or something else) in there.  That would save me an entire (troublesome) PCB in my system... but where does that stop, I guess? 

Two notes as preface: 1. There are MOS 6581 IP cores available, which you can instantiate just like any other VHDL entity, hook up address/data buses, supply with appropriate clocks, and connect to the DAC of your choice. 2. Back in my home computer days, sound programming was my specialty. Over the course I have developed some Opinions on this matter.

The Amiga sound hardware was remarkably simple, and it's worth considering as a guide. Each channel isn't much more than a period down-counter, an address up-counter, a sample length down-counter, and a few double-buffered latches. Being relatively insensitive to latency, a double-buffer for sample data allows you to take your sweet time reading the next sample(s) from memory and simplifies its integration into the system. Very likely you have hardware multipliers on the FPGA for volume control, AM effects, and so on. I2S is a standard interface to audio codecs and is pretty easy to use for just digital output: a continuously-running clock, a shift register, and a word (left/right channel) select is about it.

Remember when I half-jokingly suggested putting a Z80 core on the FPGA? Does that perchance remind you of any Sega console's sound hardware? You wouldn't have to worry about DMA at all, just let the software do it...

Purely to have enough internal RAM to hold the frame buffer.  If it has the RAM I need and can drive an HDMI output without too much hassle, it sounds like a good idea.

You can use those block RAMs as FIFOs very easily (example user guides from Xilinx, Altera). You can stream the entire next raster line from the external RAM into them at the fastest pace it allows then deal with it locally according to the pixel rate, a la hierarchical memory. In fact, this allows you to decouple the RAM clock from the pixel clock which makes your job a lot easier, enough that you can incorporate existing DRAM/SDRAM/DDR controller cores to expand the framebuffer (or can we now call it "chip") memory without limit.

I thought you were going to link me to something like Shadow of the Beast on the Amiga.   Do you think what I'm designing would be capable of that sort of output (perhaps at a lower resolution?) 

Eventually.   Multi-playfields are largely about memory organization and bandwidth. One key is to decouple the pixel fetch start/stop timing, memory addressing, and row stride from the display window start/stop timing, so that the former can be moved around independently of the latter, and only require that the CPU redraw the columns/rows that would be revealed in the next frame before moving the pixel start address around. Another key observation is that Amiga etc. video memory was often planar-organized to conserve frame buffer memory and use the memory cycles allocated to the pixel data most efficiently. With bit planes being indexed, addressed, and fetched entirely independently, the addition of a dual-playfield mode requires no modifications to the memory fetching system, only a bit of steering logic in the pixel pipeline and a priority encoder to establish Z-index relationships. Have as many playfields as you like.

[rstofer]

For pixel graphics, there is no reason that both sides of the BlockRAM need to have the same word width.  The CPU can read/write in bytes while the graphics controller can grab up some huge number of bits at a time.

https://www.xilinx.com/support/documentation/user_guides/ug473_7Series_Memory_Resources.pdf  About page 21

In theory, and I concede to never having tried it, you could organize the video side of the BlockRAM word width to be an entire scan line.

https://www.xilinx.com/support/documentation/user_guides/ug473_7Series_Memory_Resources.pdf

Of course, with dual port memory, you don't need to do this but it might be a technique to just grab the entire raster line into the pixel shift register during horizontal retrace.

[BrianHG]

With "effort", that Max10's PLL and LVDS transmitters are fast enough to directly drive 480p DVI. (HDMI compatible, but, no sound or EDID support)

It would be nice to have sound too. 

Understand that DVI transmitter cores are free available.  I'm not sure about HDMI (maybe copyrights, but a public domain transmitter may exist), however when saying sound, this means whatever your sound generator generates, you would need re-sample convert any audio generated to the standard fixed 48Khz audio within the HDMI standard.  Also, HDMI is YUV not RGB like DVI, so, you will also need a color space converter.  (easy peasy as it is nothing more than 3x3 multiply adds...)

Now, the Max10 can run upt to 400Mhz internal and the LVDS serial bus up to 750Mhz.  That means 720p capability, but with only 128kb ram and an 8bit cpu, you are not striving for this...
You have enough logic and hardware multipliers to do the colorspace conversions.
You have the internal dual port ram speed to superimpose translucent text with animated color character fonts.
Enough registers galore to control playfield, sup-pixel video offset of font tiles for smooth scrolling tricks, number of bytes per line with margins.
Also, on your video output mux output layers with translucent colors, don't forget to add pixel / sprite collision detection registers.

In the max10, you should be able to make an enhanced 16 bit version of a 6502 processor running at over 108Mhz, maybe at 8x27Mhz video clock of 216Mhz.  It would make a SNES look like a snail.

You would never have to worry about external Dram access or memory interleave timing.

With all the FPGAs ram as a dual block, one side would be a dedicated video and audio generator while the other would have interrupt free access to an external CUP, or an internal soft-core cpu.

Yes, on my video designs, I have my video read port only side set to 32 bit (note that I have 30bit color video, or 24 bit color with 8bit alpha blend channel) and my other side set to 256bit (I have access to 128bit DDR2 memory modules, yes this speed is needed for a 4 layer 1080p video blender)  In your case, you would want 8bit or 16bit on your read only video output port as you only go up to 256 colors if you want to use 1 byte per pixel.  It also makes access to you font bitmap easily addressable to any byte in ram.   You did say this is for an 8-bit computer.  On the CPU processor side, you can choose 8, 16, 32 bit if you like, but realize you may need to use a byte write enable depending on how your CPU or graphics image processor may move individual bytes around for effects like fill, copy, clear and stencil.

[hamster_nz]

With "effort", that Max10's PLL and LVDS transmitters are fast enough to directly drive 480p DVI. (HDMI compatible, but, no sound or EDID support)

It would be nice to have sound too. 

If the H/W can do DVI-D video, it can also do HDMI with audio. Once you get video working, have a look at this project that implements the HDMI data islands required for proper HDMI video+audio support;

https://github.com/charcole/NeoGeoHDMI

But consider it a stretch goal!

[legacy]

A thing I would really appreciate is a PCI Video framebuffer, made on neat and fully documented design.
VDU and 2D primitives to support X11 are all it needs to have.

There are PCI bridges to local legacy bus (kind of ISA, 16bit, with fixed address, and IRQ), hence even a simple VGA controller for 8-bit computer can be interfaced.

Not too bad, at all, and this would be seriously appreciated on non-x86 workstations where the only good thing you can do is:
- adding a Matrox M1/M2
- hacking an ATI XL

Both were reverse engineered, hence the support for what the hardware can really do is limited to the 20%

a miniPCI Video Card made on FPGA would be a super premium 


ah, sweet dreams ... are made of this

[asmi]

A thing I would really appreciate is a PCI Video framebuffer, made on neat and fully documented design.

PCI is quite a simple bus, with full specification publicly available. So I don't see any major obstacles in implementing this. Essentially PCI is nothing more than a DMA channel into the system memory.

[langwadt]

With "effort", that Max10's PLL and LVDS transmitters are fast enough to directly drive 480p DVI. (HDMI compatible, but, no sound or EDID support)

It would be nice to have sound too. 

Understand that DVI transmitter cores are free available.  I'm not sure about HDMI (maybe copyrights, but a public domain transmitter may exist), however when saying sound, this means whatever your sound generator generates, you would need re-sample convert any audio generated to the standard fixed 48Khz audio within the HDMI standard.  Also, HDMI is YUV not RGB like DVI, so, you will also need a color space converter.  (easy peasy as it is nothing more than 3x3 multiply adds...)

afaik HDMI supports both YUV and RGB

[nockieboy]

Yeah you will be able to fit it all into internal block RAM no problem as long as you keep framebuffers small since those tend to be the largest. Indeed taking baby steps is the way to go... But still getting a cheap FPGA devboard and just having at it with simple projects is the best way to start.

I think I'm going to make a start fairly soon with my Cyclone II.  Yes it's old, but I should be able to get a VGA text display up and running, perhaps even with some basic graphics, in the short term.  When the Spartan 6 (LX16) dev board turns up, I'll move development to that and start looking at the switch to HDMI and building out the resolutions a little further, with more work on the GPU side to flesh out the graphics capabilities.

As far as the Intel MAX 10 series goes, I agree they're the probably the best I can get in a package that I am (and more importantly, others are) able to solder by hand.  I'm thinking for the sake of another fiver (~$6), I'll get the 10M50 which has over 200 KB of RAM and should give me all the room I need to do what I want with the graphics and sound.

This leads me on to choice of a development board for the 10M50, though.  Sheesh - they're not cheap for a hobbyist at my level!  I've had a look at these two:

AliExpress DE10 Lite 10M50 CPLD Development Board with VGA - £74
AliExpress 10M50 Eval Kit with HDMI - £130

Now, out of the two I prefer the 10M50 Eval Kit - yes, it's nearly £50 more expensive, but it has less rubbish on it that I won't use taking up IO pins and it has an HDMI port built-in.

Anyone have any opinions on these or suggestions for alternatives?

...So the CPU here has very little work to do as its only running the game logic, updating positions of all enemies, changing coordinates of the layers to make them move in that sweet parallax way and commanding the bitlit to fill in the edges with more of the level as needed.

I guess there's no reason why the FPGA won't be a graphics co-processor and blitter in one device if I can build those functions into it.  What was it, jhpadjustable?  Agnus, Denise and Paula rolled into one?

Two notes as preface: 1. There are MOS 6581 IP cores available, which you can instantiate just like any other VHDL entity, hook up address/data buses, supply with appropriate clocks, and connect to the DAC of your choice.

Yes, I've found AY-3-891x VHDL code as well, so it looks relatively easy to sort out.  It could just be consideration how I get that audio data down the line to the TV.

2. Back in my home computer days, sound programming was my specialty. Over the course I have developed some Opinions on this matter.

Ah, pull up a chair and have a beer.  I may need to pick your brains later on when (if!) I get to the point of sorting out audio in VHDL!!

The Amiga sound hardware was remarkably simple, and it's worth considering as a guide. Each channel isn't much more than a period down-counter, an address up-counter, a sample length down-counter, and a few double-buffered latches. Being relatively insensitive to latency, a double-buffer for sample data allows you to take your sweet time reading the next sample(s) from memory and simplifies its integration into the system. Very likely you have hardware multipliers on the FPGA for volume control, AM effects, and so on. I2S is a standard interface to audio codecs and is pretty easy to use for just digital output: a continuously-running clock, a shift register, and a word (left/right channel) select is about it.

You make it sound so easy!    I can just about play the theme tune to Red Dwarf on a keyboard.  There endeth my knowledge and skills on the subject of audio and music!    I2S? Audio codecs? Digital output?  So I could output in MP3 or something?

You can use those block RAMs as FIFOs very easily (example user guides from Xilinx, Altera). You can stream the entire next raster line from the external RAM into them at the fastest pace it allows then deal with it locally according to the pixel rate, a la hierarchical memory. In fact, this allows you to decouple the RAM clock from the pixel clock which makes your job a lot easier, enough that you can incorporate existing DRAM/SDRAM/DDR controller cores to expand the framebuffer (or can we now call it "chip") memory without limit.

Okay, that's an interesting idea for when/if I get round to using external RAM (it'd make the FPGA choice a lot cheaper!)  Set up a couple of pixel stream FIFOs in internal RAM and use the external SDRAM to burst-read into the one not being read from at that moment, so access to the external RAM would be in short bursts to read the contents, allowing the GPU to access it for data writes etc. in-between?

Eventually.   Multi-playfields are largely about memory organization and bandwidth. One key is to decouple the pixel fetch start/stop timing, memory addressing, and row stride from the display window start/stop timing, so that the former can be moved around independently of the latter, and only require that the CPU redraw the columns/rows that would be revealed in the next frame before moving the pixel start address around. Another key observation is that Amiga etc. video memory was often planar-organized to conserve frame buffer memory and use the memory cycles allocated to the pixel data most efficiently. With bit planes being indexed, addressed, and fetched entirely independently, the addition of a dual-playfield mode requires no modifications to the memory fetching system, only a bit of steering logic in the pixel pipeline and a priority encoder to establish Z-index relationships. Have as many playfields as you like.

There's a heck of a lot of jargon in there I just don't understand - "pixel fetch start/stop timing", "row stride", "display window start/stop timing"... so much to learn.  Is there a book on this stuff anywhere, or a website, or more YT videos?  I have yet to sit down with some spare time and go through some of the linked videos in the YT links people have made in previous replies, though...

Understand that DVI transmitter cores are free available.  I'm not sure about HDMI (maybe copyrights, but a public domain transmitter may exist), however when saying sound, this means whatever your sound generator generates, you would need re-sample convert any audio generated to the standard fixed 48Khz audio within the HDMI standard.  Also, HDMI is YUV not RGB like DVI, so, you will also need a color space converter.  (easy peasy as it is nothing more than 3x3 multiply adds...)

Just clear up a little confusion for me - DVI sort of equals HDMI?  Would I be able to use an HDMI connection to a TV with a DVI IP core?

The colour space converter sounds like a simple bit of VHDL to add to the project, but what about the audio conversion?  Are there IP cores for that sort of thing?

Also, on your video output mux output layers with translucent colors, don't forget to add pixel / sprite collision detection registers.

That'll come later, but yes I'll need to think about how to add collision detection etc.

You would never have to worry about external Dram access or memory interleave timing.

I do like the sound of that.  It's just a high price to pay and I can see that I'll want to try to overcome the issues with external RAM so that I can use a smaller/cheaper FPGA.

...but realize you may need to use a byte write enable depending on how your CPU or graphics image processor may move individual bytes around for effects like fill, copy, clear and stencil.

Huh? Sorry, I don't follow.  Could you expand on this a little, please?   

[legacy]

I mean, if someone develops a simple video card for 8-bit computer, I know to add a PCI interface to it: via PLX chip. Already done, my team has the know/how and a dev-board to manage it.

[Berni]

Yes having the video output hardware and blitter in the same FPGA makes a lot of sense since both need access to graphics RAM. Its not all that difficult to MUX the memory bus inside the FPGA around to different parts that need it. That blitter will let you move things around in RAM at easily >10 times higher speed than the Z80 could.

In fact you can even use the same graphics RAM to hold audio data too. Typically memory is not needed for that since the audio from the 8bit era tend to be just chiptune like for example the Commodore SID chip. But later on MOD music became popular since it had the flexibility of wave files but was still small in size. This does need a memory to hold the audio samples in RAM for quick access and would be quite a lot of work for a Z80 to turn into wave audio to send to a DAC. So if you want an audio chip that can play pretty much anything you might want to have a MOD player in a FPGA that can play these files from memory without the CPUs intervention. But for a start its best to stick to some basic analog synthesis to generate beeps when you write to its register since that can be written and tested in HDL in a few hours if you know what you are doing.

For audio output out of the FPGA i would just simply have it generate a fast PWM signal that gets smoothed by a RC filter into analog audio. It only takes about 5 lines of code to write a PWM generator in HDL and everyone has a spare resistor and capacitor laying around. Makes for surprisingly high quality audio when the PWM is running fast enugh. But if you want proper hifi quality audio you can always add a I2S DAC chip to the pins. The I2S bus is almost the same as SPI so its really easy to generate in HDL too. You still could not play back MP3 tho because decoding MP3 requires quite a bit of floating point math and im sure your poor Z80 wouldn't enjoy that. It could be possible if you also added a floating point math coprocessor to the FPGA so that the math could run nice and fast, but this is really pushing the Z80 into things its really not meant to do.

As for HDMI and DVI. Pretty much DVI is part of the HDMI feature set. It uses the same 3 data + 1 clock diff pair with the same signaling levels and uses the same TDMS encoding to AC balance the signal and provide error correction. Both DVI and HDMI support the RGB color format, but HDMI can additionally also handle YUV. Its all still just glorified LVDS video with fancy encoding on top. What HDMI does differently is sneaking extra data into the video blanking periods, this is where audio and other stuff is sent, and there is support for encrypting the whole video stream via HDCP (This is just the movie industry trying to keep people from pirating stuff, but its hilariously ineffective). But all this is why you can create a DVI to HDMi adapter by simply cutting apart two cables and splicing together the right pairs, both are almost the same thing just on a different connector.

Id say for a start stick to raw VGA directly from the pins so that you can learn all about video timings in a way that is easy to look at with a scope. Its easy to then turn that into DVI by pretty much just running the exact same signals into a DVI serializer/encoder block rather than straight out the pins. Just get a cheap FPGA board and play around rather than worrying about it. You can always buy a bigger board later on. Just keep in mind that porting code between two FPGAs of the same vendor is pretty easy, porting it to a FPGA from a different vendor is usually not easy at all (The HDL code is perfectly portable but any hardware specific blocks like block RAM and FIFOs are not) and you have to relearn a completely different IDE.

[asmi]

I mean, if someone develops a simple video card for 8-bit computer, I know to add a PCI interface to it: via PLX chip. Already done, my team has the know/how and a dev-board to manage it.

If the only thing you want from the card is to hold a bitmap and output it via some interface, this can be done using Vivado with zero HDL code: MIG to interface with framebuffer memory, PCIE to AXI bridge to read/write data to the framebuffer from the host, "Video Frame Buffer Read" to stream frame from memory, VIC and PHY of your choice to actually output the video to the interface of your choice.
But a video card is far from being only "framebuffer adapter". In addition to all of above it needs to provide some kind of drawing and composition functions. This is even more important if your CPU is very slow. And this is the hard part.

[jhpadjustable]

I guess there's no reason why the FPGA won't be a graphics co-processor and blitter in one device if I can build those functions into it.  What was it, jhpadjustable?  Agnus, Denise and Paula rolled into one?

Eventually Paula's duties included ADCs for the game port, DACs for audio, the UART (you probably already have one) and floppy disk I/O (you probably don't have one). Those don't directly translate to the FPGA model, but she can be there in spirit.

Ah, pull up a chair and have a beer.  I may need to pick your brains later on when (if!) I get to the point of sorting out audio in VHDL!!

I'm more of a Verilog guy but cheers, I'll keep an eye out and help out where I can.

You make it sound so easy!    I can just about play the theme tune to Red Dwarf on a keyboard.  There endeth my knowledge and skills on the subject of audio and music!    I2S? Audio codecs? Digital output?  So I could output in MP3 or something?

Not even Popcorn? For shame! Anyway... codec has an archaic definition of a full-duplex digital-analog converter, an ADC and DAC in one package, usually with a common clock and common framing signals. I should have said ADC/DAC or something like that. MP3 output would be possible, but doesn't seem very interesting due to the lack of direct output devices and the latency, and the rather large number of gates required. TOSlink might be cool, if you have a use for it. The nice thing about all this extra hardware is that you can place footprints on the board for it and not stuff them, or stuff them and just not hook your HDL up to them, leaving them as exercises for the experimenter.

Okay, that's an interesting idea for when/if I get round to using external RAM (it'd make the FPGA choice a lot cheaper!)  Set up a couple of pixel stream FIFOs in internal RAM and use the external SDRAM to burst-read into the one not being read from at that moment, so access to the external RAM would be in short bursts to read the contents, allowing the GPU to access it for data writes etc. in-between?

Better than that, you can use a single FIFO and fill it whenever you feel like it and there's room. You don't need to double buffer because they're inherently semi-dual ported. But you've got the general idea right.

There's a heck of a lot of jargon in there I just don't understand - "pixel fetch start/stop timing", "row stride", "display window start/stop timing"... so much to learn.  Is there a book on this stuff anywhere, or a website, or more YT videos?  I have yet to sit down with some spare time and go through some of the linked videos in the YT links people have made in previous replies, though...

The Amiga HRM I linked earlier is an excellent, accessible resource that's fit for people with basic programming and hardware knowledge. While they won't tell you much about the gate-level implementation, Chapter 3, Playfield Hardware, describes the general concepts of raster video display in the context of the specific case of the Amiga OCS. Translating from my language to theirs, pixel fetch is called data fetch, row stride is approximately equivalent to playfield width, and display window is display window.

Huh? Sorry, I don't follow.  Could you expand on this a little, please?   

I believe he's referring to the rather common possibility that an external RAM chip's external data bus is more than one byte wide, and therefore has a few extra byte-select signals that need to be considered when writing only part of its total width. I think you'll find this ISSI pseudo-static RAM in a hobbyist-friendly TSOP-II package and its datasheet accessible and interesting. Its byte write enables are UB# and LB#. They're much like an extra set of chip enables for each separate byte, so that only the desired byte parts of the two-byte-wide bus are driven or sampled. The truth table on datasheet page 3 and timing diagrams throughout may help.

So if you want an audio chip that can play pretty much anything you might want to have a MOD player in a FPGA that can play these files from memory without the CPUs intervention.

As someone who is not completely unknown to the exotica branches of the Amiga audio community... Hard-coding the MOD format in HDL? Just... no. It will only get in the way. I would strongly suggest, for simplicity, borrowing the Amiga's audio architecture whole, and letting the main CPU be interrupted at however many ticks per second to adjust the DMA/pitch/volume registers as needed. That way it's much easier to borrow channels for sound effects over/under the music (if desired), and allows for 16-bit samples, various packed tracker module formats or multichannel formats like FastTracker, and formats that are not reducible to the drum-machine tracker paradigm, such as TFMX. We've got to give the poor Z80 something to do, haven't we?

Since this isn't for a proprietary product, IMHO it's worth leveraging any open IP cores that can help rather than do all that from scratch. I think MP3 needs more than a floating point coprocessor, probably closer to a complex math accelerator with its own (small) program store to do IDCTs and such.

(The HDL code is perfectly portable but any hardware specific blocks like block RAM and FIFOs are not) and you have to relearn a completely different IDE.

But most logic synthesizers will be able to infer memory from HDL, perhaps with a bit of coaxing, and FIFOs are just control logic around those memories, no? At the speeds of interest, fabric implementation of FIFO functionality would do, no?

But a video card is far from being only "framebuffer adapter". In addition to all of above it needs to provide some kind of drawing and composition functions. This is even more important if your CPU is very slow. And this is the hard part.

CGA outputs video. It's in the form of a card. What exactly are you insinuating here?   

[Berni]

As someone who is not completely unknown to the exotica branches of the Amiga audio community... Hard-coding the MOD format in HDL? Just... no. It will only get in the way. I would strongly suggest, for simplicity, borrowing the Amiga's audio architecture whole, and letting the main CPU be interrupted at however many ticks per second to adjust the DMA/pitch/volume registers as needed. That way it's much easier to borrow channels for sound effects over/under the music (if desired), and allows for 16-bit samples, various packed tracker module formats or multichannel formats like FastTracker, and formats that are not reducible to the drum-machine tracker paradigm, such as TFMX. We've got to give the poor Z80 something to do, haven't we?

Since this isn't for a proprietary product, IMHO it's worth leveraging any open IP cores that can help rather than do all that from scratch. I think MP3 needs more than a floating point coprocessor, probably closer to a complex math accelerator with its own (small) program store to do IDCTs and such.

(The HDL code is perfectly portable but any hardware specific blocks like block RAM and FIFOs are not) and you have to relearn a completely different IDE.

But most logic synthesizers will be able to infer memory from HDL, perhaps with a bit of coaxing, and FIFOs are just control logic around those memories, no? At the speeds of interest, fabric implementation of FIFO functionality would do, no?

Well i didn't mean a fully autonomous MOD file format player that could read a .mod file byte by byte. Just audio hardware that is well suited for playing it back like having the ability to play back various wave samples from memory at various pitch with multiple channels. Makes it easy to have very impressive sound without a ton of HDL code or a lot of CPU effort to play it.

Yeah its possible for the compiler to infer block RAM into a design, but i never really trusted it with doing that since small details in the way you implement it in HDL can make the compiler refuse to do it because it might not look similar enough to the hardware block. But it is not only for block ram, similar goes for other hardware features like PLLs, hardware assisted serdes, DDR pin drivers, retiming flipflops inside IO pin logic etc... So offten the way it is done for block RAM is that an abstraction layer is put in place where a HDL file holds the implementation module for the block RAM and upon porting it you are supposed to replace the implementation with your vendors one and implement any logic around it to get it to provide the same signals (Like flip some lines around, add a latch if it needs it, make the reset work the same way...).

And overall the vendors tools often provide a sizable collection of useful auto generated building blocks. This ranges from simple stuff like a RAM or FIFO to interfaces like DDR2 memory controllers to stuff like heavily chip optimized FFT, DDS, FIR filters etc... And goes on to even broader tools that generate entire systems like Altera Qsys that automatically generates memory and streaming buses to connect components such as softcores, memory, peripherals etc... magically taking care of stuff like bus width and timing adaption, multimaster bus arbitration, addressing etc... (I actually quite miss that tool when working with Lattice chips)

[legacy]

If the only thing you want from the card is to hold a bitmap and output it via some interface, this can be done using Vivado with zero HDL code: MIG to interface with framebuffer memory, PCIE t

PCI, not PCIe, and I want to the PCI stuff done via PLX. I don't want anything done in FPGA regarding the PCI. I have a lot of experience with PCI, and not a thing I want to handle in FPGA.

[jhpadjustable]

Well i didn't mean a fully autonomous MOD file format player that could read a .mod file byte by byte. Just audio hardware that is well suited for playing it back like having the ability to play back various wave samples from memory at various pitch with multiple channels. Makes it easy to have very impressive sound without a ton of HDL code or a lot of CPU effort to play it.

That I can absolutely agree with. As I mentioned to nockieboy upthread, each channel isn't much more than a handful of down-counters and double-buffers attached to a DMA channel. Then multiply, sum, and ship to the DAC.

Yeah its possible for the compiler to infer block RAM into a design, but i never really trusted it with doing that since small details in the way you implement it in HDL can make the compiler refuse to do it because it might not look similar enough to the hardware block. But it is not only for block ram, similar goes for other hardware features like PLLs, hardware assisted serdes, DDR pin drivers, retiming flipflops inside IO pin logic etc... So offten the way it is done for block RAM is that an abstraction layer is put in place where a HDL file holds the implementation module for the block RAM and upon porting it you are supposed to replace the implementation with your vendors one and implement any logic around it to get it to provide the same signals (Like flip some lines around, add a latch if it needs it, make the reset work the same way...).

And overall the vendors tools often provide a sizable collection of useful auto generated building blocks. This ranges from simple stuff like a RAM or FIFO to interfaces like DDR2 memory controllers to stuff like heavily chip optimized FFT, DDS, FIR filters etc... And goes on to even broader tools that generate entire systems like Altera Qsys that automatically generates memory and streaming buses to connect components such as softcores, memory, peripherals etc... magically taking care of stuff like bus width and timing adaption, multimaster bus arbitration, addressing etc... (I actually quite miss that tool when working with Lattice chips)

All very good points.

I haven't played very deeply in the extra tools of Quartus and never even opened up Platform Designer. That looks really handy. Next time I have an FPGA project in front of me I'm going to have to play with that. This is why I come here 

[legacy]

But a video card is far from being only "framebuffer adapter". In addition to all of above it needs to provide some kind of drawing and composition functions. This is even more important if your CPU is very slow. And this is the hard part.

I said with the minimal 2D functions to support X11.

[legacy]

For pixel graphics, there is no reason that both sides of the BlockRAM need to have the same word width.  The CPU can read/write in bytes while the graphics controller can grab up some huge number of bits at a time.

The SEGA Geneis (Megadrive) uses a similar idea with the uPD41264 chip made by NEC

[BrianHG]

...but realize you may need to use a byte write enable depending on how your CPU or graphics image processor may move individual bytes around for effects like fill, copy, clear and stencil.

Huh? Sorry, I don't follow.  Could you expand on this a little, please?   

Ok, understand that the biggest cheat you have going for you when using the MAX10 internal static ram block is that on one side, for your dedicated video graphics and sprites and audio output, you will use an 8 bit port with an address which points to each individual byte.  You can get 1 new byte read 216 million times a second while only needing 1/8 for a true 256 color paleted image, another access cycle for a font byte image lookup, another for a sprite and another 4 or so once every H-sync for audio data.  Sorta like the Amiga Paula and Denise.

(This is separate of you global screen offset controls generally used for oversized image scrolling)  Now, if you also want a Blitter like the Amiga Agnus, this would involve reading a reference graphic and reading the destination display memory, working out the source image transparent stencil bits, within logic registers, paste over the destination read source memory so you are effectively singling out individual bits, then writing that logic register's result back into the destination display memory.  This is the hassle of pasting graphics with transparent bits where you also may want to shift left and right the bits of the source image data to move a pasted graphic 1 pixel at a time onto a bitplane style graphics.  Having this hardware blitter remover you 8 bit CPU from doing this manually when you want to paint brush images onto a bitplane style display.  You have the luxury because of the Max10's speed, logic density, and that dual port ram's nature to place such an image blitter on the 8 bit port side, or on the CPU read/write port side, or even half and half.

In 256 color, byte per pixel mode, just read the source rectangle graphic data and only write the pixel bytes to the destination if the stencil isn't transparent.  Wow, so much simpler but you need a whole lot of video memory to keep every pixel a single byte.  (This would make an insane arcade machine for 20 years ago, but you would want at least 2 full video page memories.)  (I wish the Amiga 1000 had 2mb chipram with an allowable 8 ram and worked with 8bit and 16bit pixels only, no bitplane rubbish, it would have flown except for the slow logic of the 1984 era when it was engineered, all they had to do was get the ram working at 28.6Mhz instead of 14.3Mhz, and 2mb of it the cpu didn't need to go any faster.  The price of memory would have been the killer.)

On the other side of you dual port memory you may also use a wider bus like 16 bits to interface with your CPU, however, what I am saying is if you do so, in Altera's/Intel's dual port memory configuration tool, you have a byte-enable feature which allows when writing to your dual-port ram's 16 bit side, writing to only the high or low 8 bits, or both.  This write-masking is necessary for CPUs doing an 8 bit write accessing a 16 bit wide ram.  Otherwise, your CPU will need to do a 'Read-Modify-Write' to write only 8 bits on that side.

Now everything I'm telling you is possible with relative ease since you do not have to wait for any external ram cycles and having to cache read and write bursts from external dram and it's controller.  You do not need to pipe anything at all.  However, going the other route with large external memory and speed, you can always simulate a bitplane display for your 8 bit cpu and just have 16 bit word pixels and do everything like a software emulator which grants you some enormous flexibility, but you will always be refresh generating a display, a page behind with dedicated buffers to cache memory with tons of wasted dram reads to address single bytes in the middle of larger bursts just to get to those single key important bytes whenever you need random access.  Otherwise, you will be either engineering a smart cache mechanism, or slowing everything down to even faster DDR memory's precharge and post charge cycles.   Normal DRam in some cases wont be any faster, but sequential bursts will be like lightning in comparison.  Other than painting a line of video,  how often does that happen in a 8 bit cpu world which has no smart cache.

[BrianHG]

Just so we are clear, there exist cheaper FPGAs with more than 1 megabit pr internal ram out there, but, you would need a VCCIO and VCC core supply & bootprom.  Example:


1.9 megabit core for 16$  (Good for animated 360x240x256colors with 2 fame buffers for animation plus another 80kb for software)
It also has double the logic elements...
https://www.digikey.com/product-detail/en/lattice-semiconductor-corporation/LFE5U-45F-6BG256C/220-2198-ND/9553911
https://www.mouser.com/ProductDetail/Lattice/LFE5U-45F-6BG256C?utm_term=LFE5U-45F&qs=w%2Fv1CP2dgqpblS%252b2xYE99A%3D%3D&utm_campaign=LFE5U-45F-6BG256C&utm_medium=aggregator&utm_source=findchips&utm_content=Lattice

Eval board is expensive since it comes with a 3.8Megabit FPGA, but, it gives you play room.

Also, the serdes on this Lattice part is fast enough to directly drive DVI/HDMI 1080p.
You'll be using so few IOs that a 4 layer PCB would be fine.
And you can still place a single DDR2/3 ram chip on the PCB if you like...

[jhpadjustable]

Also, the serdes on this Lattice part is fast enough to directly drive DVI/HDMI 1080p.

Nope, no SERDES on that part. Anyway, Lattice requires a subscription license to use SERDES-enabled chips so it would be useless to open-hardware hobbyists if it did. The BGA package is also a bit impractical, the comparatively generous 0.80mm pitch notwithstanding.

[SiliconWizard]

Also, the serdes on this Lattice part is fast enough to directly drive DVI/HDMI 1080p.

Nope, no SERDES on that part. Anyway, Lattice requires a subscription license to use SERDES-enabled chips so it would be useless to open-hardware hobbyists if it did.

Yes. The only ECP5 parts that have SERDES are the LFE5UMxx.
http://www.latticesemi.com/en/Products/FPGAandCPLD/ECP5

One way of evaluating it AND get a free license for this part is to buy a VERSA kit: http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/ECP55GVersaDevKit
(I think the license is restricted to the part used on this board:  LFE5UM5G-45F, but a lot can be done with it!)

There are promotional prices on those boards on a regular basis. I bought the VERSA board for the ECP3 a few years ago for $99. The VERSA ECP5 is about $250 and occasionally can be had for $99 too.