FPGA Hack Becomes An Atari Game Genie

The Game Genie is a classic of the early 90s video game scene. It’s how you would have beaten the Ninja Turtles game, and it’s why the connector in your NES doesn’t work as it should. They never made a Game Genie for the Atari 2600, though, because by the time the Game Genie was released, the Atari was languishing on the bottom shelves of Toys R Us. Now though, we have FPGAs and development tools. We can build our own. That’s exactly what [Andy] did, and his Game Genie for the 2600 works as well as any commercial product you’d find for this beleaguered console.

To understand how to build a Game Genie for an Atari, you first have to understand how a Game Genie works. The hacks for a Game Genie work by replacing a single byte in the ROM of a game. If your lives are stored at memory location 0xDEAD for example, you would just change that byte from 3 (the default) to 255 (because that’s infinite, or something). Combine this with 6-letter and 8-letter codes that denote which byte to change and what to change it to, and you have a Game Genie.

This build began by setting up a DE0 Nano FPGA development board to connect to an Atari 2600 cartridge. Yes, there are voltage level differences, but this can be handled with a few pin assignments. Then, it’s just a matter of writing Verilog to pass all the data from one set of address and data pins to another set of address and data pins. The FPGA becomes a man-in-the-middle attack, if you will.

With the FPGA serving as a pass-through for the connections on the cartridge, it’s a simple matter to hard-code cheats into the device. For the example, [Andy] found the code for a game, figured out where the color of the fireballs were defined as red, and changed the color to blue. It worked, and all was right with the world. The work was then continued to create a user interface to enter three cheat codes, and finally wrapped up in a 3D printed enclosure. Sure, the Atari Game Genie works with ribbon cables, but it wouldn’t be that much more work to create a similar project with Lock-On™ technology. You can check out the entire build video below, or get the info over on Element14

Continue reading “FPGA Hack Becomes An Atari Game Genie”

FPGA used VHDL for Fractals

Over on GitHub, [ttsiodras] wanted to learn VHDL. So he started with an algorithm to do Mandelbrot sets and moved it to an FPGA. Because of the speed, he was able to accomplish real-time zooming. You can see a video of the results, below.

The FPGA board is a ZestSC1 that has a relatively old Xilinx Spartan 3 chip onboard. Still, it is plenty powerful enough for a task like this.

Continue reading “FPGA used VHDL for Fractals”

VexRISC-V Exposed

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”

Racing the Beam on a Thin Client, in FPGAs

A few years back, a company by the name of Pano Logic launched a line of FPGA-based thin clients. Sadly, the market didn’t eventuate, and the majority of this stock ended up on eBay, to eventually be snapped up by eager hackers. [Tom] is one of those very hackers, and decided to try some raytracing experiments with the hardware.

[Tom] has one of the earlier Pano Logic clients, with VGA output and a Xilinx Spartan-3E 1600 FPGA under the hood. Due to limited RAM in the FPGA, and wanting to avoid coding a custom DRAM controller for the memory on the board, there just wasn’t room for a framebuffer. Instead, it was decided that the raytracer would instead “race the beam” – calculating each pixel on the fly, beating the monitor’s refresh rate.

This approach means that resource management is key, and [Tom] notes that even seemingly minor changes to the raytracing environment require inordinately large increases in calculation. Simply adding a shadow and directional light increased core logic utilisation from 66% to 92%!

While the project may not be scalable, [Tom] was able to implement the classic reflective sphere, which bounces upon a checkered plane and even added some camera motion to liven things up through an onboard CPU core. It’s a real nuts-and-bolts walkthrough of how to work with limited resources on an FPGA platform. Code is available on Github if you fancy taking a further peek under the hood.

If you’re new to FPGAs yourself, why not check out our FPGA bootcamp?

Getting Started with Free ARM Cores on Xilinx

We reported earlier about Xilinx offering free-to-use ARM Cortex M1 and M3 cores. [Adam Taylor] posted his experiences getting things working and there’s also a video done by [Geek Til It Hertz] based on the material that you can see in the second video, below.

The post covers using the Arty A35T or Arty S50 FPGA boards (based on Artix FPGAs) and the Xilinx Vivado software. Although Vivado will allow you to do conventional FPGA development, it also can work to compose function blocks to produce CPUs and that’s really what’s going on here.

Continue reading “Getting Started with Free ARM Cores on Xilinx”

MIPI CSI-2 Implementation In FPGAs

[Adam Taylor] always has interesting FPGA posts and his latest is no exception. He wanted to use a Zynq for image processing. Makes sense. You can do the high-speed parallel parts in the FPGA fabric and do higher-level processing on the built-in CPU. The problem is, of course, you need to get the video data into the system. [Adam] elected to use the Mobile Industry Processor Interface (MIPI) Camera Serial Interface Issue 2 (CSI-2).

This high-speed serial interface is optimized for data flowing in one direction. The camera, or the master, sends a number of bits (at least one) serially with one clock. To increase speed, data transfers on both rising and falling clock edges. The slave also has a pretty standard I2C master to send commands to the camera which, for the purposes of I2C, is the slave.

Continue reading “MIPI CSI-2 Implementation In FPGAs”

RISC-V CPU Gets A Peripheral

One of the ways people use FPGAs is to have part of the FPGA fabric hold a CPU. That makes sense because CPUs are good at some jobs that are hard to do with an FPGA, and vice versa. Now that the RISC-V architecture is available it makes sense that it can be used as an FPGA-based CPU. [Clifford Wolf] created PicoSOC — a RISC-V CPU made to work as a SOC or System on Chip with a Lattice 8K evaluation board. [Mattvenn] ported that over to a TinyFPGA board that also contains a Lattice FPGA and shows an example of interfacing it with a WS2812 intelligent LED peripheral. You can see a video about the project, below.

True to the open source nature of the RISC-V, the project uses the open source Icestorm toolchain which we’ve talked about many times before. [Matt] thoughtfully provided the firmware precompiled so you don’t have to install gcc for the RISC-V unless you want to write you own software. Which, of course, you will.

Continue reading “RISC-V CPU Gets A Peripheral”