Next Generation Emulation banner

1 - 6 of 6 Posts

·
Registered
Joined
·
2 Posts
Discussion Starter #1
I've been getting errors trying to use Cxbx and I think I've narrowed it down to it not being compatible with 64-bit Windows. All of my PCs run x64 so I don't believe I can currently check out what you guys have been up to (unless there's a workaround that hasn't been posted). I tried exporting the executable and setting various compatibility settings on it to no avail. Do you have any plans to support this and is it any kind of priority to do so? Not asking for a timeframe, just wondering if it's something I should be looking forward to or if there's no bother checking back often for updates. I have an original Xbox and all of my games legit so it's no big deal, I'm just a big emulation fanboy! :thumb:

Btw - willing to test any x64 builds you might want checked out, I have a dedicated "oops that wiped my O/S" partition because I'm a developer myself. :cool:
 

·
Registered
Joined
·
423 Posts
Cxbx uses LDT (Local Descriptor Tables) to make it possible to have a separate TIB (Thread Information Block) for the Xbox-side of the emulator (Cxbx switches between a native and Xbox version of this constantly). LDT is not available on x64, so that's why you won't be able to run it on 64 bit Windows.

There's a possible work-around, but no-one has ever submitted a patch for this; The general idea is to patch all game-code that references the Xbox TIB (by way of relative addressing of the FS-register, mainly) and alter that code to be able to run on the win32/WOW64 TIB. If you're up to it, I can give you a head-start with part of a working prototype that was done a while ago...
 

·
Registered
Joined
·
2 Posts
Discussion Starter #3
Haha thanks for the offer, but I write business apps in VB. Been writing software for close to 20 years, just never really had a need to dive into C other than a few tiny projects for classes years ago. Now might be a good opportunity for me to start checking it out. I use Visual Studio 2008 so I already have everything I need to get started. Give me a couple months to get familiar with it in my spare time and I'll be back in touch.

Btw, already did some reading up on LDT/GDT/paging. Interesting stuff. Also makes sense why LDT isn't supported on x64. Now I know why we had all that memory manager stuff back in the DOS days. :)
 

·
Registered
Joined
·
376 Posts
While an old thread, I figured it's better to post here than start a new one of the same topic.

So, LDT. After reading up on it, it appears to be a feature of mainly 16 bit CPUs before paging (which is supposedly faster and more efficient) was introduced by the 386, which is definitly older than the Pentium III-based CPU used in the Xbox, so I wouldn't imagine the Xbox itself would natively use LDT much or at all.

So then could you go more into detail of why LDT was used in Cxbx, even though it would appear that there a better alternatives?
 

·
Registered
Joined
·
423 Posts
Using LDT is just a means to an end - there's no other way to create our own TIB (ThreadInformationBlock, the structure behind the FS-register). This alternative structure is needed because of little differences between the XBox and Windows version of this structure, which makes it error-prone to run Xbox FS-using code natively.
 

·
Registered
Joined
·
174 Posts
I'm curious on one point. I may be mistaken on this but on a technical level would it be possible to create a virtual machine for Cxbx but with qemu/VirtualPC style cpu acceleration? As I understand it it may then technically be possible to pass out/patch the api/kernel calls to the host and to DirectX in the same way that it does already.

Would making Cxbx more of a virtual machine make problems like the LDT/TIB 64bit problem more overcomable? If so what problems would there be (apart from a major rewrite of Cxbx)?

I'm just asking this hypothetically out of curiosity and not suggesting it as a course of action.
 
1 - 6 of 6 Posts
Top