|January 9th, 2009, 21:43||#1|
Join Date: May 2008
Location: Netherlands (GMT+1)
Dxbx FAQ - Last update : 2010-10-27 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: After alomst three years of hard work, we can finally say that we emulate our first few commercial titles!
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 not emulate much right now?
A: Nope. We do run many SDK samples, quite a bit of homebrew and a few commercial games (with varying levels of success).
We also have a few limitations with regard to the titles we support, more about this is explained below.
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, we have a website for Dxbx (http://www.dxbx-emu.com
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, none of which had a public release, nor did they run any title.
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've translated 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: How does Dxbx compare to Cxbx?
Cxbx supports more games right now, but Dxbx has a generic symbol-detection engine, which will enable us to eventually run more games.
Already, we run more SDK samples and homebrew than Cxbx. Also, we have better emulation of the Xbox1 graphics, as we emulate more render states. We also have reasonably working pixel shader emulation, much more flexible logging and have many bugfixes on top of our translation of Cxbx code.
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 is not only a GUI, it's also a loader for XBE's (the Xbox1 executable format)
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-officia...lity-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: We already have a very powerfull symbol detection engine, but it has to be improved some more in order to support more titles.
Also, we suffer from many sorts of glitches, especially in the sound and graphics departments; we're constantly working to improve this.
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 to get them all implemented sufficiently.
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.
Q: When does the new version of Dxbx will be released?
A: It will be released when we think its time to release a new version..
Last edited by patrickvl; October 28th, 2010 at 11:22.. Reason: Updated to latest revision (1258)
|dxbx, faq, xbox|