The semester is wrapping up at Cornell, and that means it’s time for the final projects from [Bruce Land]’s lab. Every year we see some very cool projects, and this year is no exception. For their project, [Andre] and [Scott] implemented the audio processing unit (APU) of the Nintendo Entertainment System (NES). This is the classic chiptune sound that regaled a generation with 8-bit sounds that aren’t really eight bits, with the help of a 6502 CPU that isn’t really a 6502 CPU.
Unlike the contemporaneous MOS 6581 SID, which is basically an analog synthesizer on a chip, the APU in the NES is extraordinarily spartan. There are two pulse wave channels, a triangle wave channel, a random noise channel, and the very rarely used delta modulation channel (DMC) used to play very low quality audio samples. This is a re-implementation of the NES APU for a university lab; it is very understandable that [Andre] and [Scott] didn’t implement the rarely used DMC.
Everything about the circuitry of the NES is well documented, so [Andre] and [Scott] had a great wiki for their research. At the highest level, the APU runs on a 894kHz clock and controls three channels through dedicated registers. These outputs are fed through a mixer, which the guys scaled and combined into a 16-bit output played through a Wolfson WM8731 audio codec.
After implementing the NES APU, [Andre] and [Scott] added an SD card reader that can read the Nintendo Sound Format – the standard distribution format for NES chiptunes – and emulated a 6502 to control the registers. The result is a relatively simple device that plays NES chiptunes with amazing accuracy. The sound files on the project report sound like the real thing, but this is entirely emulated on modern hardware.
Usually, when you think of driving a VGA–in software or hardware–you think of using a frame buffer. The frame buffer is usually dual port RAM. One hardware or software process fills in the RAM and another process pulls the data out at the right rate and sends it to the VGA display (usually through a digital to analog converter).
[Connor Archard] and [Noah Levy] wanted to do some music processing with a DE2-115 FPGA board. To drive the VGA display, they took a novel approach. Instead of a frame buffer, they use the FPGA to compute each pixel’s data in real-time.
[Sam Miller], [Sahil Gupta], and [Mashrur Mohiuddin] worked together on a very fast LED matrix display for their final project in ECE 5760 at Cornell University.
They started, as any good engineering students, by finding a way to make their lives easier. [Sam] had built a 32×32 LED matrix for another class. So, they made three more and ended up with a larger and more impressive 64×64 LED display.
They claim their motivation was the love of music, but we have a suspicion that the true reason was the love all EEs share for unnaturally bright LEDs; just look at any appliance at night and try not be blinded.
The brains of the display is an Altera DE2-115 FPGA board. The code is all pure Verilog. The FFT and LED control are implemented in hardware on the FPGA; none of that Altera core stuff. To generate images and patterns they wrote a series of python scripts. But for us it’s the particle test shown in the video below that really turns our head. This system is capable of tracking and reacting to a lot of different elements on the fly why scanning the display at about 310 FPS. They have tested display scanning at twice that speed but some screen-wrap artifacts need to be worked out before that’s ready for prime time.
The team has promised to upload all the code to GitHub, but it will likely be a while before the success hangover blows over and they can approach the project again. You can view a video interview and samples of the visualizations in the videos after the break.
Thanks to their Professor, [Bruce Land], for submitting the tip! His students are always doing cool things. You can even watch some of his excellent courses online if you like: Here’s one on the AVR micro-controller.
We’ve seen a lot of Enigma builds here at Hackaday — the World War II era encryption machine captured our readers’ imaginations. But perhaps the more important machines to come out of cryptanalysis during that era were Turing’s electromechanical Bombe, because it cracked Enigma, and the vacuum-tube-based Colossus, because it is one of the first programmable electronic digital computers.
[Ben]’s build combines his explorations into old-school cryptanalysis with a practical learning project for FPGAs. If you’re interested in either of the above, give it a look. You can start out with his Python implementations of Colossus to get your foot in the door, and then move on to his GitHub repository for the FPGA nitty-gritty.
It’s also a cool example of a use for the XuLA2 FPGA board and its companion StickIt board that plug straight into a Raspberry Pi for programming and support. We haven’t seen many projects using these since we first heard about them in 2012. This VirtualBoy hack jumped out at us, however. It looks like a nice platform. Anyone else out there using one?
The student projects that come out of [Bruce Land]’s microcontroller- and FPGA-programming classes feature here a lot, simple because some of them are amazing, but also because each project is a building-block for another. And we hope they will be for you.
This time around, [Junyin Chen] and [Ziqi Yang] created a five-in-a-row video game that is controlled by a pointing finger. A camera, pointed at the screen, films the player’s hand and passes the VGA data to an FPGA. And that’s where things get interesting.
An algorithm in the FPGA detects skin color and, after a few opening and closing operations, comes up with a pretty good outline of the hand. The fingertip localization is pretty clever. They sum up the number of detected pixels in the X- and Y-axis, and since a point finger is long and thin, locate the tip because it’s going to have a maximum value in one axis and a minimum along the other. Sweet (although the player has to wear long sleeves to make it work perfectly).
How does the camera not pick up the game going on in the background? They use a black-and-white game field that the skin-color detection simply ignores. And the game itself runs in a Nios embedded processor in the FPGA. There’s a lot more detail on the project page, and of course there’s a demo video below.
We love to follow along with Prof. Land‘s classes. His video series is invaluable, and the course projects have been an inspiration.
There are reports of a Tetris movie with a sizable budget, and with it come a plentiful amount of questions about how that would work. Who would the characters be? What kind of lines would there be to clear? Whatever the answers, we can all still play the classic game in the meantime. And, thanks to some of the engineering students at Cornell, we could play it without using a controller.
This hack comes from [Bruce Land]’s FPGA design course. The group’s game uses a video camera which outputs a standard NTSC signal and also does some filtering to detect the user. From there, the user can move their hands to different regions of the screen, which controls the movement of the Tetris pieces. This information is sent across GPIO to another FPGA which uses that to then play the game.
This game is done entirely in hardware, making it rather unique. All game dynamics including block generation, movement, and boundary conditions are set in hardware and all of the skin recognition is done in hardware as well. Be sure to check out the video of the students playing the game, and if you’re really into hand gesture-driven fun, you aren’t just limited to Tetris, you can also drive a car.
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*.