What's new

Using a hypervisor for xbox emulation?


New member
I have to admit that I don't know terribly much about emulation, but I think I could get into it with some pointers.
Anyway, I was wondering whether an existing PC emulator or hypervisor would help at getting an xbox emulated - but I guess emulating the GPU and sound devices would be too hard/not documented?

So I understood that cxbx is providing an implementation for the api calls, is this to be understood as a runtime like wine?


Local nut
Yeah, pretty much. Modern console emulators tend to use an emulation technique known as HLE (high-level emulation). This involves translating a system call made by the emulated system and replacing it with a similar native function call on the host system.

Basically, you'll have a recompiler pass through the code of the emulated system's executable, and whenever a syscall instruction is run into, it'll be replaced by the equivalent function in the output (recompiled code), which is then run natively on the host system. Since the XBox and PC both use x86 CPUs, it's more along the lines of Wine/a compatibility layer than emulation (at least on the CPU side), since code doesn't have to be translated from one ISA to another, only syscalls are dealt with.

Windows and XBox syscalls are very similar (and in many cases the same) so that makes translating XBox syscalls to their Windows equivalent more convenient.

The problem with using a hypervisor/virtualization is, like you said, the other components of the system that need to be emulated. I don't know if you can setup virtualization to work like that, I think you are only provided with general virtual hardware, or access to your system's hardware (I really don't know though, haven't dealt with virtualization much).

Anyways, if you're looking to get started in emulation, take a look at the CHIP8 thread. CHIP8 is the hello world of the emulation programming scene, it'll introduce you to the basic structure of an emulator, and shouldn't take long to get working (probably a couple days). The next logical step after that would be the GameBoy, SMS or NES. They'll get you introduced to the other main aspects of emulation and what systems are really like on a low level, ex. interrupts, MMIO, "realistic" video and audio systems, etc.

After that, well, you'll have to decide. Some people gradually step up the system complexity (SMS -> Genesis/Mega Drive, etc), others jump right to the more complex systems. Most of the techniques involved with emulating more modern systems can really only be learned by actually emulating or studying them, like the specifics of the graphics and audio hardware, since they're much different than the ones in older systems.

Hopefully I didn't make that too confusing, lol. If I have, just point out what you want to know more about, I'll try to help. I don't know exactly how much you know about emulation and systems on a lower level, but you seem to have the general idea.

- Chris
Last edited:


A lowdown dirty shame
For completion's sake, it's best to avoid emulating Xbox using HLE. Majority of inexperienced people tend to think that this is the magic solution to emulating this console. Trust me, it's not. HLE should only be used if emulating the hardware isn't possible or isn't feasable at the moment. In the early 2000s, emulating Xbox via HLE was perfectly acceptable. Now that we have a fair bit of documentation on most (not all) of it's hardware plus machines capable of emulating this hardware, LLE is a better alternative. On top of that, XDK/kernel functions (which are similar to Win32 APIs) don't always map 1:1 and often require a fair bit of hacking to get working properly and are often not well documented either. Furthermore, relying on what XDKs are available is a losing battle and games using LTCG (Link Time Code Generation) can't be HLEd so easily. A good LLE implementation would eliminate those issues. I've worked on Cxbx for quite some time, and these are some of the biggest issues stopping it from gaining any real progress these days.

As for using a hypervisor/virtual machine, that's not exactly a bad idea, but it's quite a bit of work. I've been looking into it for quite some time now, and it's not an easy thing to implement and would be rather time consuming. There isn't much information on writing a KVM (kernel virtual machine) driver so I had to search the net for various intel docs and a few obscure articles on this rarely discussed topic (ones with code and not just theory). It would be nice to give QEmu's core a try since it's both fast an accurate (from what I've heard). For my emu, I've been using libEmu to emulate x86. It's slow and buggy, but it works so far. I had a direct code execution method going, but I decided it was more work than what it was worth, so I ended up scrapping it in favour of a full blown software implementation. If you haven't already, feel free to check out my blog: http://xenoborg-emu.blogspot.com/

Also, read up on what JayFoxRox has been up to.


The hyper visor is what the PS3 used in system versions prior to 3+. Sony got rid of it because 'it was a lot of work maintaining it'. Knowing now what I do about there 'security' it seems they took a LOT of short cuts in the OS. All a hyper visor does is abstract the hardware from the OS technically it's a micro kernel architecture that is designed to prevent people from accessing the hardware directly, for security reasons (or in the PS3 so people couldn't do much with there 'special' hardware). The HV on the PS3 in particular was a set of code run in the CELL processor to handle things like the Ethernet adaptor etc. ( That is it was software operated, I can safely say this is likely one of the major sources for problems Sony had with the HV). A lot of the problems the PS3 has in general comes from bad arch design on Sony's part.

Back to the HV question, I will dig up some articles in ESD about them. This type of thing is used on a lot of Consumer products to prevent people from breaking things (or stealing things etc.)
Blue Ray players may use this a lot (LG BD390 comes to mind). They used a 'standard' OS (linux) that runs on top of this and by doing things this way they can prevent exposure of there hardware and design to unscrupulous people who want to copy it. (This is quite common unfortunately, I won't mention what 'market' does this.)