News
Faq Status
Downloads
Translation guide
Frequently Asked Questions:
Dxbx FAQ - Last update : 2009-01-09 by PatrickvL
The latest version of this file can be found at
http://dxbx.svn.sourceforge.net/viewvc/dxbx/DxbxFAQ.txt
Q: What is Dxbx?
A: Dxbx is an Xbox1 emulator, written in the Delphi programming language.
Q: What's the current status of Dxbx?
A: 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 (http://forums.ngemu.com/dxbx-official-discussion/).
Q: So Dxbx does nothing right now?
A: Well, actually it does run Turok, 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.
Q: Where can I download Dxbx?
A: We're hosting the development on sourceforge
(http://sourceforge.net/projects/dxbx), where you can also download the
latest releases.
Apart from that, Shadow_tj has set up a website for Dxbx
(http://www.shadowtj.org/main/pages/projects/Dxbx.html) with some more
information that might interest you.
Q: I heard you need official Xbox1 SDK's
(Software Development Kits) from Microsoft to be able to work on Dxbx, is
this true?
A: 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.)
Q: Is this legal?
A: 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.
Q: Can Dxbx emulate an Xbox 360?
A: No - we're building an Xbox_1_ emulator - got that?
Q: Can't you start on an Xbox 360 emulator
instead?
A: Yes, we could. But we won't - you could try it yourself though ;-)
Q: Are there any other Xbox1 emulators?
A: Yes, there's Xeon - the first emulator to run the Xbox1 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 Xbox1 emulator
available.
As a matter of fact, Cxbx is our main source of inspiration, are we're
translating it's C sources to Delphi!
Q: Yeah, so what is Cxbx?
A: Read more about it on the Cxbx forum (http://forums.ngemu.com/cxbx-official-discussion/)
and Caustic's website (http://www.caustik.com/cxbx/index.htm).
Q: What requirements does Dxbx have?
A: 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.
Q: Why are you translating Cxbx to Delphi?
A: 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.
Q: How does the emulator work?
A: 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
(http://www.caustik.com/cxbx/progress.htm).
Q: I will, but what can you tell me about the
differences between HLE and LLE in a nutshell?
A: 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 (http://www.virtualbox.org/).
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.
Q: How do you impersonate an Xbox1 while
running on Windows XP?
A: 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!
Q: What are you hoping to achieve with Dxbx?
A: First, we are striving to achieve the same level of game-compatibility as
Cxbx has (see http://forums.ngemu.com/cxbx-official-discussion/95026-cxbx-compatibility-list.html
for details).
Once that milestone is reached, we have all intentions to improve upon it.
Q: What improvements are you planning for Dxbx?
A: 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.
Q: Are you really implementing the whole Xbox1
kernel again?!
A: 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.
Q: What do you mean with 'generic API
detection'?
A: 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).
Q: What can you tell me about those
pattern-files?
A: Patterns (or rather: function patterns) are files that can be generated
with a tool called IDA Pro (http://www.hex-rays.com/idapro/flirt.htm).
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.)
Q: Will function-patterns enable Dxbx to
ultimately emulate every game?
A: 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.
Q: How can I run games that use this
problematic link-time optimization?
A: 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? ;-)
Q: What about (homebrew) software using OpenXDK
- can that be emulated too?
A: 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).
Q: I'm trying game XYZ, but it doesn't work!
What now?
A: 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.
Q: Can I help Dxbx?
A: 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.
Q: What's the use of those XBE dumps?
A: 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.
Q: How do I contribute an XBE dump?
A: You can use one of these methods, all will produce compareable output:
Cxbx - Start it, open an XBE, choose menu option "Edit | Dump Xbe Info To...
| File..."
Dxbx - Start it, open an XBE, choose menu option "Edit | Dump xbe info to |
File"
XdkTracker - Start it, choose menu option "File | Get XDK Info from Xbe"
Now you have dumped your XBE, send the resulting file to us and we'll add it
to our growing archive.
Q: Where are you guys getting your information
from?
A: 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.
Q: I have another question that's not on this
list, what can I do?
A: 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 PM or
mail to one of the Dxbx developers.