The processing power of modern game consoles is absolutely staggering when compared to the coin-op arcade machines of the early 1980s. Packed with terabytes of internal storage and gigabytes of RAM, there’s hardly a comparison to make with the Z80 cabinets that ran classics like Pac-Man. But despite being designed to pump out lifelike 4K imagery without breaking a virtual sweat, occasionally even these cutting-edge consoles are tasked with running one of those iconic early games like Dig Dug or Pole Position. Nostalgia is a hell of a drug…

As long as there are still demand for these genre-defining games, developers will have to keep figuring out ways to bring them to newer — and vastly more complex — systems. Which is precisely the topic of Bob Hickman’s 2023 Supercon talk, The Bits and Bytes of Bringing Arcade Classics to Game Consoles. Having spent decades as a professional game developer, he’s got plenty of experience with the unique constraints presented by both consoles and handhelds, and what it takes to get old code running on new silicon.

Why Not Emulate?

For any reasonably tech-savvy person, the first thing that will come to mind when talking about bringing old games to new hardware is naturally going to be emulation. At first glance, it would seem to be the ideal solution: you don’t have to recreate the game from scratch, the gameplay should be exactly as players remember it, and there’s probably an open source emulator core out there already that you can port over to whatever your target system is.

But as Bob explains early on in his talk, it’s not quite that simple in the real world. Sure, emulation should provide a perfect recreation of the game, but in practice, there are always differences that will manifest themselves in unexpected ways. Plus modern audiences are often going to expect enhancements (upgraded graphics, online play, etc) that are likely going to require some modification to the original game anyway.

There is also the issue of performance to consider. While this is going to be less of a problem on a modern console, you might be trying to bring the game over to something like a smartphone which may or may not have enough processing power to emulate the original system at the the speeds necessary to deliver the experience you’re aiming for.

To illustrate the point, most of Bob’s talk covers a particular project he was involved in back in 2001: bringing Namco Museum to Nintendo’s Game Boy Advance (GBA).

The Fine Art of Porting

Powered by an ARM7 CPU running at a little over 16 MHz, the GBA wasn’t exactly the ideal platform for emulation. At the same time, simply recreating the games included in Namco Museum from scratch wasn’t really an option either. Not only would it have been a considerable undertaking, but the final result would have been different enough from the originals that you’d lose that nostalgic charm.

The solution? Porting the games over to portable C code that could be compiled for the GBA. But even here, things wouldn’t exactly be smooth sailing. For one thing, Bob points out that you won’t necessarily have access to the original source code. So the first step is likely going to be extracting the binary and graphical assets from a ROM of the game — this could be pulled literally from an arcade cabinet and read into the computer, or if you’re pressed for time, perhaps downloaded from one of the seedier corners of the Internet.

After decompiling the game’s binary into Z80 assembly, Bob says the next step would be to convert that over to C. The results aren’t going to be perfect, but they’ll be better than nothing. The resulting C code certainly isn’t going to compile on the first go, but you’ll get plenty of error messages in the attempt, and that will tell you where you need to focus your attention on. Fixing these issues one-by-one is going to be time consuming, but will be worth the effort in the end. Eventually, you’ll get a binary that compiles and actually runs on your target system…but you aren’t done yet.

Up to this point you’ve just been worried about getting the code compiled and running. Whether or not it actually does what it’s supposed to do has been only a vague concern. So when you get this far, the binary you run likely won’t look or play anything like it’s supposed to. For one thing, the graphics are sure to be busted. You’ll need to go in there and rewrite the graphics functions so they’ll work on your target system while still taking the same inputs as the original versions. That’s going to include figuring out how to scale everything to fit your new target resolution.

You’ll need to do something similar for handling user input, as well. The original arcade cabinet probably had some memory mapped scheme where reading from an address in memory would tell it which physical buttons were being pressed, so that’s going to need to be modified to fit the game’s new home.

Keep knocking these issues out as they come up, and eventually you’ll have a working game. Sort of.

Getting Up to Speed

The final part of the process is optimization. Bob recalls that, after porting over the original Z80 code and getting it running  properly on the GBA, some of the games would only run at a fraction of their original speed. It wasn’t because the GBA didn’t have the computational power to do the games justice, it’s just that the code wasn’t working to the system’s strengths.

One trick that Bob details is adding some code that will record each function called by the code, and have somebody play the game for a bit. After you’ve collected enough data, you’ll be able to identify the most commonly used functions and properly direct your optimization efforts.

Unfortunately, there’s no magic bullet for code optimization. But Bob does mention some commonly used tricks, such as using pre-computed lookup tables instead of trying to do sine and cosine math in real-time. There’s also things the new hardware will be capable of that you might be able to put to use, even with an older game that wasn’t designed with it in mind.

Bob gives an excellent example of this in discussing the optimizations for Pole Position. Originally the background objects on the horizon were rendered in the same way the rest of the game was, but this proved to be slower on the GBA than anticipated. So the solution was to take the entire skyline, save it as a pre-rendered image, and use the GBA’s hardware scrolling capabilities to move it. Along with a few other tricks, this got the 1982 racer running at the proper 60 frames per second.

Not All Fun and Games

While Bob’s talk was focused on a very specific niche, many of the tricks and techniques he describes could be applied to other aspects of software development. Whether it’s taking old assembly code and turning it into C that your modern computer can run, or tracking down which functions are worth your time to refactor, there’s plenty in this presentation that you can use in whatever software project you might have going on.

Now whether or not your project is as much fun to bug-test as Galaga — well, that’s another topic entirely.