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."
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.
It is emulating, as they themselves say:
Providing faithful emulations of video games (and old home computers) is our primary experience with this process. But the same techniques can be applied to other areas. Aging hardware and software can be replaced by new hardware with a completely compatible program.
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?"
Server is spewing intermitant database errors so:
What if you have to port a program, but all you have is a binary?
Bridging the Gap
Typical software development involves one of two processes: the creation of new software to fit particular requirements or the modification (maintenance) of old software to fix problems or fit new requirements. These transformations happen at the source-code level. But what if the problem is not the maintenance of old software but the need to create a functional duplicate of the original? And what if the source code is no longer available?
This exact problem arises when trying to reproduce the original play of old arcade games on modern devices. The game play is so well known that anything short of the original is unacceptable. Often the source code is available, but it may be incomplete and may not cover all of the patches that were added to later production models. In addition, it is too expensive to provide copies of the original hardware.
Providing faithful emulations of video games (and old home computers) is our primary experience with this process. But the same techniques can be applied to other areas. Aging hardware and software can be replaced by new hardware with a completely compatible program.
BRIDGING THE GAP
The general problem can be expressed as "bridging the semantic gap." You must create a program that precisely maps the meaning of the original program onto a host system. Primarily this means an interpreter of some kind for the target processor's instruction set, but one must also deal with I/O (input/output) devices. Such an interpreter is known as an emulator. (See "The TRS-80: A Simple Emulator" on page 54 of this article.) If the program is automatically converted to a different language, it is called a translation.
Why are we tackling the problem at such a low level? Mainly to achieve the highest fidelity possible to the original. Emulation is about mapping semantics. The semantics of hardware are usually well documented either by circuit diagrams or chip-specification documents. Internal layers inside software are usually designed to much looser standards, so it is unlikely that specification documents--if they exist--completely describe the behavior. In fact, the software itself is the most authoritative description available. It is true that chip specifications are not always complete or accurate, but chips are reused and over time the deviations become widely known.
The semantic gap between the target and host systems is not purely an abstraction. It can be quantified as follows: G = number of host instructions to emulate one target instruction. Given G and some idea of the relative speeds of the host and target system, you can quickly decide if emulation is feasible. The problem here is that the value of G is a function of an actual emulator. A rule of thumb is that G is at least 10, but practically speaking, 10 is lower-bound for systems that are quite similar. Although time is usually the overriding concern, there is an analogue for a semantic gap in terms of storage space.
Figure 1
Emulation and translation start with the same inputs (the ROM data and the hardware documentation) and produce the same result: a copy of the original running on a PC. The difference comes in how the ROM data is handled. For the emulator, it is simply a parameter to the program. For the translated version, the ROM is converted and compiled into the executable.
The semantic space gap is the ratio of the size of the host program to the size of the target program. For an emulator, the host program size is broken into two pieces: the host's representation of the target program and the emulator code and associated tables. Unless the host and target are radically different, there is little to be gained by significant changes to the representation of storage. Thus, if the emulator code is ignored, the semantic space gap is typically exactly one.
Intuitively, the value of G really depends on how differe
i think the point is maybe if they port it they can modify it and make it better? At any rate PS III reminds me of the precursor to PSO.
This Link dispells the myth about the SNES using AppleIIgs hardware. Kujo2K
Then check out digger. Originally written in 1984 by a now defunct game company, this guy disassembled the game and rewrote it. I can't find any differences in the game play (I played it all the time as a kid on my 8088 *memories*). The person who rewrote the game tried to find the original writers of the game but came up with nothing.
He motivated me to rewrite another one of my old favorite games, Pango... though I haven't got very far
-dk
Because it's one they actually did. Phantasy Star 1, 2, and 3 got ported over to the GBA as a Phantasy Star Collection.
That was an interesting post... you just overquoted the parent. In binary. Actually, that *is* an interesting twist!
This binary converter may be useful for those not "in" on the joke.
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
... some mook sitting in a chair propping up a can of mountain dew with his belly thinks that dissing the free (as in beer), well intended, open-hearted work of someone else (did you really *suffer* through the joust port? poor baby) earns him some cool. please.
yeah yeah, you've got a grasp, but so what?
pounding on someone's efforts ("inexcusable" coding on a port of a 20 year old arcade game, that you can then sit and poke at, all day, for free, and even get the hi-score on) and then sneering down your nose at them is a perfect illustration of why so much of the public-at-large views geek culture as filled with twats.
it's also a demonstration of why they're right.
Remember, all custom chips have reliable inputs and outputs
Are you kidding? We're not talking about LEGO toys like the IBM PC or Tandy. Machines like the C64 and Amiga have autonomous, cycle-exact digital/analog hybrid custom chips which all have control over each other and can perturb or feed each other.
I have anti-debugging code on the Amiga that starts a blit (block image transfer -- copy with automatic shifting and minterm logic) to perturb some code while it's executing. While the blit takes place, the high-precision timer in the CIA-B chip triggers a level 6 68000 interrupt which changes the parameters of the blit as the blit is in progress. The exact memory locations changed by the blit are affected acutely by the number of cycles the 68000 spends on each instruction. Even the slightest inaccuracy in emulated (or real) execution time will corrupt the blit's effect.
This cannot be transliterated as a single stream of C code. It relies on cycle matching of discrete systems working in parallel. It can only be executed through a state machine that would effectively emulate the full function of all these devices.
More importantly, this is not what needs to be done. In copying full systems (and not just programs with very simple I/O that can easily be replicated), human ingenuity is necessary. One large system simply can't do the same as another entirely different system without heavy hardware or software changes. In many cases, when a downward step in hardware is made, functional equivalence is impossible. It's like saying "display a 256 colour image on a 4 colour display". All you can do is make a 4 colour image that looks like the 256 colour image.
As seen in so many arcade game ports to the Amiga/Atari/PC home systems, a home computer can't hold 16Mb game ROMs, everything needs to fit on a 800-1400Kb disk. Imagine converting a 1990 arcade game to the home systems. An Amiga circa 1990 has custom blit hardware (so it can have quite large sprites/bobs) and free raster effects, but only 32 colours. The graphics must be redrawn, the 256 colour originals can't be used directly. A PC circa 1990 has 256 colours, but no sampled sound output and has to use a slow CPU for blitting. An Atari has neither 256 colours nor custom hardware.
In many cases (for example, the Gameboy Advance conversion of popular PSX/PS2/N64/GC games), a completely different game is used instead, only keeping the basic concepts of gameplay and the characters and storyline.