VGA controller using FIFO memory, discrete ICs and Arduino Uno/Mega?

Question

I love the Arduino boards. They're super easy to use and give me access to fairly powerful microcontrollers for all of about $12. Unfortunately, 16MHz isn't quite fast enough to display more than 120x60, 2-bit colour VGA (which is what I have right now on my Uno, using the VGAX library). Even trying to squeeze out 3- or 4-bit colour requires a resolution drop.

I'm making an Arduino-powered games console for the fun of it (I love my Mega Drive and thought it might be fun to see what I could achieve with Arduino). My plan WAS to have an Arduino Mega2560 running the game code and storing all the sprites in its 8KB of RAM, loading and unloading as necessary to/from an SD card or other external storage. The Mega would then send the 2-bit pixel data, 4 pixels at a time, via an 8-bit parallel bus (literally 8 jumper wires with two "acknowledge" lines) to an Arduino Uno, which would act as the display unit and use 95%+ of its processing power just spewing pixels out to the monitor/TV. That was fine, and worked well... but 2-bit colour just isn't quite enough to reach Mega Drive-era games, and is pretty hard to work with. So I decided to try to invent some sort of custom VGA controller...

---

Ideally, what I would like to do would be have a small SRAM chip (64KB would be HEAPS, even 8KB would be enough, though 16 would be better), which the Arduino talks to. The Arduino would create an array (i.e. the front buffer) in the first section of RAM, then just update the pixels as fast as it can. Then a custom circuit on the other side of the RAM, clocked at VGA-suitable speeds (~25MHz?) would read the pixels from the RAM (using some sort of counter to move through the array?). That way, even if the Arduino couldn't keep up, the VGA controller wouldn't be left without pixel data - rather, it would just be the pixels from the last frame. So you'd get tearing but that's not a major issue.

There's probably numerous reasons that would be hard to do. Different clock speeds, for a start. I don't really know how SRAM works but as I understand it having two different clock speeds trying to write and read at the same time might be bad. So...

---

I came across this post. In it they mention FIFO memory. Bingo! I didn't even know this was a thing! They refer to the SN74ALVC7804, a 512x18-bit FIFO memory chip. It sounds perfect. It would appear that the chip doesn't care if the clock is consistent or not, or whether the input and output clocks differ, as long as they don't go above 40MHz. It has pins to show when it's nearly full (and when it's full). It's 18-bit, meaning I can spew 3 pixels of 6-bit colour (nice and neat - a 2-bit resistor DAC on each colour wire, giving me 64 colours to play with) into the buffer so as to keep up with the VGA controller on the other side as it reads each of the 6 bits of data... and this is where I'm stuck.

---

So here is my real question: What would you suggest? I could always just buy an Arduino Zero/Due and be done with it, but that's no fun (and very expensive in Australia). I want some challenge, just so long as it's not physically impossible (i.e. trying to extract 120x60 4-bit colour from an Uno). I would need some way of switching between the first, second and third set of 6 bits from the FIFO. I'd also need some way of actually timing the pixel outputs (probably the hardest part, now that I think about it - not so much the timing itself but rather counting out the sync pulses, front/back porches, etc.). I'm not looking for someone to give me a straight-up BOM, just point me in the direction.

I love electrical engineering, but I don't have much experience with it. Plus I have no clue what kind of ICs you can buy to achieve this kind of thing. And finally, even though I'm a programmer first and EE second, FPGA programming just melts my brain.

Answer 1

In effect, you're trying to recreate a color CRT controller with memory interface. This is perfectly possible, but it's much more involved than you realize. The physical implementation can be either an FPGA, as alex forencich suggests, or discrete chips. The discrete section will need something like the 74FCT series for horizontal timing, and can easily get by with 74HC for vertical timing.

First, as you realize, you'll have to generate display timing at 25 MHz - except that you won't. A 25 MHz VGA pixel clock implies that you're trying for 640 x 480 pixels, and this cannot be stored in a 64 kB RAM - it would require a 512 kB RAM. Instead, a 64 kB RAM will only support a 256 x 256 display, and this will only require a pixel clock of about 12.5 MHz. This is straightforward using a 9-bit binary synchronous counter, and can be realized with 3 74FCT161 counters. The vertical timing also uses a 9-bit counter, but 74HC161s can be used, since vertical timing is much slower than horizontal. The outputs of the two counters feed at least one static RAM, and there are at least 3 different approaches you can use for the interface.

1) FIFO - This is your first thought, but it's more complicated than you think. First, it only makes sense to transfer one byte (or 6 bits) of intensity data at a time, but you also have to store the address as well as the data. If you're going with a 64kB RAM, this means 16 bits of address along with 6 to 8 bits of intensity, and you'll need more than one FIFO. This in turn means that you'll need to ensure that the FIFOs remain synchronized. You'll also need to provide a mechanism to monitor the FIFO empty line and generate a write pulse to video RAM whenever the FIFO is not empty: that is, whenever there is data in the FIFO waiting to be written. Furthermore, you'll also need to provide a mechanism to keep memory writes from interfering with display reads. You can do this either by running the video RAM at 25 MHz, but alternating read and write cycles, or by permitting writes to RAM only during the non-display portions of the scan. This will occur during front porch, back porch, sync, or vertical blanking intervals.

2) Dual port RAM - Here's another device technology to look at. In this case you use the DPRAM as the video buffer, and feed one side from the video controller and the other from the Arduino. Be forewarned, a 64k x 8 DPRAM requires a package with a lot of pins.

3) Bank Switching - In this technique, you provide 2 video RAMs, and at any time one is being written to while the other is being read from. The state of the RAM is controlled by a flip-flop which can be triggered by the Arduino. So first (let's say) you read from bank A while writing to bank B. When you've completed writing a complete frame, you toggle the bank selector and the video is now read from B while A is being written to. This is in some ways more straightforward than the other two, but it does not permit local overwriting of areas of the image in the same way the other two approaches do.

Answer 2

This is the perfect application for a small FPGA. It would be possible to implement a relatively powerful 2D drawing engine on the FPGA that can be controlled over SPI or I2C that can output full 8-bit color with a simple R-2R DAC. It would even be possible to have frame buffers that can be double-buffered or even composited on the fly. It would also be possible to implement hardware sprite drawing modules.

You could even get a slightly bigger FPGA and stick the AVR core on the FPGA as well to simplify the interface in between. You could also get an FPGA that has a built-in hard CPU core, such as the Zynq.

So, even if an FPGA is the 'right tool for the job', suppose you don't have one or don't want to use one. I would recommend using small FIFO chips, such as the CD40105 or 74ALS232. These are asynchronous 16 word 4 bit FIFOs. I would suggest using 3 of these, one for red, one for green, and one for blue. Construct simple R-2R DACs on the outputs of all 3. For the inputs, tie them in parallel to a GPIO port on your MCU. To write data, put 4 bits of red, green, or blue data on the port and pulse the corresponding write strobe. If you are careful about how you write your code, no extra delays should be required here - the FIFOs can deal with a very short pulse. Feed the data in ready output to another GPIO pin. After each write, check that pin to see if there is space left in the FIFO. On the output, tie all of the read strobes to a PWM pin. Set up the timer to generate the pixel clock. Now the FIFO write timing is just about completely decoupled from the pixel clock. You may even be able to handle this inside of an ISR that fires at at least pixel clock/16.

Edit: Now that I actually took a look at the code in vgax, it looks like your best option may be to simply modify vgax. The code is written to output one pixel every other clock cycle: https://github.com/smaffer/vgax/blob/master/VGAX.cpp#L141 . This is pretty much the absolute upper limit in terms of how quickly you can shove stuff out the door. If you want to do 6 bit pixels, you can rewrite this to read out another byte on each clock cycle instead of reading one byte and then unpacking it. However, you're going to run out of SRAM on the 328p: 120*60/4 = 1800 bytes, leaving only 200 bytes for everything else. However, if you use a larger chip with 8k of ram, 120*60 = 7200 bytes, and you can fit an entire frame buffer with 800 bytes to spare. One thing to note: you can read your sprites directly out of program memory. So if you switch to the Arduino Mega, you may be able to do everything on one chip, including the video output. Or you might be able to use a pair of Arduino Megas if you won't have enough memory on one. It may also make sense to extend the interface protocol between the two chips to include some way to selectively update parts of the frame buffer.

A dual-port RAM is also a possibility, but using one of those would require driving a rather large number of address lines. Doable, but you will almost certainly need to drive it with an Arduino Mega. One possible chip would be the IDT 7005 8K x 8 dual port SRAM, or its larger cousin the IDT 7025 8K x 16 dual port SRAM. These are both relatively easy to find on ebay AU. This has 12 address lines and 8 data lines on each port, along with RW, CE, and OE. The 16 bit version adds UB and LB. You will probably have to burn 3 ports (~24 pins) on your micro to talk to it. However, reading it out on the other side could be done with a simple 12-bit counter, built from discrete logic, and driven from a PWM pin, cleared to zero at the beginning of each frame. If you use the 16 bit chip, then you can play some more interesting tricks with an 8 bit multiplexer and another I/O port. Consider the 8Kx16 RAM as a pair of 4Kx16 RAMs, with the highest order address bit selecting which one to access. This gives you double buffering for the price of one GPIO pin to select which half of the ram gets sent to the display. 16 bits wide means you can write two pixels in parallel. For the 12 bit readout counter, connect bits 1-11 to address bits 0-10. Connect bit 0 to an 8 bit mux that selects which of the two halves of the RAM output port will be sent to the display.

Now that I think about it some more, it seems like you will actually need 2 counters on the output. The reason is that the RAM only holds 60 or 64 lines (128*64=8192), so each line needs to be repeated several times. This can't be done just by resetting a single counter, so what you need is a 5 bit counter and a 7 bit counter. The 5 bit counter counts the lines, and the 7 bit counter counts the columns. The two of these concatenated will connect to all 12 address lines (or 11 address lines and a mux). Just reset the column counter at the beginning of each line, increment the column counter from a PWM output, and increment the line counter when necessary.

Answer 3

Here are a few comments on the answers you got so far.

1. Do NOT use discrete (74 family) ICs. You will need a large breadboard and a lot of wires. It will take you months to put the SRAM interface together plus the proper timing for VGA sync pulses. I did it once in my lifetime long time ago but today it's not worth the effort.

2. Do NOT use serial bus to interfaces your video RAM. For goodness sake I2C runs at 100kbps which will take more then 5 seconds to update 64KB RAM. SPI is better as 25Mbps is quite common but a parallel bus is the way to go.

3. FPGA implementation is ok but most FPGAs need an additional config SRAM and the parts and eval boards tend to be pricey. I used FPGAs quite often but this project is too simple for an FPGA.

Therefore I would suggest a CPLD. Xilinx or Altera have a bunch of very cheap (< $10) CPLDs. I would use the PLCC packaged ones as you can easily find a socket that will convert it to a 100 mil spaced breadboard. You can buy a USB blaster programmer for Altera CPLDs for about $12.

Here's a good link to a page where you can get an idea how to start: http://hackaday.com/2011/05/05/dabbling-with-cpld-generated-vga-signals/#more-42268