The following excerpt comes from Arcade Perfect: How Pac-Man, Mortal Kombat, and Other Coin-Op Classics Invaded the Living Room by David L. Craddock, available in paperback and Kindle formats.
DANIEL FILNER COULDN’T believe this was happening. He was seventeen years old, and he and his friend were hanging out at Skywalker Ranch, the center of George Lucas’s Star Wars universe. “I was seven when Star Wars came out. This was amazing.”
Filner’s journey to that galaxy far, far away began at age eleven, the first time he touched Radio Shack’s TRS-80 personal computer. His school had one, and his math teacher gave Filner permission to tinker with it because he was ahead of the rest of the class. Through middle school, he signed up for programming courses during summer vacations and learned BASIC on the Apple II.
Filner came by his proclivity for numbers honestly. His father, a scientist, didn’t want his son wasting time playing video games on one of those Ataris or Nintendos he’d been hearing about. As a compromise, he bought him a TI-99/4A, Texas Instruments’ personal computer released in 1981. For the modest sum of $525, the PC came with a three megahertz processor, 256 bytes of memory, and compatibility with storage media such as cartridges, floppy disks, and cassette tapes.
There, his father said as he finished setting up the PC. Now his son could learn practical skills instead of frittering away time on games. Naturally, the first thing Filner did with his new computer was write games. “By the time I was in seventh and eighth grade, I was trying to write Donkey Kong for the PET, and Pac-Man for TI994A, just trying to reproduce arcade games on home computers I had access to. I didn't do a great job, but that's how I started programming, just recreating arcade games on home computers, mainly because I didn't have twenty-five cents to put into an arcade game.”
Pac-Man stumped Filner. He was programming in BASIC, and no matter how hard he tried, the four ghosts refused to roam freely, in real-time, while he guided the hockey puck-shaped character around the maze. First he moved, then the ghosts moved. “My mom actually liked it,” he remembered. “I remember my mom playing it, and I was disappointed because the ghosts didn't move by themselves. But my mom found it more strategic because you had to cover the maze without wasting any ground.”
Filner packed up his TI when his family moved to California. His new school had a Commodore PET, and he endeavored to recreate Donkey Kong on it to marginally better results. “Somewhere in my garage is a cassette labeled Filner Kong, which was Donkey Kong,” he said.
Entering high school, Filner sought out more complex programming challenges. His father bought an Atari ST, and Filner progressed from BASIC to assembly language. His goal was to write his own BBS, or bulletin board system, an online message board where users could share messages and files. Then his friend Tim showed him a game called Ball Blazer, an action game made by Lucasfilm Games—later renamed LucasArts—for the Atari 800 PC. They liked it, and decided to port it to the ST. Filner uploaded the game to a BBS and was contacted by a guy who claimed to be working the dream job Filner had fantasized about since childhood.
“I'm seventeen, and he's a full-grown adult, and he knew I was a bulletin board operator in the neighborhood. He needed some work done on a BBS he was trying to get together, but it turned out he had been in the games industry, and he had connections. He saw what we were doing with our Atari ST version of Ball Blazer, and he got us in touch with Lucasfilm Games.”
Lucasfilm invited Filner and Tim to Skywalker Ranch. After the grand tour, the executives presented them with a contract to finish Ball Blazer for the ST. It was fun while it lasted. “The total amount of money for the two of us might have been less than $2,000,” Filner said. “We were high school kids. We finished it up and got it working, and it came out reasonably well. But it turned out they weren't going to publish it. It wasn't going to turn into a thing, and we were very disappointed by that.”
A year later, Filner was attending classes at UC Berkeley when he got a call from a manager at LucasArts. He was looking for a programmer to write a sound driver—a file that brokered communication between hardware and software—for the Atari ST version of Zak McKracken and the Alien Mindbenders, a point-and-click adventure game that ran on the company’s proprietary SCUMM (Script Creation Utility for Maniac Mansion) engine. The producer had reached out to Filner because he was one name on a very short list of programmers familiar with the ST. Just like that, he was a Jedi again.
“I mean, they sent me paper checks that had Yoda on them. I'm in college, and I'm making… not a living salary,” Filner said after a pause, “but more money than a college kid needs, and I'm getting my computer science degree and already working professionally.”
LucasArts continued developing point-and-click adventures on the SCUMM engine. Each new game introduced new features such as the ability to scale characters up and down as they walked closer to or further from the screen. Filner stayed on as a contractor, porting games such as Loom and Maniac Mansion to the Atari ST. Later versions of the engine forced him to keep his skills up to snuff by doing things like writing in a hybrid of assembly and C.
In university, one of his classes centered on learning to give presentations. Filner talked about his favorite subject: How to make video games. Around the same time, he enrolled in a course on assembly language. His professor greeted them the first day by saying, “You’ll never really need to use this stuff” since high-level languages like C were far more prevalent in nine-to-five jobs like writing software for banks, but, he admitted, a few students might find it useful.
Filner smirked. “It was like, ‘Well, actually, I'm getting paid to use this stuff right now.’ It wasn't some hypothetical. It was actually what I was doing.”
Following graduation, Filner got a job programming licensed games for a company called Equilibrium. He worked on a baseball game starring Bo Jackson, an action game that licensed the Attack of the Killer Tomatoes characters, and a title where players performed the slick moves of rapper Vanilla Ice. One afternoon, he got a call from a guy who asked if he’d be interested in working on a collection of old arcade games.
Filner was taken aback. He had no idea who this guy was or how he’d got his number—but, yes, he was interested.
The company was Digital Eclipse, and the assignment was to get Defender, Stargate, and other classic Williams games running on Sega Genesis. “The guy said, ‘Okay. Here's the Genesis dev kit. Here's the source code for Defender. See if you can make Defender work.’ It was like being handed the Crown Jewels: Looking at Defender's source code and seeing how it worked. I was cross-translating from 6809 assembly to 68000 assembly,” Filner explained, the latter being the dialect of assembly processed by the Genesis. “I had to understand the entire program top to bottom.”
Every Williams game used a bitmap system that stored every pixel on the screen in a memory register. The end product displayed at a resolution that was more than good enough. Two weeks later, Filner called his contact at Digital Eclipse and said he’d gotten Defender working. “Great,” the guy said. “Now do Stargate.” Filner completed the job even faster. He moved on to Robotron, then Sinistar.
For his next job, Digital Eclipse wanted Filner to convert the same collection to the Saturn, Sega’s CD-based console. This job, he knew, was a taller hurdle to jump. His Genesis conversions had been translations of a game from one language to another. The Saturn required an emulator. That would make each retro game in the collection arcade perfect, if Filner could figure out how emulators ran and how to write one. Fortunately, one of the engineers at DE gave him a primer. “You don't have to massage every single byte of every single line by hand,” Filner said. “You just the emulator to work, and then, boom—it comes out the right way. I don't think I've ever thought about it like this before, but I was right at the junction of having a game where the target system was not powerful enough to do an emulator, so I had to build an emulator for this game I already knew from top to bottom.”
Over the next several years, emulating classic console and arcade games became Filner’s specialty. He handled the Capcom Classics Collection, which included versions of Street Fighter II, an anthology of Sega Genesis games like Sonic the Hedgehog and Golden Axe, and more arcade titles by Midway. Many of those and other projects were given to him under contract by Digital Eclipse, who by that time had him on speed dial.
“When they got Street Fighter 30th Anniversary Collection, they knew right away that that was the kind of thing I could do,” Filner said.
✽✽✽
DANIEL FILNER HOPED things would go a certain way when he worked with publishers. Hoped, but did not expect.
For instance, he rarely spoke directly to property-holders like Capcom, so he asked contractors such as Digital Eclipse to do his talking for him. His request for Street Fighter 30th Anniversary Collection was simple, and the same as every project involving porting or emulation: Get the source code. Having a game’s source was like having a GPS on a long road trip. Without it, he just had to get in his car and drive. “Usually, it doesn't happen,” Filner admitted. “It's super-difficult, because the source code is maybe missing completely or hard to access, and they don't understand or care that it's helpful, or they're paranoid about letting it out of their grasp. Sometimes it happens after the project is over.”
Street Fighter 30th was a special case. Heading into the project, he already had a personal library of SF code he’d been amassing since the early 2000s, when he’d worked on various Capcom anthologies that included assorted flavors of SFII. He’d been work-for-hire at the time, so the emulator he’d written had belonged to his employer. Since then, he’d built his own from scratch, updating it whenever a Street Fighter-related project came along.
Every programmer went about writing an emulator in his or her own way. No matter the method, the goal remained the same. “Basically, an emulator pretends to be another piece of hardware,” said Mike Mika, studio head of Digital Eclipse, and an engineer who’d written his fair share of emulators.
At the dawn of every emulation project, programmers consider the technical layout of the platform they want to emulate: its processors, its memory, its audio and video chips, and the language of the game’s code, which executes the instructions that operate all that hardware. Most arcade games are written in assembly. The job of a game’s main processor, the CPU, is to read instructions in code, one by one, and do what that instruction tells it to do: add values, subtract values, store a value, load a value, compare two or more values, branch into other sections of code. “An emulator does what the CPU does,” Filner explained. “It has a number that points to the program counter, and it pulls the next instruction by reading from the game ROM.”
Emulators are agnostic. They don’t care what game the CPU is trying to run. They just wait for instructions and tell the CPU to act on them. “Each chip, whether it's a sound chip or anything else, follows the same basic pattern of doing a little bit of processing, producing output, checking the inputs—whether they're joystick inputs, a button being pressed, or input from some other chip,” Filner continued.
Every frame of animation, emulators produce two types of output: an image rendered at the game’s native resolution, and a stream of audio. Another part of the emulator decides what to do with that output. Usually, this means blowing up an image to fill the screen and directing audio to an output channel, most often a set of speakers. “The core of the emulator doesn't care what system it's on. It just produces a bitmap and a stream of audio samples,” Filner said. “If you think about an arcade game that's eighteen inches square, maybe, and has thirty chips on it, one of those is the CPU, one might be a sound chip, and one might be another CPU to talk to the sound chip. An emulator just has to do what the hardware did.”
Primordial games such as Pong were made up of circuits with gates that opened electronically and dispatched binary signals of yes or no, one or zero. That made them difficult to reproduce exactly, one-to-one, in code. When technology allowed engineers to make games from CPUs and RAM chips, most coin-op manufacturers bought those and other products off the shelf rather than reinventing the wheel. Every one of those chips and boards came with documentation that helped them to understand how to build what they wanted to build.
Writing emulators is still an arcane art rather than a science, but enthusiasts and career programmers like Filner have bridged the gap by following in the footsteps of coin-op manufacturers. When given an emulation project, they try not to reinvent the wheel. “If you think about automobile parts, these are like if you had a bunch of companies making automobiles, but the companies all got their parts from three parts manufacturers,” Filner explained. “You might have an automobile with a Z80 and another with a 68000 processor. The outside could look like whatever they wanted, but the insides would look like the parts everybody knew how to use. If you know how to emulate those parts, it's all modular. The amount of unique hardware for each hardware system is still rather small.”
In a way, emulating a game is simple. Once programmers understand a particular piece of hardware, they can write code so emulators such as MAME, the most popular arcade-machine emulator around, will support it. The tricky part comes when publishers request changes to be made. “Any time you need to modify original behavior in any way, it pierces the veil of the emulation. You can break things,” Filner said.
Back in the heyday of Street Fighter II and Teenage Mutant Ninja Turtles, manufacturers like Capcom and Konami included a screen featuring the FBI logo along with a quote now synonymous with video arcades, Winners Don’t Do Drugs. “Recently,” Filner recalled, “some genius lawyer said, ‘The FBI lawyer on that screen is a trademark of the US government. We're not necessarily still allowed to use that, so we'd better remove it.’ What? No, that's part of the original game. Well, I'm not in the legal department so I don't get to ask those questions. They just say, ‘Please take out the FBI screen.’”
Making a change as direct as ripping out a screen is easy when developing an original game. For emulation programmers without access to source code, classic games are black boxes. They could crack open the game’s ROM, disassembling it, and sifting through code to find instructions pertaining to that screen, but that came with risks. Filner could accidentally damage other parts of the code. Instead, he tries to figure out how to hop from the instruction pertaining to the screen needing to be removed to the next instruction in line. Another option is to leave the screen intact, but implement a way to skip over it.
Publishers also tend to request that a game’s copyright screen be updated to show the year of its re-release. That’s less like performing surgery and more like defusing a bomb. “The copyright message is the first thing that would have boobytraps on it,” Filner said. “When a programmer was trying to prevent bootlegging, they'd have checksums”—a sequence of characters the game verifies—"and checksums to check the checksums. If you're asked to change something that you think might have been boobytrapped, you have to be super-careful to make it so the emulator can't tell you've changed anything.”
The approach Filner chose for Street Fighter 30th was to insert breakpoints, road signs that divert a program’s execution without needing to even see legacy code, much less alter it. “Breakpoints mean, at this instruction, the emulator stops and calls this C++ function. The C++ function is essentially a magic watch that stops the world: It happens in between instructions, and you can change things without the original program noticing, if you're careful.”
As Filner moved deeper into the code for the twelve games included in Street Fighter 30th, he had to make other changes requested by Capcom. Before each match, Street Fighter let players choose from a handful of stages themed after cities and countries. SFII expanded on that practice by designing a stage around each character’s personality and the culture of their country: a dojo in Japan for Ryu, a U.S. Air Force hangar for Guile complete with a jet idling in the background and soldiers hanging around to cheer him on, a Chinese market for Chun Li’s marketplace is a hive of activity. Citizens pedal bicycles back and forth, a vendor throttles a chicken, and a family cheers from within the shade and safety of their shop. Behind the family sits a stack of crates decorated with Coca-Cola’s white-swish-on-red-background iconography. Another offending item, a can of Coke, sits on the ground in Guile’s hangar. “Capcom decided, ‘Maybe we shouldn't have those because we didn't talk to Coca-Cola about it,’” Filner said. “I had to paint over or erase those crates so they didn't look like Coca-Coca [iconography].
“There's something like 64,000 tiles for every one of these games, so there's this giant tapestry of tiles Maps and player-character sprites are generated from these lists of tiles,” he said. “When it came time to make these modifications, I just inserted crate tiles that had been overlaid. The tiles are not actually stored as a big bitmap in the ROMs. In order to make these changes, I had to write a converter program to take the ROM image and convert it into a bitmap. Then I could edit the bitmap, and the tool had to convert the bitmap back into the ROM format.”
Changing subtle details of decades-old game content gives Filner a different perspective of a career built on preserving games. “This particular topic isn't really preservation. This is corrupting parts of the original game to make it legally possible to [sell again].”
Arcade Perfect: How Pac-Man, Mortal Kombat, and Other Coin-Op Classics Invaded the Living Room by David L. Craddock is available in paperback and Kindle formats. Disclosure: David L. Craddock is the author of Arcade Perfect, and the longreads editor at Shacknews.com. This feature is not considered an endorsement of his book
-
Shacknews
replyDavid Craddock posted a new article, How Digital Eclipse preserved a classic in Street Fighter 30th Anniversary Collection
-
Great article.
-
