Slashdot Mirror
Porting Games From Binary
CowboyRobot writes "My favorite Slashdot links are those that inspire me to embark on meaningless and time-consuming quests. This is one of them. Two Canadian game developers at Digital Eclipse have a thorough explanation of how to port a game using nothing but the binary stream coming out of the cartridge. They use the TRS-80 and Phantasy Star III as examples."
One problem that I don't see addressed in the article is the different approaches games use today compared with those on old hardware. For example, on machines where the disparity between CPU and memory speed was not as great as it is today, it was common practice to precalculate many maths-intensive operations into lookup tables (usually in the form of sin tables, cos tables and so on). On a modern processor this level of precalculation can result in slower execution than just working out the maths on the fly, so most games do minimal precalculation of things like maths functions. While it's often the case that speed is not really an issue with old game ports, it would be interesting to see how they would approach the problem of porting and ensuring that the resulting game makes optimal use of the target machine.
In our lab we sometimes have to reverse-engineer components for which we no longer have documentation. It would be very simple to export the data of a video game cartridge by accessing its ROM module with a binary card reader. The trickier part is to get the offset right so that any fluctuations will be evened out on the oscilator. One could then re-compile the imported code into a new platform similar to what the folks at MAME do.
What we've done is imported "Yars' Revenge" from the Atari 2600 did some elevation emulation, ported the code, and re-compiled to make it work on the Intellivision. We may be selling that cartridge commercially as there is a great need for 8-bit cartridges.
Which is nice.
For console video games, why in the hell would you translate the language? All the consoles had funky hardware that games used one time or another.
For 1, the NES uses mappers to display games. On emulators, many mappers are not supported. NES game producers also put hard-coded timings in games. So if your recompiled game isnt the exact same multiplier of clock frequencies, many will exhibit starnge behavior or just lock up.
Next, the SNES had pretty much basic AppleII GS hardware with the exception of the 32 channel sound card. It had a sound cpu which could hold 64k code along with samples. A problem that the makers of ZSnes had was determining the random noise generators formula. On the older games like Chrono Trigger, the wind would sound like square waves going up and down. That sounds fun, compiling a game when you find out that the hardware emulation controls wernt right.
Jump to PS2. Who would have thought that a comuter like that would be available to the public? One that has little GFX ram but a huge bus. Not to mention a full FS to "compile". What pitfalls occur in the 3D hardware?
Emulation is still better as it offers a replacable shim to modify and add features. You can also use other emulators.
Amazing feat. It's completely rewritten in C to gain exactly the same functionality as the original code, with only the binary / dissassembled machine code to work with.
-larsch
The guys at OS/2 Netlabs have been doing this for years now. It'ts called Project Odin They run Win32 apps on top of OS/2 with no emulation: they "translate" binaries on-the-fly. They even run Win32 drivers on OS/2!!
I've had to suffer through these guys' port of Joust on shockwave.com (in fact I have the high score for the month currently) and it has several inexcusable flaws. The most annoying is that it doesn't always respond to keypress events properly - rather critical functionality for a game. It doesn't actually seem to drop the events, which would be bad enough, but it ignores them for as much as half a second at a time and then spits a whole bunch out together. If your game wasn't screwed up when it seemed to ignore the event, it's damn sure going to be screwed up when they all get played back in a burst along with the other keys you hit to recover from the original failure. I know Windows is not a real-time system, and I've worked on real real-time systems (microsecond response times) so I do know the difference, but there's no excuse for a delay this long on an unloaded modern system. Other games don't seem to be afflicted by the same problems. The problem is not in Windows; it's in Digital Eclipse's emulation of the hardware on which the game originally ran (even if the code is translated the non-CPU hardware still has to be emulated).
There was also a time when the game's speed calibration was totally broken. I'd play on my 600MHz laptop and it would be just about right, but when I went to my 1.5GHz desktop guess what happened. Yeah, everything in the game was moving about 2.5x as fast and the game was unplayable. This only persisted for a week or two, but it's still not something that should happen in a version that's released to the public. These technical failures, combined with their apparent acquiescence to Shockwave's desire to add deliberate player-killing features to their translation (the very laws of physics in the game change after you get a good score, and I've looked at the original ROM code so I know exactly how they're doing it) have left me with the impression that Digital Eclipse is both incompetent and unethical.
Slashdot - News for Herds. Stuff that Splatters.
Odd TRS story: the bicycle manufacturer GT made a mountain bike called an RTS-1 (Rear Tuned Suspension). It shouls have been the more logical TRS-1 (Tuned Rear Suspension), but the Tandy trademark apparently stopped them using the initials TRS. This was about 10 years after the TRS had gone out of production!
When I am king, you will be first against the wall.