Skip to main content
replaced http://electronics.stackexchange.com/ with https://electronics.stackexchange.com/
Source Link

I came across this postthis 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.

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.

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.

adjusted to my standard method of writing RAM (i.e. all caps) - forgot that's how I do it normally
Source Link
Clonkex
  • 237
  • 2
  • 10

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 ramRAM, 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 ramRAM, then just update the pixels as fast as it can. Then a custom circuit on the other side of the ramRAM, clocked at VGA-suitable speeds (~25MHz?) would read the pixels from the ramRAM (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.

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.

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.

Source Link
Clonkex
  • 237
  • 2
  • 10

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

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.