The most common question to cause flames and debate, along with the occasional enlightening insight (good or bad), is:
Can I play PS2 (or Gamecube) games on my Xbox?

The simplest answer to this is:
No.

I've seen people suggest anything from "it will happen, you just wait and see" to "just rename the PS2 files with an XBE extension and run them". In the case of the latter, when the guy was laughed into oblivion, he responded back that it was worth a try.

In this page I will try to illustrate why "just waiting for it" and "renaming the files" are not viable options. I will also attempt to demonstrate how an emulator works, and thus its limitations, to an audience not familiar with the mechanics involved. In other words I'm writing this for all the people new to the scene who ask for a PS2 emulator, and for all those who know why and are tired of answering the question.

Without further ado, lets dive in!

An emulator, whether it be to play games written for an older console on a different machine (MAME for example), or to run an entire [non open source, thus non portable] operating system on a non-target (non ported) platform (VMware and Soft Windows), performs the same basic function. Using multiple instructions available in the instruction set of the host platform to execute instructions from the target platform that the host does not provide.

In a nutshell that means the following: If I am running an old game on an old Motorola 68K CPU and the game was coded with the memory mapped architecture of that CPU in mind, then I will access the sound card as a memory read and write. The soundcard exists as a byte (or word if needed) of ram in a large memory map. In this CPU architecture there is no separate I/O and Memory space. Everything acts as memory.

Now imagine that I want to run that same game on a newer hardware platform based on x86 architecture. In this case I have a memory space and an I/O space. If I want to access the sound card and were to issue the memory read/write commands I would not only not access the sound card as intended, but I would also likely corrupt a memory address and cause a kernel panic (Blue Screen Of Death for Windows users). What I need is something to trap the instruction to read or write to the sound card and convert the memory read to an I/O read.

Enter the emulator. The emulator runs as an application on the host system. In turn the emulator acts as a "virtual system" which runs the code for the target platform. In the case of MAME there is no operating system per-se on the target system because the games were compiled to run exclusively on the processor. In the case of VMware you actually can boot the Windows OS and then run windows dependant applications.

At this point I want to make an important distinction about emulators. The emulators used for games are hardware emulators, while VMware emulation is predominately software emulation. A hardware emulator is (usually) used to run code on a platform for where a port is not available, a software emulator will let you run an application on a host OS for where a port is unavailable (i.e. running M$ Word on Linux using WINE).

Why all this means a PS2 emulator will not exist on the Xbox.

When emulating a system you are using multiple host machine instructions to execute one target machine instruction. How large this ratio is depends on how divergent the two machine architectures are. For example, if you are trying to emulate a 80486DX CPU on a Pentium4 based computer so that you can play an oldie but goodie game that is unplayable on the new hardware (due to a lack of maximum clock locking on the old game it now runs at 1000+FPS and the sound is more like rebar on a grinder than multi-tone beeps), then your emulation task is very easy. In this case the instructions themselves are pretty much identical and you may only need to "present" 33 clock cycles to the target game for every millisecond of real time, divided evenly over that millisecond. Things get more complicated as your processor becomes more divergent. In the case of our Motorola 68000 MAME example you may need four to six host instructions (on average) per target instruction. Lets say the target runs at 8MHz. Some math yields:

8,000,000 * 6 = 48,000,000

so we need to have a processor that is at least 48 MHz in order to get in the average number of instructions done in time to properly emulate the target. In reality you often need to support the peak number of instructions, not the average, but hey this is just an example right?

Fast forward to the PS2. Here is a quote from a Wired article that a quick google for "sony PS2 +processor" turned up:

So as we can see this architecture is significantly different from our host system (an x86 32 bit platform). Some quick math assuming we keep with our average based computation and 6 host instructions per target instruction, while not accounting for the fact that each PS2 instruction register is 4x the width of an x86 register:

294,000,000 * 6 = 1,764,000,000

So that means we need a 1.7GHz processor, or one that is over 2x the power of the PIII in the Xbox. I am not a game or emulation developer, so I can not tell you how far off or close this is, but I have a feeling that more horsepower than that even is needed to emulate the PS2 successfully (remember we have not accounted for the 128 bit Vs. 32 bit difference in platforms yet!)

No amount of waiting will change the significant architectural differences between the Sony "Emotion Engine" CPU and the "normal" x86 architecture, so the poor chap who said "wait for it" is out of luck.

As for the guy who suggested that we simply rename the files to have an XBE extension, I'll leave that as an exercise for the reader to figure out.

How to configure an emulator:

Ok, so now that we (hopefully) understand how emulators work, I'll walk you through setting up my two favorites: Stella and MAME.