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."

Comments

When Bad means Good

[WebfishUK]

It's this kind of pointless endeavour that gives geeks a bad name.

It's this kind of pointless endeavour that makes me happy to be a geek.

Some people climb mountains, other disassemble 8085 binary code.

Badly researched?

[FyRE666]

Unless I'm missing something, this novel idea is complete garbage. Yes, sure you can disassemble the machine code, produce some C code from that and then recompile for a new target CPU but it's not going to work for the vast majority of applications.

The reason: hardware.

Even your average 80's arcade machine relies upon custom hardware for virtually everything. The main program spends most of its time simply adjusting registers to control sprites etc, and reading from hardware to detect collisions and so on. This new code you've generated for a new CPU will still expect the same supporting hardware...

Re:Badly researched?

[Zan Zu from Eridu]

If you rebuild an executable for system X from a binary dump for system Y, you don't just disassemble it, but you put in macro's for all of the opcodes for system Y. These macro's are the glue that emulate parts of Y's hardware on system X.

It's comparable to the difference between an interpreted language and a compiled language. An emulator is a virtual machine that interprets opcodes for machine Y and translates them to instructions for machine X on the fly; this solution compiles the tanslations into an executable for machine X once.

Re:Badly researched?

[ivan256]

If you rebuild an executable for system X from a binary dump for system Y, you don't just disassemble it, but you put in macro's for all of the opcodes for system Y. These macro's are the glue that emulate parts of Y's hardware on system X.

That's a dubious claim at best. A rom image is likely to contain device driver calls that set register bits that have no equivalent on other hardware. In order to produce a single device operation, a series of opcodes is likely to be required that is guaranteed not to appear in the same order on all software for the platform, and may not even have an analog on the new platform. That means at the very least you have tailor your macros for every image, if not for sections of an image. In the worst (and most likely) case, procedures and algorithims comprised of hundreds of opcodes and used to manipulate hardware on the original system would be completely invalid on the target, and would have to be implemented completely differently. That's the same thing as porting the software, but with some extra steps added.

Their example in the article is perfect to illustrate this. After they converted the FM synth codes to sampled PCM data, do you really think the sound code from the original ROM came even remotely close to working? I call bullshit.

Furthermore, there is no evidence in the article that this project was actually attempted, much less completed. Even if it was, I would bet significant sums of money that their tools wouldn't work to translate other games from Genesis to Gameboy without as much work as went into the tools in the first place. If their techniques ever were to work, it's likely that it would only be while translating between two extremely similar systems. Did anybody with a clue at the ACM read this article before posting it?

Gain v Pain..

[adeyadey]

This methos is of genuine value for cases of applications where the source has been lost and needs alteration - for just running invaders/pacman/etc an emulator is just as good - since you have to slow things down to run at 100% original speed. The best emulators really o absolutely emulate every facet of the original CPU & hardware - the VICE C64/PET/VIC emulator runs on a 1mhz interupt, that, as I understand it, emulates all the states of the 6502 processor exactly. If you convert bin->asm->c you would still need to put hold-states in the C code to make it step at exactly that speed, cycle for cycle. Where this method would be better than MAME/VICE style emulation is when you need to patch the code- to upgrade it, fix bugs etc. This applies more to non-game type code where old (and failing) hardware/software needs to be migrated to new hardware, maybe with minor code changes.. And if you are not tied to executing at a set pace, then bin->asm->c is a really cool thing to have.

Let's see...

[Wolfier]

Emulation:
*Each assembly instruction interpreted by an interpreter
*Compile once to run N applications

"Translation":
*Each assembly instruction translated to a C macro
*Compile N times to run N applications

Looks like emulation wins. If an emulator has JIT then "translation" losses its only speed advantage too.

Re:These guys are hardly experts

[Salamander]

Programs that simply don't work right, that don't meet quality standards we'd apply to every other product category, is a perfect illustration of why the public at large views geek culture - that includes you, we're on Slashdot - as a bunch of overpaid lazy clods.

Mindless flames that make unwarranted assumptions (such as "propping up a can of mountain dew") are a perfect illustration of why the public at large and even the geek community views Slashdot - and particularly the anti-community of aptly named anonymous cowards like you - as filled with twats.

In the latter case, at least, they are right. You're in no position to criticize others' behavior.