Some see gaming as the way to make AI work, by teaching computers how to play, and win, at games. This is perhaps one step on the way to welcoming our new gaming overlords: a group of Cornell students used an FPGA to win a computer cricket game. Specifically, they figured out how to use an FPGA to beat the tricky batting portion of the game in a neat way. They used an FPGA that directly samples the VGA output signal from the gaming computer, detecting the image of the meter that indicates the optimum batting time. Once it detects the optimum point to press the button, it triggers a hacked keyboard to press a button, whacking the ball to the boundary to score a six*.
We should all be familiar with TV ambient lighting systems such as Philips’ Ambilight, a ring of LED lights around the periphery of a TV that extend the colors at the edge of the screen to the surrounding lighting. [Shiva Rajagopal] was inspired by his tutor to look at the mechanics of generating a more accurate color representation from video frames, and produced a project using an FPGA to perform the task in real-time. It’s not an Ambilight clone, instead it is intended to produce as accurate a color representation as possible to give the impression of a TV being on for security purposes in an otherwise empty house.
The concern was that simply averaging the pixel color values would deliver a color, but would not necessarily deliver the same color that a human eye would perceive. He goes into detail about the difference between RGB and HSL color spaces, and arrives at an equation that gives an importance rating to each pixel taking into account its saturation and thus how much the human eye perceives it. As a result, he can derive his final overall color by looking at these important pixels rather than the too-dark or too-saturated pixels whose color the user’s eye will not register.
The whole project was produced on an Altera DE2-115 FPGA development and education board, and makes use of its NTSC and VGA decoding example code. All his code is available for your perusal in his appendices, and he’s produced a demo video shown here below the break.
Somehow or another, the Raspberry Pi has become a standardized form factor for single board computers. There are now Raspberry Pi-shaped objects that can do anything, and between the Odroid and bizarre Intel Atom-powered boards, everything you could ever want is now packaged into something that looks like a Raspberry Pi.
Except for one thing, of course, and that’s where [antti.lukats]’s entry for the 2016 Hackaday Prize comes in. He’s creating a version of the Raspberry Pi based on a chip that combines a fast ARM processor and an FPGA in one small package. It’s called the ZynqBerry and will, assuredly, become one of the best platforms to learn FPGA trickery on.
Xilinx’ Zynq comes with a dual-core ARM Cortex A9 running around 1GHZ, and from that fact alone should be about comparable to the original Raspberry Pi. Also inside the Zynq SoC is a very capable FPGA that [antti] is using to drive HDMI at 60hz, and can stream video from a Raspberry Pi camera to a display.
Last year for the Hackaday Prize, [antti] presented some very cool stuff, including a tiny FPGA development board no bigger than a DIP-8 chip. He’s hackaday.io’s resident FPGA wizard, and the ZynqBerry is the culmination of a lot of work over the past year or so. While it’s doubtful it will be as powerful as the latest Raspberry Pis and Pi clones, this is a phenomenal piece of work that puts an interesting twist on the usual FPGA development boards.
We have talked about a whole slew of logic and interconnect technologies including TTL, CMOS and assorted low voltage versions. All of these technologies have in common the fact that they are single-ended, i.e. the signal is measured as a “high” or “low” level above ground.
This is great for simple uses. But when you start talking about speed, distance, or both, the single ended solutions don’t look so good. To step in and carry the torch we have Differential Signalling. This is the “DS” in LVDS, just one of the common standards throughout industry. Let’s take a look at how differential signaling is different from single ended, and what that means for engineers and for users.
Single Ended
Single Ended: TTL, CMOS, LVTTL, Etc.
Single Ended and Sources of Noise
Collectively, standards like TTL, CMOS, and LVTTL are known as Single Ended technologies and they have in common some undesirable attributes, namely that ground noise directly affects the noise margin (the budget for how much noise is tolerable) as well as any induced noise measured to ground directly adds to the overall noise as well.
By making the voltage swing to greater voltages we can make the noise look smaller in proportion but at the expense of speed as it takes more time to make larger voltage swings, especially with the kind of capacitance and inductance we sometimes see.
Differential
Enter Differential Signaling where we use two conductor instead of one. A differential transmitter produces an inverted version of the signal and a non-inverted version and we measure the desired signal strictly between the two instead of to ground. Now ground noise doesn’t count (mostly) and noise induced onto both signal lines gets canceled as we only amplify the difference between the two, we do not amplify anything that is in common such as the noise.
I’ve worked with a lot of students who want to program computers. In particular, a lot of them want to program games. However, when they find out that after a few weeks of work they won’t be able to create the next version of Skyrim or Halo, they often get disillusioned and move on to other things. When I was a kid, if you could get a text-based Hi-Lo game running, you were a wizard, but clearly the bar is a lot higher than it used to be. Think of the “Karate Kid”–he had to do “wax on, wax off” before he could get to the cool stuff. Same goes for a lot of technical projects, programming or otherwise.
I talk to a lot of people who are interested in CPU design, and I think there’s quite a bit of the same problem here, as well. Today’s commercial CPUs are huge beasts, with sophisticated memory subsystems, instruction interpreters, and superscalar execution. That’s the Skyrim of CPU design. Maybe you should start with something simpler. Sure, you probably want to start learning Verilog or VHDL with even simpler projects. But the gulf between an FPGA PWM generator and a full-blown CPU is pretty daunting.
Retro gaming consoles exploded with the introduction of the Raspberry Pi and other similar single-board Linux computers. They all work the same way in that they emulate the original game console hardware with software. The game ROM is then dumped to a file and will play like the original. While this works just fine for the vast majority of us who want to get a dose of nostalgia as we chase the magic 1-up mushroom, gaming purists are not satisfied. They can tell the subtle differences between emulation and real hardware. And this is where our story begins.
Meet the Coleco Chameleon. What appears to be just another run-of-the-mill retro gaming console is not what you think. It has an FPGA core that replicates the actual hardware, to the delight of hardcore retro game enthusiasts around the world. To get it to the masses, they started an ambitious 2 million US dollar Indiegogo campaign, which has unfortunately come to a screeching halt.
Take a close look at the header image. That blue circuit board in there is nothing but an old PCI TV tuning card. To make matters worse, it also appears that their prototype system which was displayed at the Toy Fair in New York was just the guts of an SNES Jr stuffed into their shell.
This scam is clearly busted. However, the idea of reconstructing old gaming console hardware in an FPGA is a viable proposition, and there is demand for such a device from gaming enthusiasts. We can only hope that the owners of the Coleco Chameleon Kickstarter campaign meant well and slipped up trying to meet demand. If they can make a real piece of hardware, it would be welcomed.
What would you get it you mashed up an FPGA and an Arduino? An FPGA development board with far too few output pins? Or a board in the form-factor of Arduino that’s impossible to program?
The Alhambra board itself looks to be Arduino-compatible, with the horrible gap between the rows on the left-hand-side and all, so it will work with your existing shields. But they’ve also doubled them with pinheaders in a more hacker-friendly layout: SVG — signal, voltage, ground. This is great for attaching small, powered sensors using a three-wire cable like the one that you use for servos. (Hackaday.io has two Arduino clones using SVG pinouts: in SMT and DIP formats.)
The iCE40 FPGA has 144 pins, so you’re probably asking yourself where they all end up, and frankly, so are we. There are eight user LEDs on the board, plus the 28 I/O pins that end in pinheaders. That leaves around a hundred potential I/Os unaccounted-for. One of the main attractions of FPGAs in our book is the tremendous availability of fast I/Os. Still, it’s more I/O than you get on a plain-vanilla Arduino, so we’re not complaining too loudly. Sometimes simplicity is a virtue. Everything’s up on GitHub, but not yet ported to KiCad, so you can tweak the hardware if you’ve got a copy of Altium.
We’ve been seeing FPGA projects popping up all over, and with the open-source toolchains making them more accessible, we wonder if they will get mainstreamed; the lure of reconfigurable hardware is just so strong. Putting an FPGA into an Arduino-compatible form-factor and backing it with an open GUI is an interesting idea. This project is clearly in its very early stages, but we can’t wait to see how it shakes out. If anyone gets their hands on these boards, let us know, OK?
enthusiasts around the world. To get it to the masses, they started an ambitious 2 million US dollar Indiegogo campaign, which has unfortunately come to a 
