With the wide availability of Raspberry Pi hardware and pre-baked Linux distros with emulators ready to go, making a retro handheld is easier than ever. Emulation isn’t the only way to go about playing old games however. [Wenting Zhang] decided to instead recreate the Nintendo Game Boy in Verilog, and has documented the effort.
The project runs on a Spartan 6 FPGA. [Wenting] first developed the hardware to use a DualShock controller for input, and output video to a regular LCD monitor. However, work is now underway to produce a handheld VerilogBoy. This will feature a 320×320 LCD screen, with pixels being quadrupled from the original Game Boy 160×144 resolution, with some pixels to spare. [Wenting] is also looking at porting the code to some Pano Logic units, which we’ve discussed before. The thin clients pack FPGA hardware and lots of IO ports that make them perfect for such a project.
Code is available on Github for the curious tinkerers out there. While there are easier ways to play old handheld games, the amount of learning value of such a project should not be underestimated. We’ve seen FPGAs used for other Nintendo hijinx, too – like this NES cart that packs some serious muscle. Video after the break.
Continue reading “Game Boy Recreated in Verilog”
Reinforcement learning has been a hot-button area of research into artificial intelligence. This is a method where software agents make decisions and refine these over time based on analyzing resulting outcomes. [Kamil Rocki] had been exploring this field, but needed some more powerful tools. As it turned out, a cluster of emulated Game Boys running at a billion FPS was just the ticket.
The trick to efficient development of reinforcement learning systems is to be able to run things quickly. If it takes an AI one thousand attempts to clear level 1 of Super Mario Bros., you’d better hope you’re not running that in real time. [Kamil] started by coding a Game Boy emulator in C. By then implementing it in Verilog, [Kamil] was able to create a cluster of emulated Game Boys that enabled games to be run at breakneck speed, greatly speeding the training and development process.
[Kamil] goes into detail about how the work came to revolve around the Game Boy platform. After initial work with the Atari 2600, which is somewhat of a defacto standard in RL circles, [Kamil] began to explore further. It was desired to have an environment with a well-documented CPU, a simple display to cut down on the preprocessing required, and a wide selection of games.
The goal of the project is to allow [Kamil] to explore the transfer of knowledge from one game to another in RL systems. The aim is to determine whether for an AI, skills at Metroid can help in Prince of Persia, for example. This is arguably true for human players, but it remains to be seen if this can be carried over for RL systems.
It’s rather advanced work, on both a hardware emulation level and in terms of AI research. Similar work has been done, training a computer to play Super Mario through monitoring score and world values. We can’t wait to see where this research leads in years to come.
Classic battles: PC vs Mac, Emacs vs Vi, Tastes Great vs Less Filling, and certainly one that we debate around the Hackaday watercooler: command line or IDE? There’s something to be said for using good old command line tools, and even if you like to configure your favorite editor to be nearly an IDE, at least it is one you are familiar with and presumably leverage over several different uses.
Most commercial FPGA tools come with a heavy-weight IDE. The open source tools for Lattice (IceStorm) typically is driven by the command line or a makefile. Until now. [Rochus-Keller] released VerilogCreator which is a plugin for QtCreator.
We were impressed because as IDEs go, QtCreator is both useful and lightweight, two things that don’t go together for many similar tools. [FPGAwars] has had an IDE based on Atom (apio-ide) although it hasn’t been updated in nearly a year. IceStudio sees more updates, of course, but it isn’t so much an IDE as a GUI-based code builder.
[Rochus-Keller] says there’s more to come. However, even at this early stage the IDE does syntax coloring, tooltips, inline messages, and can analyze source code allowing you to cross-reference symbols as you’d expect. There are configurations for Icarus to do simulations or you can use Verilator or Yosys — the synthesizer behind IceStorm. It appears it can also interact with Tcl-based workflows like those used by most FPGA vendor IDEs.
There’s quite a bit still on the to-do list, so we are excited to see where this is going. QtCreator isn’t hard to learn and it doesn’t’ feel as bloated as some of the big IDEs like Eclipse. If you want a quick introduction to QtCreator, we did that already. If you want to draw boxes instead of writing Verilog directly, try IceStudio.
If you have a thing for old game development — things like the Atari 2600 or similar period arcade games — you might already know about the 8bitworkshop IDE. There you can develop code in your browser for those platforms. In a recent blog post, the site announced you can now also do FPGA development in the IDE.
According to the site:
Most computers are fast enough to render a game at 60 Hz, which requires simulating Verilog at almost 5 million ticks per second.
To activate Verilog, you need to select the hamburger menu to the top left, select Platform, and then under Hardware, check Verilog. What makes this different from, say, EDA Playground, is that the output can be waveforms or the output to a virtual TV monitor. For example, here’s one of the examples:
The Verilog code is generating horizontal and vertical sync along with an RGB output and the results appear on the monitor to the right. There is a handle at the bottom of the screen. If you drag it up you will see the logic analyzer output. Drag it down and you’ll see the screen again. The examples include an 8-bit and 16-bit CPU, and example games that can even read the mouse.
Honestly, we don’t think anyone would suggest using Verilog to write in-browser games. That isn’t really the point here. However, if you are trying to learn Verilog, it is great fun to be able to produce something other than just abstract waveforms from simulation. The only downside is that to move to a real piece of hardware, you’d need to duplicate the interfaces provided by the IDE. That would not be very hard, and — of course — if you are just using it to learn you can try a different project for the real world.
If you need help getting going in Verilog, we have a series of boot camps that can help. Those tutorials use EDA Playground, but they’d probably work here, too. If you try them in the IDE, be sure to let us know your experience.
If you’ve ever wanted to sit at the console of the machine that started the revolution in interactive computing, your options are extremely limited. Of the 53 PDP-1 machines that Digital Equipment Corporation made, only three are known to still exist, and just one machine is still in working order at the Computer History Museum. So a rousing game of Spacewar! on the original hardware is probably not something to put on your bucket list.
But thanks to [Hrvoje], there’s now an FPGA emulation of the PDP-1 that lets you play the granddaddy of all video games without breaking into the CHM. The project was started simply to give [Hrvoje] a sandbox for learning FPGAs and Verilog, but apparently went much further than that. The emulation features the complete PDP-1 instruction set, 4kB of core memory, and representations of the original paper tape reader, teletype, operator’s console, and the classic Type 30 CRT. All the hardware is displayed on a standard HDMI monitor, but it’s the CRT implementation that really sells this. The original Type 30 monitor used a CRT from a radar set, and had long-persistence phosphors that gave the display a very distinctive look. [Hrvoje] replicated that by storing each pixel as three values (X, Y, and brightness) in a circle of four chained shift registers. As the pixels move through the shift registers, the brightness value is decreased so it slowly fades. [Hrvoje] thinks it doesn’t look quite right, but we’ll respectfully disagree on that point.
We’ve argued before that the PDP-1 is the machine that started hacker culture, and we think this project is a fitting tribute to the machine as we enter the year in which it will turn sixty. Having the chance to play with it through this emulation is just icing on its birthday cake.
Continue reading “FPGA Emulates a PDP-1, Breathes New Life Into Classic Video Game”
If you want to use FPGAs, you’ll almost always use an HDL like Verilog or VHDL. These are layers of abstraction just like using, say, a C compiler is to machine language or assembly code. There are other challengers to the throne such as SpinalHDL which have small but enthusiastic followings. [Tom] has a post about how the VexRISC-V CPU leverages SpinalHDL to make an extremely flexible system that is as efficient as plain Verilog. He says the example really shows off why you should be using SpinaHDL.
Like a conventional programming language, it is easy to find niche languages that will attract a little attention and either take off (say, C++, Java, or Rust) or just sort of fade away. The problem is you can’t ever tell which ones are going to become major and which are just flashes in the pan. Is SpinalHDL the next big thing? We don’t know.
Continue reading “VexRISC-V Exposed”
While desktop computers have tons of computing power and storage, some small CPUs don’t have a lot of space to store things. What’s more is some CPUs don’t do multiplication and division very well. Same can be said for FPGAs. So suppose we are going to grab a bunch of three-digit decimal numbers from, say, a serial port. We want to store as many as we can, and we don’t want to do a lot of math because we can’t, it is slow, or perhaps it keeps our processor awake longer and we want to sleep to conserve power. We want a way to pack the numbers as close to the theoretical maximum as we can but with little or no math.
The simple approach is to store the numbers as ASCII. Great for processing since they are probably in ASCII already. If they aren’t, you just add 30 hex to each digit and you are done. That’s awful for storage space, though, since we can store 999 in 10 bits if it were binary and now we are using 24 bits! Storing in binary isn’t a good option, if you play by our rules, by the way. You need to multiply by 10 and 100 (or 10 twice) to get the encoding. Granted, you can change that to two shifts and an add (8x+2x=10x) but there’s no easy way to do the division you’ll have to do for the decode.
Of course, there’s no reason we can’t just store decimal digits. That’s call binary coded decimal or BCD and that has some advantages, too. It is pretty easy to do math on BCD numbers and you don’t get rounding problems. Some CPUs even have specific instructions for BCD manipulation. However, three digits will require 12 bits. That’s better than 24, we agree. But it isn’t as good as that theoretical maximum. After all, if you think about it, you could store 16 distinct codes in 4 bits, and we are storing only 10, so that 6 positions lost. Multiply that by 3 and you are wasting 18 codes.
But there is a way to hit that ten-bit target without doing any math. Its called DPD or densely packed decimal. You can convert three decimal digits into ten bits and then back again with no real math at all. You could implement it with a small lookup table or just do some very simple multiplexer-style logic which means it is cheap and easy to implement in software or onboard an FPGA.
Continue reading “Packing Decimal Numbers Easily”