Raspberry Pi-Based Game Boy Emulator

March 12, 2017 by Brian Benchoff 14 Comments

The most popular use for a Raspberry Pi, by far, is video game emulation. We see this in many, many forms from 3D printed Raspberry Pi cases resembling the original Nintendo Entertainment System to 3D printed Raspberry Pi cases resembling Super Nintendos. There’s a lot of variety out there for Raspberry Pi emulation, but [moosepr] is taking it to the next level. He’s building the smallest Pi emulation build we’ve ever seen.

This build is based on the Pi Zero and a 2.2″ (0.56 dm) ili9341 TFT display. This display has a resolution of 240×320 pixels, which is close enough to the resolution of the systems the Pi Zero can emulate. The Pi Zero and display are attached to a beautiful purple breakout board (shared on OSH Park) along with a few 5-way nav switches, a charger for a Lipo battery, and a few other bits and bobs.

Right now, [moosepr] is experimenting with adding sound to his board. It’s easy enough to get sound out of a Pi Zero — it’s just PWM coming from a few pins — but audio also needs an amp, a speaker, and more space on the board. To solve this problem, [moose] found a few piezo transducers from musical greeting cards. These are designed to be thin and as loud as possible, and attaching these directly to the PWM pins providing audio might just work. This is a project to keep an eye on, if only to see if cheap piezos work for low-fi audio in retro emulators.

ENIAC: The Way We Were

January 31, 2017 by Al Williams 33 Comments

When I first got interested in computers, it was all but impossible for an individual to own a computer outright. Even a “small” machine cost a fortune not to mention requiring specialized power, cooling, and maintenance. Then there started to be some rumblings of home computers (like the Mark 8 we recently saw a replica of) and the Altair 8800 burst on the scene. By today’s standards, these are hardly computers. Even an 8-bit Arduino can outperform these old machines.

As much disparity as there is between an Altair 8800 and a modern personal computer, looking even further back is fascinating. The differences between the original computers from the 1940s and anything even remotely “modern” like an Altair or a PC are astounding. If you are interested in that kind of history, you should read a paper entitled “Electronic Computing Circuits of the ENIAC” by [Arthur W. Burks].

These mid-century designers used tubes and were blazing new ground. Part of what makes the ENIAC so different is that it had a different design principle than a modern computer. It was less a general purpose stored-program computer and more of a collection of logic circuits that could be configured to solve problems — sort of a giant vacuum tube FPGA, if you will. It used some internal representations that proved to be suboptimal which also makes it seem strange. The EDSAC — a later device — was closer to what we think of as a computer. Yet the ENIAC was a major step in the direction of a practical digital computer.

Cost and Size

The size of ENIAC is hard to imagine. The device had about 18,000 tubes, 7,000 diodes, 70,000 resistors, 10,000 capacitors, and 6,000 switches. There were ~~5 million hand-soldered joints~~! ([Thomas Haigh] tells us that while this is widely reported, the real number was about 500,000.) Physically, it stood 10 feet tall, 3 feet deep, and 100 feet long. The tube filaments alone required 80 kW of power. Even the cooling system consumed 20 kW. In total, it took 150 kW to run the beast.

The cost of the machine was about $487,000. Almost a half-million dollars in 1946 is plenty. But that’s nearly seven million dollars in today’s money. What was worth that kind of expenditure? The military built firing tables for shell trajectories. From the [Burks] paper:

“A skilled computer with a desk machine can compute a 60-second trajectory in about twenty hours…”

Keep in mind that in 1946, a computer was a person. [Burks] goes on to say that a differential analyzer can do the same job in 15 minutes. ENIAC, on the other hand, could do it in 30 seconds and with a greater precision than the differential analyzer.

Continue reading “ENIAC: The Way We Were” →

Fixing Bugs In A 37 Year Old Apple II Game

January 15, 2017 by Lewin Day 19 Comments

Emulators are a great way to reminisce about games and software from yesteryear. [Jorj Bauer] found himself doing just that back in 2002, when they decided to boot up Three Mile Island for the Apple II. It played well enough, but for some reason, crashed instantly if you happened to press the ‘7’ key. This was a problem — the game takes hours to play, and ‘7’ is the key for saving and restoring your progress. In 2002, [Jorj] was content to put up with this. But finally, enough was enough – [Jorj] set out to fix the bug in Three Mile Island once and for all.

The project is written up in three parts — the history of how [Jorj] came to play Three Mile Island and learn about Apple IIs in the first place, the problem with the game, and finally the approach to finding a solution. After first discovering the problem, [Jorj] searched online to see if it was just a bad disk image causing the problem. But every copy they found was the same. There was nothing left for it to be but problem in the binary.

Continue reading “Fixing Bugs In A 37 Year Old Apple II Game” →

Shmoocon 2017: On Not Reverse Engineering Through Emulation

January 14, 2017 by Brian Benchoff 12 Comments

Right now, I’m at Shmoocon, and it’s living up to all expectations. That’s a tall order — last year, the breakout talk was from [Travis Goodspeed] on his efforts to reverse engineer the firmware for a cheap Chinese radio. Four people in the room for that talk last year bought the radio on Amazon, and now there’s a legitimate open source project dedicated to building firmware and tools to support this radio.

Now that [Travis] has a few compatriots working on firmware for this radio, he has the same challenges as any other team. The project needs unit tests, and this isn’t easy to do when all the code is locked up inside a radio. Instead of setting up an entire development platform based around a cheap radio, [Travis] came up with a toolchain that’s unlike anything I’ve ever seen. Instead of reverse engineering the firmware for this radio, he’s simply emulating the ARM firmware on the desktop. Development is quick and easy, and he has the live demos to prove it.

The heart of the Tytera radio in question is an STM32F405. This is a pretty common part, and thanks to [Travis]’ work last year, he has all the firmware that ships on this radio. This doesn’t mean he has access to all the radio’s capabilities, though; there’s a black box in the code somewhere that translates .wav files to radio packets and back again. Open sourcing this would usually mean reverse engineering, but [Travis] had a better idea.

Instead of reverse engineering the entire radio, [Travis] is using QEMU to emulate an ARM microcontroller on his desktop, run the relevant code, and completely ignore any actual reverse engineering. Since this radio is already jailbroken and the community has a pretty good idea of where all the functions and subroutines are in the firmware, the most difficult part of pulling this trick off is setting up QEMU.

As a proof of concept, [Travis] downloaded raw AMBE packets from the radio to his laptop. These were then sent through the emulated radio, producing raw audio that was then converted into a .wav file. Effectively, a black box in this radio was emulated, which means [Travis] doesn’t need to know how the black box works.

All the code for this weird emulation / unit test, as well as everything the community has released for this radio is available on the GitHub. A lot of work has gone into the jailbreaking, reverse engineering, and emulation efforts here, making this radio somewhat ironically one of the most open radios you can buy.

Portable RetroPie Builds On The Shoulders Of Giants

January 12, 2017 by Bryan Cockfield 36 Comments

For anyone wanting to get that shot of nostalgia without the hassle of finding an NES Classic, the Retropie project is a great starting point. Of course, it’s not too noteworthy to grab a Raspberry Pi, throw a pre-built distribution on it, and plug in an SNES to USB converter. What is noteworthy, however, is building a Retropie that’s portable and that has the quality and polish of the latest build from [fancymenofcornwood].

For starters, the laser cut wood case was custom-made. From there, all of the PCBs were fitted including specific ones to handle each set of buttons (complete sets of D-pads, shoulder buttons, and joysticks) and another for the 5″ HDMI screen. It has stereo speakers and its own headphone jack (to the envy of all new iPhone owners), and is powered from a Raspberry Pi 2 running Retropie 4.1. The battery pack shouldn’t leave you stranded, either, especially not if you grew up playing the Sega Game Gear.

The quality of the build here is outstanding, and its creator made a design choice to make it easily replicable, so if you’ve wanted to play N64 or PS1 games while on the go, this might be what you’ve been waiting for. There are lots of other options for getting some fun from a Retropie going though, from building one into a coffee table to re-purposing that infamous Game Gear.

Obligatory clip of this portable playing Doom is found after the break.

Continue reading “Portable RetroPie Builds On The Shoulders Of Giants” →

Amstrad On An FPGA

January 6, 2017 by Al Williams 22 Comments

If you are from the United States and of a certain age, it is very likely you owned some form of Commodore computer. Outside the US, that same demographic was likely to own an Amstrad. The Z80-based computers were well known for game playing. [Freemac] implemented a working Amstrad CPC6128 using a Xilinx FPGA on a NEXYS2 demo board.

The wiki posting is a bit long, but it covers how to duplicate the feat, and also gives technical details about the design. It also outlines the development process used ranging from starting with a simple Z80 emulation and moving on to more sophisticated attempts. You can see a video of the device below.

Continue reading “Amstrad On An FPGA” →

Anti-Emulation Tricks On GBA-Ported NES Games

December 31, 2016 by Lewin Day 27 Comments

Emulation is a difficult thing to do, particularly when you’re trying to emulate a complex platform like a game console, with little to no public documentation available. Often, you’ll have to figure things out by brute force and dumb luck, and from time to time everything will come unstuck when a random piece of software throws up an edge case that brings everything screeching to a halt.

The Classic NES series was a handful of Nintendo Entertainment System games ported to the Game Boy Advance in the early 2000s. What makes them unique is a series of deliberately obtuse programming decisions that make them operate very differently from other titles. These tricks utilize advanced knowledge of the way the Game Boy Advance hardware operates and appear to have been used to make the games difficult to copy or emulate.

The games use a variety of techniques to confuse and bamboozle — from “mirrored memory” techniques that exploit addressing anomalies, to putting executable code in video RAM and writing to the audio buffers in unusual manners.

Even more confusingly, these techniques only appear to have been used in the Classic NES series of games, and not other Game Boy Advance titles. It’s not obvious why Nintendo went to special effort to protect these ports over other titles; perhaps the techniques used were for other reasons than just an attempt at copy protection. Speculate amongst yourselves in the comments.

This isn’t the first time we’ve discussed emulation of Nintendo systems — check out this effort to reverse engineer the Sony Pocketstation.

[Thanks to [[[Codifies]]] for sending this in!]