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."
They're in unary, you insensitive clod!
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.
-- "Can't sleep, clowns will eat me!"
RTFA, It is not Emulation, it is Translation. With Emulation you need an Emulator program on the target machine. With translation, the rom is converted to an executable that can be executed independent of any program on the target machine.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
printer-friendly, one page, no ads.
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...
Code, Hardware, stuff like that.
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.
They're talking about -altering- the source code of an application so that it will run on new hardware.
Not running the existing code through a software emulator on new hardware.
They are aiming to (for example) map the display instructions from Pacman on the Atari 2600, to x86 windows API display instructions.
They will also have to translate all game logic more times than not (to valid x86 logic instructions), and may have to alter the stored data in the event of differences in endian-notation.
The resulting translation will not suffer from the overhead emulators create.
Interestingly, I see this very feature as becoming one of their largest problems. pre-pentium-speed game programmers tended to rely on the clock speed of their original target hardware to set the update rate for the game. Trying to play frogger on even a 486 would be an impossible blur.
Timing control will be their biggest hurdle.
// "Can't clowns and pirates just -try- to get along?"
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.
"You lied to me! There is a Swansea!"
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!!