SDRAM controller for low-end FPGAs

There are very few ‘recent’ FPGAs out there that can be easily soldered. Due to their important number of IOs, they usually come in Ball Grid Array (BGA) packages. The Xilinx Spartan 6 LX9, a TQFP144 FPGA (having pins with a 0.5mm pitch) is one of the few exceptions that can be used to make low end development boards. However, it doesn’t have a lot of logic and memory resources or an on-chip Memory Control Block implemented in the silicon. Therefore, [Michael] designed an SDRAM controller with a small footprint for it.

Writing an SDRAM controller from scratch isn’t for the fainthearted – first of all you really have to know how SDRAM  works (RAS, CAS, precharges, refresh cycles), and because of the high speed and accurate timing required you also have to learn some of the finer points of FPGA off-chip interfacing. In addition, most publicly available open cores are very complex – for example just the RTL core of the sdr_ctrl controller on adds up to over 2,700 lines of Verilog. Even if it is not an accurate comparison metric, [Michael]’s controller is only 500 lines long.

Making vector arcade games with an FPGA


While we’re sure most Hackaday readers were raised by arcade games featuring sprites, pixels, and other shiny brightly colored squares, this was not always so. Many classic arcade games – Lunar Lander, Gravitar, and Asteroids in particular – used vector displays. Instead of drawing individual pixels, these games functioned more like an oscilloscope, drawing lines. When [Todd] and [Andrew] got their hands on a monitor from an old Asteroids cabinet, they knew what they had to do: build their own vector arcade game.

The guys made their own DAC and Amplifier board that plugs right in to a Nexys2 FPGA dev board. This was after they tested out some 3D drawing code with a gnarly handmade R2R DAC they used to draw and rotate a cube on an oscilloscope screen.

Not only did the guys build a vector video card, they also connected the FPGA’s VGA out to a monochrome monitor for an in-game HUD. Awesome work that blows away anything available in the golden days of vector arcade games. It’s a beautiful piece of engineering that certainly deserves its own cabinet.

Video of the game available below.

Continue reading “Making vector arcade games with an FPGA”

Camera-based touchscreen input via an FPGA


[Chonggang Li] wrote in to share a link to the final project he and [Ran Hu] built for their embedded systems class. It’s called Piano Hero and uses an FPGA to implement a camera-based touch screen system.

All of the hardware used in the project is shown above. The monitor acts as the keyboard, using an image produced by the FPGA board to mark the locations of each virtual key. It uses a regular VGA monitor so they needed to find some way to monitor touch inputs. The solution uses a camera mounted above the screen at an obtuse angle. That is to say, the screen is tilted back just a bit which allows the images on it to be seen by the camera. The FPGA board processes the incoming image, registering a key press when your finger passes between the monitor and the camera. This technique limits the input to just a single row of keys.

This should be much simpler than using a CCD scanner sensor, but that one can track two-dimensions of touch input.

Continue reading “Camera-based touchscreen input via an FPGA”

FPGA plays Mario like a champ


This isn’t an FPGA emulating Mario Bros., it’s an FPGA playing the game by analyzing the video and sending controller commands. It’s a final project for an engineering course. The ECE5760 Advanced FPGA course over at Cornell University that always provides entertainment for us every time the final projects are due.

Developed by team members [Jeremy Blum], [Jason Wright], and [Sima Mitra], the video parsing is a hack. To get things working they converted the NES’s 240p video signal to VGA. This resulted in a rolling frame show in the demo video. It also messes with the aspect ratio and causes a few other headaches but the FPGA still manages to interpret the image correctly.

Look closely at the screen capture above and you’ll see some stuff that shouldn’t be there. The team developed a set of tests used to determine obstacles in Mario’s way. The red lines signify blocks he will have to jump over. This also works for pits that he needs to avoid, with a different set of tests to detect moving enemies. Once it knows what to do the FPGA emulates the controller signals necessary, pushing them to the vintage gaming console to see him safely to the end of the first level.

We think this is more hard-core than some other autonomous Mario playing hacks just because it patches into the original console hardware instead of using an emulator.

Continue reading “FPGA plays Mario like a champ”

HDMI color processing board used as an FPGA dev board to mine Bitcoins


The blue board seen above is the guts of a product called the eeColor Color3. It was designed to act as a pass-through between your television and HDMI source device. It boasts the ability to adjust the color saturation to suit any viewing conditions. But [Taylor Killian] could care less about what the thing was made for, he tore it open and used the FPGA inside for his own purposes.

The obvious problem with this compared to a proper dev board is that the pins are not all broken out in a user-friendly way. But he got his hands on it for free after a mail-in-rebate (you might find one online for less than $10 if you’re lucky) and it’s got an Altera Cyclone IV chip with 30k (EP4CE30F23C6N) gates in it so he’s not complaining. The first project he took on with his new toy was to load up an open source Bitcoin mining program. The image above shows it grinding away at 15 megahashes per second while consuming only 2.5 watts. Not bad. Now he just needs to make a modular rack to hold a mining farm.

Playing Meat Boy on an FPGA


We usually look at these FPGA University projects and think how much fun it must have been to get credit for the work. But in this case we can’t image the grind it must have been to implement the game mechanics of Meat Boy in an FPGA. See how well it came out in the clip after the break.

Remember that with an FPGA you’re basically building hardware devices by using code. The Reddit discussion of the project sheds some light on where to start (and even shares the source code). The Altera DE2 is pushing the game to a monitor using SXGA at 60Hz. The map is laid out as a collection of 32×32 tiles, each represented by 2 bits in memory. [SkipToThe3nd] does go into detail about how the physics work but we can’t even begin to paraphrase that part of the discussion.

The game being cloned here is Meat Boy, the Flash game predecessor to Super Meat Boy. If you’ve never heard of the title we’d suggest watching Indie Game: The Moviea documentary which follows several independent game developers as they try to get their titles to market.

Continue reading “Playing Meat Boy on an FPGA”

Building new, weird CPUs in FPGAs


The popularization of FPGAs for the hobbyist market means a lot more than custom LED controllers and clones of classic computer systems. FPGAs are also a great tool to experiment with computer architecture, creating new, weird, CPUs that don’t abide by the conventions the industry has used for 40 years. [Victor] is designing a new CPU that challenges the conventions of how to access different memory locations, and in the process even came up with a bit of example code that runs on an ARM microcontroller.

Most of the time, the machine code running on your desktop or laptop isn’t that interesting; it’s just long strings of instructions to be processed linearly. The magic of a computer comes through comparisons, an if statement or a jump in code, where the CPU can run one of two pieces of code, depending on a value in a register. There is the problem of reach, though: if a piece of code makes a direct call to another piece of code, the address of the new code must fit within an instruction. On an ARM processor, only 24 bits are available to encode the address, meaning a jump in code can only go 16 MB on either side of its call. Going any further requires more instructions, and the performance hit that comes along with that.

[Victor] decided a solution to this problem would be to create a bit of circuitry that would be a sliding window to store address locations. Instead of storing the literal address for jumps in code, every branch in the code is stored as a location relative to whatever is in the program counter. The result is an easy way to JMP to code very far away in memory, with less of a performance hit.

There’s an implementation for this sliding window token thing [Victor] whipped up for NXP’s ARM Cortex M3 microprocessor, and he’ll be working on an implementation of this concept in a new CPU over on his git.