Fixing Bugs In A 37 Year Old Apple II Game

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

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.

tyteraNow 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

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].

render-blowup-of-retropieFor 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

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

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!]

Reverse Engineering the Sony PocketStation

[Robson Couto] never actually owned a PlayStation in his youth, but that doesn’t mean he can’t have a later in life renaissance. In particular a Japan only accessory called the PocketStation caught his interest.

The item in question resided in the PlayStation’s memory card slot. It’s purpose was to add additional functionality to games and hopefully sell itself. Like the PokeWalker, Kinect, etc. It’s an age old tactic but the PocketStation had some interesting stuff going on (translated).

The biggest was its processor. Despite having a pathetic 32×32 mono screen, it hosted the same processor as the GameBoy Advance. Having acquired a card from an internet auction house [Robson] wanted to load up some of the ROMs for this device and see what it was like.

It took quite a bit of work. Luckily there is a ton of documentation floating around the internet thanks to the emulation scene and it wasn’t long before he convinced a microcontroller to pretend to be the memory card slot. Now anyone with some skill and a small piece of gaming history can play around with the rare ROM dump for the PocketStation.

The Dual-Core, ARM-Powered Commodore 64

There is no CPU that is better understood than the 6502 and its cousins the 6510, 6507, 6509, and whatever we’re calling the CPU in the NES. With this vast amount of documentation, just about anything can be done. Want a discrete and un-discreet 6502? Sure thing. It’s the NMOS version, though. Want an emulated version. Sure. With libraries porting the 6502 to every platform ever, there’s only one place left to go: putting a 6502 in a Commodore 64. Make it dual-core, too, so we can run CP/M.

This build is based on one of [telmomoya]’s earlier builds – a soft-core 6510 running on an ARM Cortex M3. The inspiration for this build came from a 6502 emulator running on an Arduino, which got [telmomoya] wondering what would happen if he attached some external RAM, CIA or a SID. Doing this on an Arduino is hard, but there are a few 5 Volt tolerant ARM chips out there, and with a few banks of SRAM, [tel] quickly had an emulated 6502 running EhBasic.

Running an emulated 6502 on an ARM chip is nothing new. What makes this build spectacular is the adaptation to the C64 motherboard. Since [telmomoya] was already breaking out the data and address lines to go to the SRAMs, it didn’t take much extra work to simply build an adapter for the DIP40 CPU socket on a C64. A few 74-series logic chips made the interface easy, and after a bit of soldering, [telmomoya] had a Commodore 64 powered by an ARM chip.

If you’re emulating one chip, you can emulate two, and with the Commodore 64, this leads to a few interesting possibilities. The C64 had a CP/M cartridge — a cartridge that contained a Z80 CPU, sharing the data and address bus with the 6510. This cartridge allowed the ‘toy computer’ C64 to run the ‘business’ CP/M operating system (and the Z80 made the Commodore 128 much cooler).  Since [telmomoya] was already emulating a CPU, emulating a second CPU wasn’t really that hard.

It’s a phenomenal build, and great if you’ve ever wanted to speed up VisiCalc.