x64 support?

Elkay · February 21st, 2009

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!

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.

**patrickvl** · February 21st, 2009

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...

Elkay · February 24th, 2009

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.

Nintendo Maniac · October 7th, 2009

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?

__________________

CPU: Athlon XP 2100+ OC'd @ 2GHz (lacks support for SSE2)
GPU: Radeon 9600 256MB AGP OC'd @ 420 core : 200 mem
RAM: 512MB DDR + 256MB DDR
OS: Windows XP Pro SP3

Last edited by Nintendo Maniac; October 7th, 2009 at 03:37..

**patrickvl** · October 7th, 2009

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.

chipsugar · October 11th, 2009

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.

February 21st, 2009	#1 (permalink)
Elkay Registered User Join Date: Feb 2009 Location: CT Posts: 2	x64 support? 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! 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.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

February 21st, 2009	#2 (permalink)
patrickvl Emu author Join Date: May 2008 Location: Netherlands Posts: 97	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...

February 24th, 2009	#3 (permalink)
Elkay Registered User Join Date: Feb 2009 Location: CT Posts: 2	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.

October 7th, 2009	#4 (permalink)
Nintendo Maniac Registered User Join Date: Aug 2008 Location: Northeast Ohio Posts: 108	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? __________________ CPU: Athlon XP 2100+ OC'd @ 2GHz (lacks support for SSE2) GPU: Radeon 9600 256MB AGP OC'd @ 420 core : 200 mem RAM: 512MB DDR + 256MB DDR OS: Windows XP Pro SP3 Last edited by Nintendo Maniac; October 7th, 2009 at 03:37..

October 7th, 2009	#5 (permalink)
patrickvl Emu author Join Date: May 2008 Location: Netherlands Posts: 97	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.

October 11th, 2009	#6 (permalink)
chipsugar Registered User Join Date: Jul 2003 Location: London, England Posts: 164	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.