Has there ever been a documented reverse engineering of an arcade game?

Main > Everything Else

<< < (4/8) > >>

CheffoJeffo:
I seem to recall some reverse-engineered and documented source for early Williams games, but I can't recall whether it appeared on RGVAC or was something that Mike Ranger (who posted as WilliamsGuru) told me about when I bought his Joust cocktail.

As a piece of arcade trivia, I guess that Tim Skelly was the first to do this when Larry (last name escapes me) left Cinematronics and took all of his notes and all of the hardware. IIRC, Tim rebuilt the software and was able to reconstruct the hardware based on a hex dump.

Howard_Casto:
MonMotha:

Did you not see my post?

I liked your explainations, but you basically just repeated what I posted in long-hand. ;)

jimmy2x2x:
I'm still not really convinced that arcade game code would have been written in C or any other high level languages in the mid to late 80's. With most games running around 60 frames a second, binary code size and chip prices at the time, speed of the CPU in many arcade games, non mature nature of compilers back then... seems like a stretch to me.

MonMotha:

--- Quote from: jimmy2x2x on March 02, 2012, 06:40:05 pm ---I'm still not really convinced that arcade game code would have been written in C or any other high level languages in the mid to late 80's. With most games running around 60 frames a second, binary code size and chip prices at the time, speed of the CPU in many arcade games, non mature nature of compilers back then... seems like a stretch to me.

--- End quote ---

C compilers in the late 80s were already getting fairly good. UNIX was written in it, after all, and it was nearing 10 years since the publication of the K&R book and nearly 20 years since initial development. Figure most PC games were written in C and other "high level" languages, so why wouldn't arcade games be? The maintenance is just so much easier, and you can easily knock 50% off of the software dev cycle, which was a major deal in the arcade industry.

By 1990, people would pretty much assume you were insane if you wanted to write an entire program of any real complexity entirely in assembly without a really, really good reason.

If you know what you're doing, it's trivial to write pretty tight C. Honestly, I find it easier to write "efficient" (both space and size) programs in C than assembly, even allowing for extra development time for the assembly variant. It's just so much easier to make modifications to improve performance when you don't have to worry about every tiny little detail. You can always inspect the output assembly and tweak either your input or drop to inline assembly, if necessary. The optimizers are better these days, but it was not hard to write "small" and efficient C programs back in the day, even with fairly immature compilers.

C isn't a crazy bloated language. The language itself is extremely lightweight, and the standard library is small, reflecting the storage/computing capabilities of when it was developed (late 70s). printf and malloc are generally some of the biggest functions in the library, and you'll often burn a whopping 20-30k to include both of those, which was getting small even for ROMs by the late 80s.

FWIW, I'm working on a project right now using GCC for ARM, and the total binary output (including all the init and library code) is...40348 bytes, about half of which is a somewhat suboptimal (it handles floats, which I don't need and are complicated) implemenation of printf and some bitmap font data. I haven't even really been trying to make it small. The input is 17 mid-size (typically 100-250 lines) source files plus a libc.

I regularly program little 8-bit micros that have less than 1k of RAM and 8k of FLASH for program code and run at 8-16MHz (performance comparable to a 20-32MHz M68k) in C without any real issues performance-wise. I'll admit I'm running on somewhat newer compilers, but even disabling optimization entirely generally leaves me with something that works just fine, even in time critical applications.

Many arcade games also ran at only 30fps, not 60. Each frame was just output to the monitor twice while the system worked on the next frame.

Then again, if you want to know, just grab a program ROM image and run an appropriate disassembler on it. It's usually fairly easy to tell if it was hand written or compiled. Heck, you can often tell what language it was written in and sometimes even which compiler was used, if you know what to look for. Honestly, excepting cases where inordinate attention was paid, the compiled code is often quite a bit more efficient than the hand-written code. Like I said, you might see a few sections in a program written in a high level language (C, Pascal, etc.) that were hand tuned assembly for performance reasons, but often the "base" for that code was the output of a compiler. Easier to know that it's "right" to start with, that way.

MonMotha:

--- Quote from: Howard_Casto on March 02, 2012, 06:35:43 pm ---MonMotha:

Did you not see my post?

I liked your explainations, but you basically just repeated what I posted in long-hand. ;)

--- End quote ---

I think it got posted while I was composing my post, so, while I saw it, I figured I'd already written everything up and might as well post it anyway.

Navigation

 Message Index

Go to full version