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?
Fortunately, the ICEZUM Alhambra looks like it’s avoided these pitfalls, at least for the most part. It’s based on the Lattice iCE40 FPGA, which we’ve covered previously a number of times because of its cheap development boards and open-source development flow. Indeed, we were wondering what the BQ folks were up to when they were working on an easy-to-use GUI for the FPGA family. Now we know — it’s the support software for an FPGA “Arduino”.
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?
Thanks [RS] for the tip!
At the Lifelong Learning Robotics Laboratory at the Erasmo Da Rotterdam in Italy, robots are (not surprisingly) used to teach all of the fundamentals of robotics. [Alessandro Rossetti] and the students at the lab have been at it for years now, and have finally finished their fifth generation of a robot called Nessie. The big idea is to help teach fundamentals of programming and electronics by building something that actually uses these principles.
The robot is largely 3D printed and uses an FPGA to interact with the physical world through a set of motors and sensors. The robot also uses a Raspberry Pi to hold the robot’s framework. The robot manages the sensors in hardware with readers attached to the CPU AXI bus. The CPU reads their values from memory space, though, so the robot is reported to be quite quick.
The lab is hoping to take their robot to a robotics competition in Bari, Italy. We hope that they perform well there, since we are big fans of any robot that’s designed to teach anyone about robotics and programming. After all, there are robots that help teach STEM in Africa, robots that teach teen girls about robots, and robots that teach everyone.
If you’ve ever worked with FPGAs, you’ve dealt with the massive IDEs provided by the vendors. Xilinx’s ISE takes about 6 gigabytes, and Altera’s Quartus clocks in at over 10 gigs. That’s a lot of downloading proprietary software just to make an LED blink.
[Jesús Arroyo]’s Icestudio is a new, graphical tool that lets you generate Verilog code from block diagrams and run it on the Lattice Semi iCEstick development board. A drag and drop interface lets you connect IOs, logic gates, dividers, and other elements. Once your block diagram is ready, a single button press downloads the code to the iCEstick.
Under the hood, Icestudio uses IceStorm, which we’ve discussed on HaD in the past, including this great talk by [Clifford], Icestorm’s lead. For the GUI, Icestudio uses nw.js, which spits out JSON based on the block diagram. This JSON is converted into a Verilog file and a PCF file. The Verilog is used to create the logic on the FPGA, and the PCF is used to define the pin configuration for the device. Clicking on selected modules reveals the generated Verilog if you want to know what’s actually going on.
It’s experimental, but this looks like a neat way to get started on FPGAs without learning a new language or downloading many gigs of toolchains. We’re hoping Icestudio continues to grow into a useful tool for education and FPGA development. A demo follows after the break.
[Thanks to Nils for the tip!]
Continue reading “Icestudio: An Open Source Graphical FPGA Tool”
Sorting. It’s a classic problem that’s been studied for decades, and it’s a great first step towards “thinking algorithmically.” Over the years, a handful of sorting algorithms have emerged, each characterizable by it’s asymptotic order, a measure of how much longer an algorithm takes as the problem size gets bigger. While all sorting algorithms take longer to complete the more elements that must be sorted, some are slower than others.
For a sorter like bubble sort, the time grows quadradically longer for a linear increase in the number of inputs; it’s of order
O(N²).With a faster sorter like merge-sort, which is
O(N*log(N)), the time required grows far less quickly as the problem size gets bigger. Since sorting is a bit old-hat among many folks here, and since
O(N*log(N)) seems to be the generally-accepted baseline for top speed with a single core, I thought I’d pop the question: can we go faster?
In short — yes, we can! In fact, I’ll claim that we can sort in linear time, i.e a running time of
O(N). There’s a catch, though: to achieve linear time, we’ll need to build some custom hardware to help us out. In this post, I’ll unfold the problem of sorting in parallel, and then I”ll take us through a linear-time solution that we can synthesize at home on an FPGA.
Need to cut to the chase? Check out the full solution implemented in SystemVerilog on GitHub. I’ve wrapped it inside an SPI communication layer so that we can play with it using an everyday microcontroller.
To understand how it works, join us as we embark on an adventure in designing algorithms for hardware. If you’re used to thinking of programming in a stepwise fashion for a CPU, it’s time to get out your thinking cap!
Continue reading “Sort Faster with FPGAs”
The Manchester Baby seems simple today. A 32-bit machine with 32 words of storage. It wasn’t meant to be a computer, though, but a test bed for the new Williams tube storage device. However, in 1948, it executed stored programs at about 1,100 instructions per second. The success of the machine led to a series of computers at Manchester University and finally to the first commercially available computer, the Ferranti Mark I.
[Dave] is lucky enough to volunteer to demonstrate the Baby replica at Machester’s Museum of Science Industry. He wanted his own Baby, so he used a Xilinx FPGA board to build a replica Baby named BabyBaby. Although it runs at the same speed as the original, it is–mercifully–much smaller than the real machine.
Continue reading “BabyBaby: A 1948 Computer on an FPGA”
When [iliasam] needed an Ethernet connection, he decided to see how much of the network interface he could put in the FPGA logic. Turns out that for 10 Base-T, he managed to get quite a bit inside the FPGA. His original post is in Russian, but automatic translation makes a passable attempt at converting to English.
This is a classic trade off all FPGA designers face: how much external logic do you use for a particular design. For example, do you add memory to the PCB, or use FPGA resources as memory? Each has its advantages and disadvantages (that’s why it is a trade off). However, if you are trying to keep things cheap, slashing external circuitry is often the way to go.
Continue reading “FPGA to Ethernet Direct”