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.
Can't wait to play true classics on my Pentium 4...
Stop by my site where I write about ERP systems & more
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
Well, I'm not porting to a different platform, but I am converting old bootable 360k floppy disk games into games that can still be run on modern computers.
I've finished the Epyx game JUMPMAN
http://www.classicgaming.com/jmanproject
and I'm currently working on Beyond Castle Wolfenstein
This is a very time consuming hobby, but for me it's a matter of preservation than anything. I don't want to have to dig out the PCjr from my closet everytime I want to play these oldies.
-jeff!
Too much self modifying code, the guy is a fool.
He does not talk about dynamic recompilers (that use page management dirty-bits to track self mofifying code)
He does not talk about self modifyingh code
he does not talk about timing loops and differences in different opcodes
He does not talk about lot of things.
I suspect he is not the one to talk about this stuff.
Tom Dowdy (old email dowdy@apple.com) knows all about DR he wrote a paper on it.
So did the guys who wrote a DR for recoding Mac 68K on an Intel at full speed, the Executor guys.
Its incredibly hard work and takes half a millikon dollars to do one correctly that can handle self modifying code.
The guys from Connectix (now Microsfot) did it with having the x86 intel run on a PowerPC.
DR (Dynamic Recompilation) technologies do not make source code.... because that itself would take tens of millions of dollars to engineer and at least a few huge teams of experts, and even then would not be possible to automate.
That guy is a fool, but I do agree that stuff NOT written in assembler (compiled stull written mostly after 1999) couple be transcoded into files because C++ and C on moder architectures rarely has self modifying structures.
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.
These people are the ones who translated Phantasy Star games to the GBA.
The GBA does not have the power to emulate the Mega Drive (Genesis) even with a JIT compiler. Hence, a different method would be needed. Either simulation, recompilation, or translation. Translation was the best option given what they had to work with.
Emulation is wonderful and all but it certanly doesn't work in all situations.
FYI, I believe that PS1 was emulated and PS2,3 were translated in Phantasy Star Collection. They're not saying to use this as a replacement, they're just telling you how they did it. I'm letting you know why.
Why not a compiler that takes machine code and compiles it to a new machine code? Such systems have been made. The Java JIT compilers take java bytecode and compile it to native machine code. The translator on the Transmeta chip takes AI-32 and comiles it. Why not one that takes say an MS-DOS program and converts it to Linux? You would have to map every interupt and dos call but it could be done. Selfmodifying code would be a big no no or a huge challenge for the compiler. All in all it could be interesting.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
This should be modded WAY up. People are really missing the point of this article. It's not useless, they actually got paid to do this!
Those games run fabulously and flawlessly on the GBA. They really do look and act like the originals.