patrickvl
May 22nd, 2008, 11:01
Because some might not know this here a link explaining how Xbox-emulation has been done on the Xbox-360 : On Backwards Compatibility (http://blogs.msdn.com/xboxteam/articles/On_Backwards_Compatibility.aspx)
Interesting :
Our software emulator works much like emulators for other platforms like SNES and Genesis.
The goal and design of emulation is pre-ordained: do whatever it takes to act like what you're emulating.
At some point, your first attempt at emulation acts like the old hardware as well as it can. At that point, you try your luck: does Halo run? The answer is both yes and no at this stage. Yes, the executable loads and starts running some x86 code, but no you don't see anything on the screen. Then it promptly crashes.
We typically have neither source code nor symbolic information for the games we’re debugging, so we’re just looking at raw assembly code with no external clues as to what it’s doing (or what it’s supposed to do). Obviously debugging code others wrote is always harder than debugging code you wrote yourself. It’s hard to know what the code normally does, and indeed some games already have a few bugs of their own. Debugging a mixed environment -- both the emulated Xbox (x86 assembly in one address space) and the translated native code and emulator runtime (PPC code in another address space) – can also be challenging. You have to master a lot of aspects of both the original Xbox (hardware, compiler, and operating system) and the Xbox 360.
Luckily, backwards compatibility doesn't need to emulate things exactly right. One of the biggest problems in emulation are exceptions. Exceptions are interrupts that occur when something unexpected happens. For instance, dividing by zero, accessing memory you're not supposed to, etc. all raise exceptions. There are very few exceptions that video games care about. Many times, they will completely ignore them. When an exception occurs, many games simply crash or exit. Backwards compatibility on Xbox 360 exploits this common behavior - as well as other common patterns.
BC performance work differs from typical software performance work in only two ways. First of all, emulators do some highly specialized things -- like interrupt handling and very low-level memory management -- that most software programs (other than operating systems) never do. Secondly, it’s not usually the performance of the emulator itself that matters, but rather the overall performance as perceived by the emulated Xbox game. Most of our work isn’t to improve the performance of the code we wrote, but rather to improve the performance of the emulated games. Overall, we approach performance in the same way that all software developers do: Measure, make a change, and measure some more.
PS : Also read Microsoft's backwards compatibility FAQ (http://www.xbox.com/en-US/games/backwardcompatibilityfaq.htm) and Wikipedia's angle on this (http://en.wikipedia.org/wiki/List_of_Xbox_games_compatible_with_Xbox_360).
Interesting :
Our software emulator works much like emulators for other platforms like SNES and Genesis.
The goal and design of emulation is pre-ordained: do whatever it takes to act like what you're emulating.
At some point, your first attempt at emulation acts like the old hardware as well as it can. At that point, you try your luck: does Halo run? The answer is both yes and no at this stage. Yes, the executable loads and starts running some x86 code, but no you don't see anything on the screen. Then it promptly crashes.
We typically have neither source code nor symbolic information for the games we’re debugging, so we’re just looking at raw assembly code with no external clues as to what it’s doing (or what it’s supposed to do). Obviously debugging code others wrote is always harder than debugging code you wrote yourself. It’s hard to know what the code normally does, and indeed some games already have a few bugs of their own. Debugging a mixed environment -- both the emulated Xbox (x86 assembly in one address space) and the translated native code and emulator runtime (PPC code in another address space) – can also be challenging. You have to master a lot of aspects of both the original Xbox (hardware, compiler, and operating system) and the Xbox 360.
Luckily, backwards compatibility doesn't need to emulate things exactly right. One of the biggest problems in emulation are exceptions. Exceptions are interrupts that occur when something unexpected happens. For instance, dividing by zero, accessing memory you're not supposed to, etc. all raise exceptions. There are very few exceptions that video games care about. Many times, they will completely ignore them. When an exception occurs, many games simply crash or exit. Backwards compatibility on Xbox 360 exploits this common behavior - as well as other common patterns.
BC performance work differs from typical software performance work in only two ways. First of all, emulators do some highly specialized things -- like interrupt handling and very low-level memory management -- that most software programs (other than operating systems) never do. Secondly, it’s not usually the performance of the emulator itself that matters, but rather the overall performance as perceived by the emulated Xbox game. Most of our work isn’t to improve the performance of the code we wrote, but rather to improve the performance of the emulated games. Overall, we approach performance in the same way that all software developers do: Measure, make a change, and measure some more.
PS : Also read Microsoft's backwards compatibility FAQ (http://www.xbox.com/en-US/games/backwardcompatibilityfaq.htm) and Wikipedia's angle on this (http://en.wikipedia.org/wiki/List_of_Xbox_games_compatible_with_Xbox_360).