I’m always on the lookout for a quality addition to my lab that would respect my strict budget. Recently, I’ve found myself pushing the Hertz barrier with every other project I do and hence desperately wanted a high bandwidth scope. Unfortunately, only recently have 70 MHz to 100 MHz become really affordable, whilst a new quad channel oscilloscope in the 500 MHz to 1 GHz range still costs a fortune to acquire. My only option was to find an absolute miracle in the form of an old high bandwidth scope.
It seemed the Gods of Hand Me Down electronics were smiling upon me when I found this dumpster destined HP 54542C. It appeared to be in fairy good shape and was the Top Dog in its day. But something had to be broken right? Sure enough, the screen was clearly faulty and illegible. Want to know how I fixed it? Four letters: FPGA.
The Gameboy line of handheld systems from Nintendo have been wildly popular, but lack one major thing – a video output. This can be troublesome if you’d like to view the games on a bigger screen, for more comfortable gaming sessions or detail work like producing chiptunes. One option is to use the Gameboy Player for the Gamecube, however that system’s age means you’re out of luck if you want a crisp, clear picture on a modern digital display. Wouldn’t it be great if you could get HDMI output from a Gameboy Advance Instead?
A family resemblance?
When it comes to working with video signals, FPGAs can’t be beat. [Stephen] leverages an FPGA in this project to read the GBA’s video signals and convert them to the modern digital format. Unfortunately, it’s not a seamless install – limited space means the GBA’s screen must be entirely removed, replaced with the adapter in a manner resembling the terrifying Facehugger.
Packaging aside, the output from the device is nothing short of stunning – the graphics are absolutely crystal clear when displayed on a modern HDMI television. This is because the FPGA is capturing the exact digital output from the GBA, and piping it out as HDMI – there’s no analog fuzziness, conversions or noise to spoil the image. Output is a tasty 1280×720, upscaled from the GBA’s original resolution. For more details, check out the forum thread where [Stephen] runs through the build.
The only thing missing is details – we’d love to know more about the exact hardware used, and any trials and tribulations during the build! As far as we can tell, the build doesn’t stop at just video – a SNES controller is used instead of the original buttons, and we have a feeling sound is being passed over the HDMI channel as well sound is piped to the TV from the GBA’s headphone port.
It’s great to see these projects for old hardware come out – modern hardware has the muscle to achieve things previously unthinkable on retro consoles. We’ve seen similar projects before – like adding VGA to an original Game Boy.
The human auditory system is a complex and wonderful thing. One of its most useful features is the ability to estimate the range and direction of sound sources – think of the way people instinctively turn when hearing a sudden loud noise. A team of students have leveraged this innate ability to produce a game of tag based around nothing but sound.
The game runs on two FPGAs, which handle the processing and communication required. The chaser is given a screen upon which they can see their own location and that of their prey. The target has no vision at all, and must rely on the sounds in their stereo headphones to detect the location of the chaser and evade them as long as possible.
The project documentation goes into great detail about the specifics of the implementation. The game relies on the use of the Head Related Transfer Function – a function related to how the ear picks up sounds relative to their position. This allows the FPGA to simulate the chaser’s footsteps, and feed the audio to the target who perceives the chaser’s position purely by sound.
It’s a great example of a gameplay mechanic that we’d love to see developed further. The concept of trying to find one’s way around by hearing alone is one which we think holds a lot of promise.
With plenty of processing power under the hood, FPGAs are a great choice for complex audio projects. A great project to try might be decoding MP3s.
[Bruce Land] is one of those rare individuals who has his own Hackaday tag. He and his students at Cornell have produced many projects over the years that have appeared on these pages, lately with FPGA-related projects. If you only know [Land] from projects, you are missing out. He posts lectures from many of his classes and recently added a series of new lectures about developing with a DE1 System on Chip (SoC) using an Altera Cyclone FPGA using Verilog. You can catch the ten lectures on YouTube.
The class material is different for 2017, so the content is fresh and relevant. The DE1-SOC has a dual ARM processor and boots Linux from an SD card. There are several labs and quite a bit of background material. The first lab involves driving a VGA monitor. Another is a hardware solver for ordinary differential equations.
Cornell students [Erissa Irani], [Albert Xu], and [Sophia Yan] built a FPGA wave equation music synth as the final project for [Bruce Land]’s ECE 5760 class.
The team used the Kaplus-Strong string synthesis method to design a trio of four-stringed instruments to be played by the Cyclone V FPGA. A C program running on the development board’s ARM 9 HPS serves as music sequencer, controlling tempo and telling the FPGA which note to play.
The students created versions of four songs, including “Colors of the Wind” from the Pocahantas soundtrack, “Far Above Cayuga’s Waters” (Cornell’s alma mater) and John Legend’s “All of Me”. A simple GUI allows the viewer to select a song and to choose which instrument or instruments to play, providing multiple variations for each song.
The Internet is full of low-speed logic analyzer designs that use a CPU. There are also quite a few FPGA-based designs. Both have advantages and disadvantages. FPGAs are fast and can handle lots of data at once. But CPUs often have more memory and it is simpler to perform I/O back to, say, a host computer. [Mohammad] sidestepped the choice. He built a logic analyzer that resides partly on an FPGA and partly on an ARM processor.
In fact, his rationale was to replace built-in FPGA logic analyzers like Chipscope and SignalTap. These are made to coexist with your FPGA design, but [Mohammad] found they had limitations. They also eat up die space you might want for your own design, so by necessity, they probably don’t have much memory.
The system can capture and display 32-bit signals on a 640×480 VGA monitor in real-time. The system also has a USB mouse interface which is used to zoom and scroll the display. You can see a video of the thing in operation, below.
Last time I looked at a simple 16-bit RISC processor aimed at students. It needed a little help on documentation and had a missing file, but I managed to get it to simulate using a free online tool called EDA Playground. This time, I’ll take you through the code details and how to run the simulation.
You’ll want to refer to the previous post if you didn’t read it already. The diagrams and tables give a high-level overview that will help you understand the files discussed in this post.
If you wanted to actually program this on a real FPGA, you’d have a little work to do. The memory and register initialization is done in a way that works fine for simulation, but wouldn’t work on a real FPGA. Anyway, let’s get started!
