Here we attempt o answer the most common questions. Please click on a question to view the answer.
Dxbx is an Xbox1 emulator, written in the Delphi programming language.
For now, Dxbx requires 32 bit Windows XP (Vista and Windows 7 are not tested, and might give problems). 64 Bit windows is not supported (WOW64 is not tested, but likely won’t work anyway). On the hardware side, we’re not completely sure yet but a decent system (2 Ghz CPU, 1+ GB memory and a DirectX8 compatible video card) should suffice.
No. We’re building an Xbox 1 emulator.
Yes, we could. But we won’t – you could try it yourself though 😉
Yes, there’s Xeon – the first emulator to run the Xbox 1 game ‘Halo’ (that’s about the only thing it did however, and the project is dead since). Other projects that we know of are Xenoborg, XProject and IronBabel. And then there’s Cxbx: The only working open-source Xbox 1 emulator available. As a matter of fact, Cxbx is our main source of inspiration, are we’re translating it’s C sources to Delphi!
I heard you need official Xbox1 SDK’s (Software Development Kits) from Microsoft to be able to work on Dxbx, is this true?
No. Actually, we don’t use a single file from these SDK’s (or XDK’s as they are frequently called). We do use function-patterns derived from them however, see below.
Well, actually it does run Turok Evolution [PAL], although you’ll have to use another Xbox1 kernel DLL (see below, on Cxbx). Also our controller code is not yet complete, so apart from a few opening screens and an intro-movie, you won’t be seeing much.
At the current time of writing we cannot (let me emphasize this: we CANNOT) run anything yet. (It’s hard work, you know.) Of course, we’ll be keeping you up-to-date of our progress in the ngemu forums.
As we’re not using any classified information or restricted files, we believe we’re not violating any copyright or other law. If you feel there’s still a risk (or other problem) in the way we do things, please tell us.
It’s fun! We can learn a lot from a project like this, and we like the change of subject from our day-jobs. Plus, it’s a nice showcase for what you can accomplish with the Delphi language.
Same as Cxbx: We are building a High-Level Emulator (as opposed to a Low-Level Emulator). You could start by reading up on the various resources available on Cxbx progress page.
In LLE the actual hardware is (almost) completely simulated in software. Given enough processor power this would potentially result in a (very) good level of compatibility with the actual hardware. The problem however is, that every component of the actual Xbox1 must be emulated – that’s a HUGE undertaking, even when you could start with an existing code-base like VirtualBox. HLE works by running Xbox1 software natively on Windows, by impersonating to the application it’s running on an Xbox1. This requires a few tricks, and won’t be able to run everything, but it’s enough to emulate a few (and hopefully more than a few) games. Also, HLE is regarded as being a faster way of emulation than LLE.
This involves a few steps:
1) Dxbx converts the XBE (the Xbox1 executable format) to a windows EXE
2) This EXE is statically linked to our Xbox1 kernel-replacement DLL.
3) Our kernel DLL bootstraps the game by setting up a kernel thunk table and patching some library code contained in the executable with patches that solve the differences between Xbox1 and Windows.
4) Once the environment is set up, we call the original entry-point of the executable, effectively launching the game.
Now, hopefully we’ve done enough patching to make this work!
Well, for starters Cxbx is branched into 4 different versions already, and no-one seems willing to fold it all back into one do-it-all version. So one of our targets will be translating all the Cxbx branches into one Delphi version. Other area’s of improvement are: a more complete implementation of the Xbox kernel and more generic API detection.
Yes and no – Yes, eventually we’ll have to implement each and every API available in the Xbox1 kernel. But no, an actual implementation in the spirit of Wine or ReactOS is normally not necessary – lots of the API’s can be routed on to the Windows XP kernel – that’s the whole idea of HLE! But still, there are 379 unique API indexes in the Xbox1 kernel, so it’s still quite a bit of work.
Just like Cxbx, we have to do a bit of a trick to get software written for the Xbox1 to run on Windows. The main part is patching all functions that cannot run without the actual hardware present (think of the DirectX API’s for example). To patch functions, we first have to locate them. Cxbx contains an ingenious hand-crafted data-structure for this, but it requires an insane amount of (debugging) work to achieve good results. So in Dxbx we took another approach, and generate the needed data-structure automatically, using so-called pattern-files. This way, we get much more detailed information on the various functions linked into the game – and rather effortlessly too! Also, because we can detect the presence of named variables too, we don’t need any hard-coded logic to find them (like Cxbx has). Last but not least, having a fairly detailed map of the executable gives us the ability to produce stack-traces when something goes wrong (which is quite helpfull when debugging a crash).
Patterns (or rather: function patterns) are files that can be generated with a tool called IDA Pro. Pattern files contain enough information for us to detect tens of thousands of symbols (functions and variables) reliably. If you have access to IDA Pro and an XDK version we don’t have patterns for yet, than please: send them to us! (Again: not the XDK – it’s just the patterns we need.)
Sadly, no. Some games are using link-time optimization, which means that the library functions in-use do appear in the executable, but altered. This makes it very hard for us to pin-point them. Most likely Dxbx will fail placing most of the patches that should be in-place. The effect will be undeterminable, but most likely your game will crash.
We know of only one way around this: use a feature-complete LLE. None exists yet, though, so you’re out of luck. Might we suggest you use an actual Xbox1? 😉
LTCG stands for “Link Time Code Generation” – a technique that optimized an executable during the linking phase. A nasty sideeffect (for us) is that the resulting executable doesn’t contain the exact binary code, as was present in the original libraries.
This fact hinders our pattern scanning engine to such a degree, that we probably won’t find enough symbols that should be patched in order to run the game.
Sure, you could reverse engineer each of those titles and manually add symbol locations (like _SF_ did in Xeon to run Halo), but chances are that even then our patches don’t work anymore because of differences in argument-passing and whatnot.
So for now, we state officially that Dxbx won’t support LTCG generated titles. This paints a clear picture to the general public and gives us more focus on other areas. I’m sure you’ll understand this reasoning.
Quite possibly, yes. But apart from a few patterns for OpenXDK, we’ve written not a single patch for it, because right now our main priority is emulating XDK linked software. Once OpenXDK emulation becomes a reality, it would enable the testing Xbox1 homebrew on Windows, which is certainly a nice-to-have feature (in due time).
First, check the Dxbx status (see the second Question above). If we ever reach a state where we start running games, you might continue checking if your game uses link-time optimization (this information can be gleaned from an XBE dump – see below). If that’s not the case, maybe your could be made to run when we add a few patches – we’ll be needing your Dxbx log files to analyze exactly which patches are necessary.
Sure you can! Dxbx is an open-source project, so if you’re a Delphi programmer: Just grab our sources from sourceforge and start browsing our code. There’s lots of open issues to address, so you’ll surely find something nice to work on. And even when you’re not a developer you could help us out by supplying us with XBE dumps we don’t have yet.
The information contained in an XBE dump mainly tells us which games use what XDK version. This gives an indication of the feasibility of actually supporting this game. Especially when it uses an XDK version that we have patterns for, there’s a good chance we could provide compatibility for it some day. On the other hand: XBE dumps will also show us if a game is linked to link-time optimized libraries – we’ve already stated that Dxbx won’t be able to emulate these.
Lots of information can be gleaned from the Cxbx sources. Google helps a lot too. Also, various people contribute all forms of input to us: XBE dumps, documentation of Xbox internals, pattern files, etc.
First, try searching the Dxbx forum – there’s a good chance someone already talked about your topic. If that doesn’t help, post your question in a new topic, or send a private message or mail to one of the Dxbx developers (see the CONTACT US page).