Ask any security professional and they’ll tell you, when an attacker has hardware access it’s game over. You would think this easily applies to arcade games too — the very nature of placing the hardware in the wild means you’ve let all your secrets out. Capcom is the exception to this scenario. They developed their arcade boards to die with their secrets through a “suicide” system. All these decades later we’re beginning to get a clear look at the custom silicon that went into Capcom’s coin-op security.
Alas, this is a “part 1” article and like petulant children, we want all of our presents right now! But have patience, [Eduardo Cruz] over at ArcadeHacker is the storyteller you want to listen to on this topic. He is part of the team that figured out how to “de-suicide” the CP2 protections on old arcade games. We learned of that process last September when the guide was put out. [Eduardo] is now going through all the amazing things they learned while figuring out that process.
These machines — which had numerous titles like Super Street Fighter II and Marvel vs. Capcom — used battery-backed ram to store an encryption key. If someone tampered with the system the key would be lost and the code stored within undecipherable thanks to “two four-round Feistel ciphers with a 64-bit key”. The other scenario is that battery’s shelf life simply expires and the code is also lost. This was the real motivation behind the desuicide project.
An overview of the hardware shows that Capcom employed at least 11 types of custom silicon. As the board revisions became more eloquent, the number of chips dropped, but they continued to employ the trick of supplying each with battery power, hiding the actual location of the encryption key, and even the 68000 processor core itself. There is a 6-pin header that also suicides the boards; this has been a head-scratcher for those doing the reverse engineering. We assume it’s for an optional case-switch, a digital way to ensure you void the warranty for looking under the hood.
Thanks for walking us through this hardware [Eduardo], we can’t wait for the next installment in the series!
Don’t call it an arcade. There are arcade-like things about it… like dance-based video games, Skee-ball, and tickets — oh so many tickets. But Marvin’s Marvelous Mechanical Museum is a one-of-a-kind that you need to visit next time you’re in the North suburbs of Detroit, Michigan.
[Marvin] was there in person, as he is many days. He talked with us for a few minutes and we’ve folded his interview, along with footage of many of the attractions, into the video above.
He’s been collecting for more than three decades. The attractions are packed into every bit of floor space, spilling up onto the walls, and hanging from every spot in the ceiling. There are true antiques from both home and abroad that could be referred to as automatons, rows of fortune tellers, a track of large airplane models that make a loop around the establishment when fed a quarter, and much more.
Some of the attractions were build for him, like the robot band you can make out behind [Marvin] during the interview. It is a MIDI-based build that allows songs to be selected from a touchscreen. Soon to be on exhibit is a Tesla-coil-based offering which [Marvin] commissioned after taking second place to [Nicolai Tesla] on a list of oddest museums.
Continue reading “Marvin’s Marvelous Mechanical Museum”
This is a screenshot from the Atari 5200 version of the classic game Berserk. But the write-up we’re featuring actually looks at the original coin-op version. The maze for each level was established on the fly using a seed number fed into a rudimentary algorithm . Here’s a close look at how the maze building code actually worked.
Recently we saw a talk by Pitfall creator [David Crane] as part of our Retrotechtacular series. That is a real gem of programming history, and one of our favorite take-aways was that the levels were not hardcoded, but built using a random number generator algorithm with a hardcoded seed (so that the game was the same each time you played it). This uses a similar method but with a somewhat random seed.
The maze building was reverse engineered by observing the game in a MAME emulator, and by digging through disassembled code. Each time the code is “cold started” the seed starts out at zero, but from there the room number is used as the next seed. This is fed through a very simple algorithm. It generates directions for the walls, which use s few bit-wise operations to add the pillars inside the rooms.
It’s a great thing to study if you’re writing games for your embedded projects. By generating the room programmatically you don’t use up as much program memory. Of course these days even simple hobby controllers have way more storage to work with than [Alan McNeil] had when he designed Berserk.
The company which [Eric Wright] works for recently bought a Nintendo VS. It had Ice Climber installed as one of the titles but they asked the vendor if it was possible to swap it out for the Duck Hunt ROM. They had the ROM but not a light gun that would work with the system. [Eric] suggested they buy it with Duck Hunt and hack an NES Zapper to work with the VS cabinet.
Let’s take a step back for a moment. The Nintendo VS was a coin-operated gaming cabinet you would find in an Arcade. Luckily there’s quite a bit of information about the original hardware on the web. Some research helped him discover that electronically the only difference between the arcade and home versions of the Zapper is that the sensor capture is inverted. This was fixed by replacing a transistor in the gun with a jumper wire. The next challenge was figuring out how to wire the gun up to the second controller port. And finally he patched the ROM to work with the incorrect PPU as the right chip was not easily sourced.
Continue reading “NES Zapper modified to work with an old Nintendo VS. cabinet”
Head to head video game action can’t even compare to this use of a coin-op Sega Rally game to race actual RC vehicles. Take a close look at those screens and you’ll see there are no computer graphics, just a feed for a camera on each of the toy cars.
The project was conceived for the Sapo Codebits VI conference in Portugal. The arcade cabinets had their controls connected to an Arduino, but getting video up and running wasn’t nearly as easy. After fruitless attempts to get the original CRTs to work the team ended up replacing them with functioning CRT units of the same size. The cars themselves have two camera, one on top of the vehicle’s cab and one mounted on a boom for a perspective that was above and behind the vehicle. The drivers can switch between either view. The cars were set loose in the room serving as the event’s retro gaming area and players were free to race each other wherever they pleased. Don’t miss the video clip after the break which shows off all of the fun. Continue reading “Coin-op Sega Rally used to race RC cars”