| << Newer | Article #179 | Older >> |
Revisiting the Past
It's been a long-time goal of mine to revisit many of the classic game drivers and give them an overhaul. Apart from my strange obsession with breaking things and reassembling them, there's actually a really good reason for doing so. When MAME was first developed, the obvious focus was on emulating the classics. After all, that's what everyone was most interested in, and since developers on free projects tend to work on what interests them, that's what they worked on. There was a lot of excitement about emulation back then, and for the most part, once a game worked, it was time to move on to the next game. I'm sure the thought that we would have 3000+ games emulated someday was an impossible vision.
Over the past 9 years, there have been a number of important improvements to the core MAME system. Things like tilemaps were added, more accurate timing was provided, better sound routing, improved input port options, more flexible and dynamic memory options, etc, etc. As these things were added, most drivers were updated only in the most fundamental manner, not to really take advantage of any of these features, but just to make sure that they still actually worked. And so today, we have a number of drivers that are very old, which haven't been looked at or updated in years.
But they still work, don't they? Well, yes, they mostly produce seemingly accurate results. But they are far from perfect. And while I don't know that I would call any MAME driver "perfect", most of the early drivers are really quite far from where they could be. For example, I know a number of people have used MAME to develop multigame hacks or hiscore hacks or other interesting variants of arcade systems. And invariably, I hear complaints that what works during development on MAME doesn't work on real hardware, due to the incompleteness of the emulation.
In addition, over the last few years, a much larger collection of arcade schematics and documentation has been discovered, scanned, and made available. Up until the mid-80's, complete schematics for many arcade games were produced and made available to operators so that they could repair problems with the PCBs. This means that many of the "golden age" games are actually well-documented, which makes it a shame that they are largely only very loosely documented in MAME. A large part of the problem with most of the early MAME work is that there was a lot of guesswork involved. Most of the people writing drivers (myself included) couldn't read schematics and didn't have access to a lot of arcade hardware. Thus you find things where, for example, the devs just slapped RAM anywhere the game wrote in the hopes of making it work, without any considering for how much actual RAM was present on the boards.
Finally, a lot of the early drivers were overly optimized. After all, computers 9 years ago weren't nearly as powerful as they are today, and it made sense that you optimized the drivers to ensure that you could hit a solid 60fps on systems of the time. But the problem with optimizations is that they by and large obfuscate what is actually happening. Over the years, I have removed a number of hacks and optimizations from MAME as they became less necessary to achieve an accurate framerate, and this has resulted in much easier to understand code. As a documentation project, it is important that the code make sense and reveal as much as possible about how the hardware actually works.
So far, I've done a fairly complete overhaul of the Crystal Castles and Missile Command drivers, though there are still a few things left to be done. Some important fixes there included getting the correct frame rates based on actual documented video timings, implementing video bitmap access techiques which were not hidden by the optimizations, and correctly emulating the CPU speed in Missile Command (it switches to half frequency for the last 32 scanlines of each frame).
In addition, I used what I learned from Crystal Castles to reimplement the Cloud 9 driver, which now also supports the Atari prototype game Firebeast. These games ran on what is an obvious predecessor to the final Crystal Castles hardware. And thanks to the person who loaned me his Firebeast PCB, I was able to trace out some of the circuits and determine the correct behaviors.
What's next? Well, obviously I have a certain affinity for Atari, Williams, and Sega, so those are obvious candidates. At the moment I am overhauling the Zaxxon driver. Thanks to a tip from one of the other devs, it was pointed out to me that Razmataz and Ixion used the universal sound board that I recently emulated for the old Sega vector games, and that got me interested in cleaning up the whole Zaxxon mess. Beyond that, who knows? And no, I'm not taking requests. :)