cxbx-reloaded / cxbx-reloaded

Xbox (Original) Emulator

Cxbx-Reloaded - Original Xbox Emulator

Cxbx-Reloaded is an emulator for running Microsoft Xbox (and eventually, Chihiro) games on Microsoft Windows and Wine.

System Requirements

Minimum

• OS: Windows 7+ x64, or x86-64 Linux with Wine. 32-bit is not supported.
  • MacOS with Wine is known not to work, and BSD-based systems are untested.
  • Also note that Wine is relatively unstable, and it might break compatibility with Cxbx-Reloaded at any time without warning.
• GPU: Direct3D 9.0c with Pixel Shader Model 2.x, and Vertex Shader Model 3.0.

Prerequisites

Windows

• 32-bit (x86) Visual C++ 2022 Redistributable
• Npcap (used for network emulation)
  • Make sure to enable winpcap compatibility mode.
• WinUSB compliant driver
  • Optional, only needed for USB pass-through of original Xbox and Steel Battalion controllers.

Wine

Please use the latest stable release version of Wine. If it does not work for you, then roll back to Wine 7.0 which is the last known working version.
There also exists this known issue which currently prevents savings in some games with the most recent Wine 6.8 and later versions.

• Winetricks
  • vcrun2019
    • Requires the latest winetricks script.
  • d3dcompiler_47
    • This may be subject to change.
• Winpcap is built-in, no installation is required.

Automated Builds

Cxbx-Reloaded doesn't currently have stable builds, but you can obtain pre-release builds from our official website's download page, or the links below:

• Release Builds
• Full build history

Compatibility

Cxbx-Reloaded has a compatibility list.

If you would like to submit compatibility reports, please request permission in our Discord server.

Bug Reports

Game or software specific issues can be reported in the compatibility website.

For emulation issues that are not specific to any single piece of software, a bug report can be submitted at the Cxbx-Reloaded issue tracker.

Additional information

Cxbx-Reloaded has a wiki containing various subjects and background information.

Chat on Discord.

Contributing

We welcome contributions, large and small.

If you want to do some coding, be sure to read the Developer notes.

IMPORTANT: Pull-Requests containing code derived from XQEMU will not be approved until an agreement is reached to make work mutually beneficial. This includes updates to existing XQEMU derived code. We should not/will not become a hostile fork.

Please contact us before you start working on something, so we can make sure your work is going to be accepted once finished.

Main Prerequisites

1. Git for Windows
2. CMake
   • Some IDEs already have CMake support, this is optional.

Fetching the code

1. Run the following command in the command line:
   git clone --recurse-submodules https://github.com/Cxbx-Reloaded/Cxbx-Reloaded.git
   • Please note the --recurse-submodules parameter. This is required to fetch submodules.

     • If Cxbx-Reloaded was checked out without submodules, they can be updated/fetched with the following command:

       git submodule update --init --recursive

Compiling

Windows

Don't open CMakeLists.txt from Visual Studio, as it won't generate files in the build directory.

Prerequisites

1. Visual Studio 2022
   • C++ and C# desktop development
   • Windows Universal CRT SDK
   • C++ CMake tools for Windows
     • Optional if CMake is installed
   • Microsoft Child Process Debugging Power Tool

Generate Visual Studio files

1. If you don't have CMake installed, open ___ Native Tools Command Prompt for VS 20##.
2. cd to the Cxbx-Reloaded directory.
3. Run these commands.
   1. mkdir build & cd build
   2. cmake .. -G "Visual Studio 17 2022" -A Win32
      • VS2022 17.0 or later is required.
4. Open Cxbx-Reloaded.sln from the build directory.
5. Select the Release configuration, then click Build.
   • Debug builds are significantly slower, and only for developers.

Linux / macOS

Currently not supported.

Support

You can support Luke Usher, initiator of Cxbx-Reloaded, on Patreon.

Special Thanks

• All contributors to the original Cxbx and Dxbx projects. Without them Cxbx-Reloaded would not exist at all.
• XQEMU - While the majority of Cxbx-R is our own work (Kernel, HLE, etc), the NV2A LLE and NVNet implementation are primarily the work of the XQEMU developers.
• XboxDev - Providing Xbox hardware research & useful tooling.
• XbSymbolDatabase - Providing support to detect symbols across XDK builds from reverse engineered retail titles.
• Xbox Kernel Test Suite - Making accurate tests on hardware to compare against cxbxr's kernel implementation.

cxbx-reloaded's Issues

Implement the entire kernel

All kernel API's need an implementation that matches the Xbox behavior.

One goal is to update all Nt prefixed functions that are currently implemented, to make use of the Ke and Obj prefixed kernel functions.

Title Screen - The Fairly OddParents: Breakin' da Rules

Fun fact - first game that I have ever booted up on xbox emulator.
Build from 2 weeks ago (and any before) crashes immediately.

Here is xbe file:
FOP.txt

Extend debug logging

Add a logging mechanism that can convert integer values to string representations of their respective data types.

There are numerous flag types, mask values, magic numbers, memory address, etc, that could be rendered as a string.

Especially if these strings match the symbols that are used in code, log messages become much more valuable when doing research into what the original code that triggers these log messages is doing.

It's possible for these string renderings (of values of known types) to automatically kick in everywhere they are applicable, without having to update all logging code.

Formulated differently: Each new type added to this design should automatically be used by the existing logging code, without any changes to the individual log message calls.

The new LOG_FUNC and LOG_ARG* macro's are the way forward for now.
We 'just' need some more formatters...

b61e2f8 fixes :

• Convert non-printable data into something sensible

This leaves us with :

• Complete render methods for all used xboxkrnl types (there's been a bit of work done on this already)
• Prevent processing out of bounds data (done in #1636)
• Determine if and how to render nested types (never enter a cycle!)
• Indentation of printed values
• Filter settings for often hit functions, entire sections, etc
• Option to place Kernel Log in XBE path.
• Command Line arg for Log path/Method (Console|File)

Get XMountUtilityDrive to run unpatched

Our goal is to get rid of as many patches as possible. This one, XMountUtilityDrive, is a valuable candidate

Config options for LLE/HLE sound and graphics

LLE is about to start for both sound (APU) and graphics (GPU), but we don't want to delete our HLE just yet.

So, we need a switch in the GUI for both sound and graphics, choosing between HLE and LLE.
This switch needs to be transferred to our CxbxKrnl.DLL, and be put in bLLE_APU vs bLLE_GPU (which were introduced recently).

Default should be HLE for both.
Choosing LLE is purely for development purposes, so these switches might as well only be available in DEBUG builds...

Cleanup OOVPA Tables

The OOVPA tables in their current form are very prone to errors.
The definition of symbols should be simplified via Macros to reduce the chance of mistakes.

Allow the user to configure Xbox settings, such as connected AV Pack, Region, etc

Currently all the values returned by ExQueryNonVolatileSetting are hard coded.
The connected AV Pack is also hard coded to HDTV.

The user should be able to change these settings somewhere in the Cxbx-Reloaded UI, Additionally, settings changed via the Dashboard/ExSaveNonVolatileSetting should be preserved.

XLoadSection XUnloadSection Unimplemented.

I encounter this from time to time, and it looks like it functions as follows:

XLoadSection(pLSTR):
-find section in XBE, using pointer to string.
-Load section in memory
-Return pointer to address

XUnloadSection/XFreeSection(pPointer):
-Clear memory

EmuD3DDeferredTextureState FatalError

I keep getting "*EmuD3DDeferredTextureState was not found!" error on alot of xbe's I try to run.

Ability to detect kernel API usage per executable

It would be handy if we could have an overview somewhere that shows test-cases per kernel API.

This makes it easier to test an kernel API separately, to determine how well it is supported.

Log sanitize chars

Logging char and char * should generate output that could be pasted directly in code.

Thus, unprintable chars (!isgraph) should be shown using the backsplash escape character and accompanying encoding.

A single char should be surrounded by single quote chars, if a single quote is rendered, it should be be backslash-escaped.

A char * should be surrounded by double quote chars, if a double quote is rendered, it should be be backsplash-escaped.

A char * render should be broken off at some point if no zero terminator is encountered until then.

The same should be done for wchar and wchar*.

Export Exe Not Working

*Close me*

remove exe conversion remnants

• Method 1:

Steps:
1. Start up Cxbx
2. Open XBE
3. Export Exe
4. Run Exe

Result:
EmuMain (0xXXXX): Recieved Fatal Message:
* Could not map

This error is also thrown if running without Cxbx running.

• Method 2:

Steps:
1. Go Back to Cxbx, and start emulation
2. Run exe

Result:
<Alias>.exe has stopped working
[Debug] [Close program]

• Method 3:

Steps:
1. Stop Emulation
2. Run Exe

Result:
Same result as method 2
Upon returning to Cxbx, emulation was started again.

• Method 4:

Steps:
1. Close and ReOpen Cxbx
2. Run Exe

Result:
Same as Method 1

• Method 5:

Steps:
1. Load XBE
2. Run Exe

Result:
Same as Method 1

• Method 6:

Steps:
1. Start Emulation
2. Run Exe

Result:
New Window opens, then same result as method 2

• Method 7:

Steps:
1. Stop Emulation
2. Run Exe

Result:
Same result as method 6

lol, Does not seem to work in any scenario. Where as in Blueshogun's version, the exported exe has the same icon as Cxbx, and works in standalone. The reason I did so many different tries, is that I found on other builds, when starting then stopping the emulation before running the Exe, the Exe would start the emulation in the existing Cxbx instance.

Fix ExQueryNonVolatileSetting

This function implementation contains a lot of hard coded offsets and values, we really should implement a data structure to represent the emulated EEPROM and read/save values from there.

This also opens up the possibility of persisting these settings when they are changed.

Quantum Redshift - Crash on title screen

tested on 988e2fc
I follow the message that I pressed the start button, however nothing happens.

IoCreateSymbolicLink: "Could not map" error (in Avalaunch)

Testing various 3rd party dash files, keep causing this error. there is the tail of the krnl log:

EmuMain : Linked "\??\t:" to "\Device\Harddisk0\Partition1\TDATA\080299ff" (residing at "C:\Users\Biatu\AppData\Roaming\Cxbx-Reloaded\\EmuDisk\Partition1\TDATA\080299ff")
EmuKrnlPs.cpp (0xE68): IoCreateSymbolicLink returns 0
EmuKrnlPs.cpp (0xE68): IoDeleteSymbolicLink(
   SymbolicLinkName          : 0x0F76EC00 -> PSTRING {
   .Length: 6
   .MaximumLength: 7
   .Buffer: \??\W:}
);
EmuKrnlPs.cpp (0xE68): IoDeleteSymbolicLink returns -1073741772
EmuKrnlPs.cpp (0xE68): IoCreateSymbolicLink(
   SymbolicLinkName          : 0x0F76EBF0 -> PSTRING {
   .Length: 6
   .MaximumLength: 7
   .Buffer: \??\W:}
   DeviceName                : 0x0F76EBF8 -> PSTRING {
   .Length: 52
   .MaximumLength: 53
   .Buffer: C:\C:\Users\Biatu\Desktop\Emuz\Cxbx\Avalaunch.0.49.3}
);
EmuMain (0xE68): Recieved Fatal Message:

* Could not map C:\C:\Users\Biatu\Desktop\Emuz\Cxbx\Avalaunch.0.49.3

Originally had this running on a Ramdisk at the root of the drive cause I though it was a path length issue, but this was not the case as I got the same error.

MK Deception crash

Mortal Kombat crashing with exception in Cxbx-Reloaded b7f4b23(24 Dec 2016).
Part of log:
EmuMain (0x990): Recieved Exception (Code := 0xC0000005)
EIP := 0x10047E56 EFL := 0x00010212
EAX := 0x00000000 EBX := 0x00000000 ECX := 0x0000002E EDX := 0x0000002D
ESI := 0x089DF250 EDI := 0x00000000 ESP := 0x089DDD10 EBP := 0x089DF23C
CR2 := 0x00000000
EmuMain (0x990): Aborting Emulation

Why I think that is issue - at 791f885 (23 Dec 2016) MK boots until start menu (without graphics but with sound). Second run - error with trying dashboard loading. Cleaning of folder "AppData/Cxbx-Reloaded" will fix it, next try will also lead to start menu, next - boot dashboard,etc.

* IDirect3D8::CreateDevice failed (Invaild Call)

When i start the game [IronPhoenix], a few seconds i get a message:
CxbxKrnl
EmuMain (0x1218): Recieved Fatal Message:

• IDirect3D8::CreateDevice failed (Invaild Call)

There're xbe info and Debug console infoes below:
`XBE information generated by CXBX (Version 0.8.1-Pre3)

Title identified as "Iron Phoenix"

Dumping XBE file header...

Magic Number : XBEH
Digitial Signature :
A44791757C2E9EBA1066A17D0E5A2716
7D22A3CA83891BBB1A4AA88FBFA4EA85
D9BF986C149E1978A53E00C7C3ADD490
9F38CC10BE59BD96A863CF1ECC28EB03
158F52FF5B88A76F274622CB1FCEEC6F
E01D58E368F2BA1D0D899AC951B41888
7BB9A6483F16D344C4F8B5A36D43170D
097AE13986BE3E0736D38838A3C76F8C
3A5A4AC8595182D3D03139E4517CAA54
0096F8BFE41790114B26404BE7F4002D
BB1B001B40C94AED2DF6D3FB21211848
97E7A8AD8B09A0C73E0A93AAACE6E03C
000135A1DE53DEB91BDFDF1F1FDEC169
3327DCE420CF1116FBB8FB5713A83FEE
6788D2833125D77A6DF72DF01EEBAF2D
EB807C4DE74FB91909FB2924FB859D22
</Hex Dump>
Base Address : 0x00010000
Size of Headers : 0x00000BE4
Size of Image : 0x0049DDE0
Size of Image Header : 0x00000184
TimeDate Stamp : 0x41E20D53 (Mon Jan 10 13:06:27 2005)
Certificate Address : 0x00010184
Number of Sections : 0x00000012
Section Headers Address : 0x00010370
Init Flags : 0x00000001 [Mount Utility Drive] [Format Utility Drive] [Setup Harddisk]
Entry Point : 0xA8ECA08E (Retail: 0x0010F725, Debug: 0x3C693DC5)
TLS Address : 0x00315D84
(PE) Stack Commit : 0x00010000
(PE) Heap Reserve : 0x00100000
(PE) Heap Commit : 0x00001000
(PE) Base Address : 0x00010AE0
(PE) Size of Image : 0x004BC3E0
(PE) Checksum : 0x004C679C
(PE) TimeDate Stamp : 0x41E20D37 (Mon Jan 10 13:05:59 2005)
Debug Pathname Address : 0x000108FC ("d:\Projects\XBlade\Game\XBox\Release\default.exe")
Debug Filename Address : 0x00010921 ("default.exe")
Debug Unicode filename Address : 0x000108E4 (L"default.exe")
Kernel Image Thunk Address : 0x5B5DF9B6 (Retail: 0x0030B900, Debug: 0xB4EC08E4)
NonKernel Import Dir Address : 0x00000000
Library Versions : 0x0000000E
Library Versions Address : 0x000107F4
Kernel Library Version Address : 0x00010844
XAPI Library Version Address : 0x000107F4
Logo Bitmap Address : 0x00010930
Logo Bitmap Size : 0x000002B2

Dumping XBE Certificate...

Size of Certificate : 0x000001EC
TimeDate Stamp : 0x41ED7974 (Wed Jan 19 05:02:44 2005)
Title ID : 0x53410003
Title : L"Iron Phoenix"
Alternate Titles IDs : 0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
Allowed Media : 0x00000202
Game Region : 0x00000007
Game Ratings : 0x00000003
Disk Number : 0x00000000
Version : 0x00000001
LAN Key : 951253A6530C012A6685D8E615B2574C
Signature Key : 33E89B90CC10E00FC97997B009E7548C
Title Alternate Signature Keys :
E2D8BD1E45C3531E6C2D2F60D5A27EF9
2198E3185D00E3F4C96DE71364FB9C41
DB9E471214BFA507B3AEE39179FF6526
9284727FE21B34EBDAF6125C4715A4A9
7C02A49EF3AC61ED98DAA28EDBDC597A
5748BA16F530DC994350562BDDD1EEE9
AD9180833918ABA4AF92CF2A88B73009
3E11786BA88AE58AA2DA46CBAF8AA2DE
0DF8A36EAF9085DB5FAE936411331C5A
67BAE5FD96B046ADDF117CD2FBEA7258
D042FCF127ACBAF81C531730252CE192
D3C10E6F3267F065ADB991CE5392136C
C734F44A9DED5458306A0DF49FE420B9
D9A03A600A0D357F3DEC02A2C1682DD0
C950745A938CF830126BA9F795220C85
023F0D538B7233E3EA91CD2CCFCAF5FD
</Hex Dump>

Dumping XBE Section Headers...

Section Name : 0x00010782 (".text")
Flags : 0x00000000 (Preload) (Executable) (Head Page RO)
Virtual Address : 0x00011000
Virtual Size : 0x00215ECC
Raw Address : 0x00001000
Size of Raw : 0x00215ECC
Section Name Address : 0x00010782
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010760
Tail Shared Reference Count Addr : 0x00010762
Section Digest : 21AD9F3C47EC159606D7108871795B434DC94F70

Section Name : 0x00010788 ("D3D")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x00226EE0
Virtual Size : 0x00014CE0
Raw Address : 0x00217000
Size of Raw : 0x000111F8
Section Name Address : 0x00010788
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010762
Tail Shared Reference Count Addr : 0x00010764
Section Digest : B893EDC28C037574A21D58DF8F02F799110E63FB

Section Name : 0x0001078C ("D3DX")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x0023BBC0
Virtual Size : 0x00000868
Raw Address : 0x00229000
Size of Raw : 0x00000868
Section Name Address : 0x0001078C
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010764
Tail Shared Reference Count Addr : 0x00010766
Section Digest : B15C957584C14245A2BB298A547604DB385808D2

Section Name : 0x00010791 ("XGRPH")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x0023C440
Virtual Size : 0x00020488
Raw Address : 0x0022A000
Size of Raw : 0x0001F80C
Section Name Address : 0x00010791
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010766
Tail Shared Reference Count Addr : 0x00010768
Section Digest : 7EF2F74BCE1EA7C14503469EB76A0CB17895755A

Section Name : 0x00010797 ("DSOUND")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x0025C8E0
Virtual Size : 0x0001E86C
Raw Address : 0x0024A000
Size of Raw : 0x0001E604
Section Name Address : 0x00010797
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010768
Tail Shared Reference Count Addr : 0x0001076A
Section Digest : 80F377042B5ABE2FF73594CBAB8F2E2BBA91D9C1

Section Name : 0x0001079E ("WMADEC")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x0027B160
Virtual Size : 0x0001907C
Raw Address : 0x00269000
Size of Raw : 0x0001907C
Section Name Address : 0x0001079E
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x0001076A
Tail Shared Reference Count Addr : 0x0001076C
Section Digest : 24D7DEE3C34D806B89E0EF1F0865F73C50AD52BB

Section Name : 0x000107A5 ("XMV")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x002941E0
Virtual Size : 0x00027FEC
Raw Address : 0x00283000
Size of Raw : 0x00027FDC
Section Name Address : 0x000107A5
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x0001076C
Tail Shared Reference Count Addr : 0x0001076E
Section Digest : 47B0840CCD6DD98CEC14499C0CC01DA81DA1BB87

Section Name : 0x000107A9 ("XACTENG")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x002BC1E0
Virtual Size : 0x0000B9D8
Raw Address : 0x002AB000
Size of Raw : 0x0000B984
Section Name Address : 0x000107A9
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x0001076E
Tail Shared Reference Count Addr : 0x00010770
Section Digest : B50D35394E2F9B5DC3BB82C42DF326C899ED87E6

Section Name : 0x000107B1 ("XNET")
Flags : 0x00000000 (Preload) (Executable) (Tail Page RO)
Virtual Address : 0x002C7BC0
Virtual Size : 0x00012F20
Raw Address : 0x002B7000
Size of Raw : 0x00012F20
Section Name Address : 0x000107B1
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010770
Tail Shared Reference Count Addr : 0x00010772
Section Digest : CC9FF3EE46E3EEB47238CF4102CC4E18D9E801B9

Section Name : 0x000107B6 ("XONLINE")
Flags : 0x00000000 (Preload) (Executable) (Head Page RO)
Virtual Address : 0x002DAAE0
Virtual Size : 0x00027F84
Raw Address : 0x002CA000
Size of Raw : 0x00027F84
Section Name Address : 0x000107B6
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010772
Tail Shared Reference Count Addr : 0x00010774
Section Digest : 0F43DC2D8693F0B16200EB94516F7E945EB43063

Section Name : 0x000107BE ("XPP")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x00302A80
Virtual Size : 0x00008E80
Raw Address : 0x002F2000
Size of Raw : 0x00008E80
Section Name Address : 0x000107BE
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010774
Tail Shared Reference Count Addr : 0x00010776
Section Digest : E2CECC89DC4E5984502D2DE01B8A6B5420C1D25D

Section Name : 0x000107C2 (".rdata")
Flags : 0x00000000 (Preload) (Executable)
Virtual Address : 0x0030B900
Virtual Size : 0x00048074
Raw Address : 0x002FB000
Size of Raw : 0x00048064
Section Name Address : 0x000107C2
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010776
Tail Shared Reference Count Addr : 0x00010778
Section Digest : 62F8C16BEF21DA9F4F6DACCD8DF8D99E832FECC2

Section Name : 0x000107C9 (".data")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x00353980
Virtual Size : 0x0014E398
Raw Address : 0x00344000
Size of Raw : 0x0000D568
Section Name Address : 0x000107C9
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010778
Tail Shared Reference Count Addr : 0x0001077A
Section Digest : C305760FF268AB34D04957679D802FEDE6D0EC61

Section Name : 0x000107CF ("DOLBY")
Flags : 0x00000000 (Preload) (Executable) (Tail Page RO)
Virtual Address : 0x004A1D20
Virtual Size : 0x00007180
Raw Address : 0x00352000
Size of Raw : 0x0000716C
Section Name Address : 0x000107CF
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x0001077A
Tail Shared Reference Count Addr : 0x0001077C
Section Digest : C8C9142DCCBD31BDCA9A2D94E0ACC47C2048D615

Section Name : 0x000107D5 ("XON_RD")
Flags : 0x00000000 (Preload) (Executable) (Head Page RO)
Virtual Address : 0x004A8EA0
Virtual Size : 0x00001A90
Raw Address : 0x0035A000
Size of Raw : 0x00001A90
Section Name Address : 0x000107D5
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x0001077C
Tail Shared Reference Count Addr : 0x0001077E
Section Digest : E791C7550E5A5462ECF66AB27D33377FE850C5BB

Section Name : 0x000107DC (".data1")
Flags : 0x00000001 (Writable) (Preload) (Executable)
Virtual Address : 0x004AA940
Virtual Size : 0x000000E0
Raw Address : 0x0035C000
Size of Raw : 0x000000B0
Section Name Address : 0x000107DC
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x0001077E
Tail Shared Reference Count Addr : 0x0001077E
Section Digest : 7F154B1A51860A1447B77E7BA73968FD275EC053

Section Name : 0x000107E3 ("$$XTIMAG")
Flags : 0x00000000 (Inserted File) (Tail Page RO)
Virtual Address : 0x004AAA20
Virtual Size : 0x00002800
Raw Address : 0x0035D000
Size of Raw : 0x00002800
Section Name Address : 0x000107E3
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x0001077E
Tail Shared Reference Count Addr : 0x00010780
Section Digest : E30887B82C6272FB51615BECE2A1753B141E8985

Section Name : 0x000107ED (".XTLID")
Flags : 0x00000000 (Inserted File) (Head Page RO) (Tail Page RO)
Virtual Address : 0x004AD220
Virtual Size : 0x00000BA8
Raw Address : 0x00360000
Size of Raw : 0x00000BA8
Section Name Address : 0x000107ED
Section Reference Count : 0x00000000
Head Shared Reference Count Addr : 0x00010780
Tail Shared Reference Count Addr : 0x00010780
Section Digest : 9B79E25F5DCFA3012DC18D2112B1593E51184FC1

Dumping XBE Library Versions...

Library Name : XAPILIB
Version : 1.0.5849
Flags : QFEVersion : 0x0001, Retail, Approved

Library Name : D3D8
Version : 1.0.5849
Flags : QFEVersion : 0x0001, Retail, Approved

Library Name : D3DX8
Version : 1.0.5849
Flags : QFEVersion : 0x0001, Retail, Approved

Library Name : XGRAPHC
Version : 1.0.5849
Flags : QFEVersion : 0x0009, Retail, Approved

Library Name : DSOUND
Version : 1.0.5849
Flags : QFEVersion : 0x0001, Retail, Approved

Library Name : XBOXKRNL
Version : 1.0.5849
Flags : QFEVersion : 0x0001, Retail, Approved

Library Name : XMV
Version : 1.0.5849
Flags : QFEVersion : 0x0001, Retail, Approved

Library Name : XACTENG
Version : 1.0.5849
Flags : QFEVersion : 0x0006, Retail, Approved

Library Name : XONLINES
Version : 1.0.5849
Flags : QFEVersion : 0x0009, Retail, Possibly Approved

Library Name : UIX
Version : 1.0.5849
Flags : QFEVersion : 0x0009, Retail, Approved

Library Name : XVOICE
Version : 1.0.5849
Flags : QFEVersion : 0x0004, Retail, Approved

Library Name : VOICMAIL
Version : 1.0.5849
Flags : QFEVersion : 0x0804, Retail, Approved

Library Name : LIBCMT
Version : 1.0.5849
Flags : QFEVersion : 0x0001, Retail, Approved

Library Name : LIBCPMT
Version : 1.0.5849
Flags : QFEVersion : 0x0001, Retail, Approved

Dumping XBE TLS...

Data Start Address : 0x00000000
Data End Address : 0x00000000
TLS Index Address : 0x0037E598
TLS Callback Address : 0x00000000
Size of Zero Fill : 0x00000090
Characteristics : 0x00000000
`

WndMain: Debug console allocated. Xbe::Xbe: Opening Xbe file...OK Xbe::Xbe: Storing Xbe Path...OK Xbe::Xbe: Reading Image Header...OK Xbe::Xbe: Reading Image Header Extra Bytes...OK Xbe::Xbe: Reading Certificate...OK Xbe::Xbe: Title identified as Iron Phoenix Xbe::Xbe: Reading Section Headers... Xbe::Xbe: Reading Section Header 0x0000...OK Xbe::Xbe: Reading Section Header 0x0001...OK Xbe::Xbe: Reading Section Header 0x0002...OK Xbe::Xbe: Reading Section Header 0x0003...OK Xbe::Xbe: Reading Section Header 0x0004...OK Xbe::Xbe: Reading Section Header 0x0005...OK Xbe::Xbe: Reading Section Header 0x0006...OK Xbe::Xbe: Reading Section Header 0x0007...OK Xbe::Xbe: Reading Section Header 0x0008...OK Xbe::Xbe: Reading Section Header 0x0009...OK Xbe::Xbe: Reading Section Header 0x000A...OK Xbe::Xbe: Reading Section Header 0x000B...OK Xbe::Xbe: Reading Section Header 0x000C...OK Xbe::Xbe: Reading Section Header 0x000D...OK Xbe::Xbe: Reading Section Header 0x000E...OK Xbe::Xbe: Reading Section Header 0x000F...OK Xbe::Xbe: Reading Section Header 0x0010...OK Xbe::Xbe: Reading Section Header 0x0011...OK Xbe::Xbe: Reading Section Names... Xbe::Xbe: Reading Section Name 0x0000...OK (.text) Xbe::Xbe: Reading Section Name 0x0001...OK (D3D) Xbe::Xbe: Reading Section Name 0x0002...OK (D3DX) Xbe::Xbe: Reading Section Name 0x0003...OK (XGRPH) Xbe::Xbe: Reading Section Name 0x0004...OK (DSOUND) Xbe::Xbe: Reading Section Name 0x0005...OK (WMADEC) Xbe::Xbe: Reading Section Name 0x0006...OK (XMV) Xbe::Xbe: Reading Section Name 0x0007...OK (XACTENG) Xbe::Xbe: Reading Section Name 0x0008...OK (XNET) Xbe::Xbe: Reading Section Name 0x0009...OK (XONLINE) Xbe::Xbe: Reading Section Name 0x000A...OK (XPP) Xbe::Xbe: Reading Section Name 0x000B...OK (.rdata) Xbe::Xbe: Reading Section Name 0x000C...OK (.data) Xbe::Xbe: Reading Section Name 0x000D...OK (DOLBY) Xbe::Xbe: Reading Section Name 0x000E...OK (XON_RD) Xbe::Xbe: Reading Section Name 0x000F...OK (.data1) Xbe::Xbe: Reading Section Name 0x0010...OK ($$XTIMAG) Xbe::Xbe: Reading Section Name 0x0011...OK (.XTLID) Xbe::Xbe: Reading Library Versions... Xbe::Xbe: Reading Library Version 0x0000...OK Xbe::Xbe: Reading Library Version 0x0001...OK Xbe::Xbe: Reading Library Version 0x0002...OK Xbe::Xbe: Reading Library Version 0x0003...OK Xbe::Xbe: Reading Library Version 0x0004...OK Xbe::Xbe: Reading Library Version 0x0005...OK Xbe::Xbe: Reading Library Version 0x0006...OK Xbe::Xbe: Reading Library Version 0x0007...OK Xbe::Xbe: Reading Library Version 0x0008...OK Xbe::Xbe: Reading Library Version 0x0009...OK Xbe::Xbe: Reading Library Version 0x000A...OK Xbe::Xbe: Reading Library Version 0x000B...OK Xbe::Xbe: Reading Library Version 0x000C...OK Xbe::Xbe: Reading Library Version 0x000D...OK Xbe::Xbe: Reading Kernel Library Version...OK Xbe::Xbe: Reading Xapi Library Version...OK Xbe::Xbe: Reading Sections... Xbe::Xbe: Reading Section 0x0000...OK Xbe::Xbe: Reading Section 0x0001...OK Xbe::Xbe: Reading Section 0x0002...OK Xbe::Xbe: Reading Section 0x0003...OK Xbe::Xbe: Reading Section 0x0004...OK Xbe::Xbe: Reading Section 0x0005...OK Xbe::Xbe: Reading Section 0x0006...OK Xbe::Xbe: Reading Section 0x0007...OK Xbe::Xbe: Reading Section 0x0008...OK Xbe::Xbe: Reading Section 0x0009...OK Xbe::Xbe: Reading Section 0x000A...OK Xbe::Xbe: Reading Section 0x000B...OK Xbe::Xbe: Reading Section 0x000C...OK Xbe::Xbe: Reading Section 0x000D...OK Xbe::Xbe: Reading Section 0x000E...OK Xbe::Xbe: Reading Section 0x000F...OK Xbe::Xbe: Reading Section 0x0010...OK Xbe::Xbe: Reading Section 0x0011...OK Xbe::Xbe: Reading Thread Local Storage...OK WndMain: Iron Phoenix loaded.

EmuInitFS crash

Checking for FS patches needs to do a quick bounds check before calling memcmp:

--- a/src/CxbxKrnl/EmuFS.cpp
+++ b/src/CxbxKrnl/EmuFS.cpp
@@ -296,13 +296,19 @@ void EmuInitFS()

        DbgPrintf("Searching for FS Instruction in section %s\n", sectionName.c_str());
        uint32_t startAddr = CxbxKrnl_Exe->m_SectionHeader[sectionIndex].m_virtual_addr + CxbxKrnl_XbeHeader->dwBaseAddr;
-       for (uint32 addr = startAddr; addr < startAddr + CxbxKrnl_Exe->m_SectionHeader[sectionIndex].m_sizeof_raw; addr++)
+       uint32_t endAddr = startAddr + CxbxKrnl_Exe->m_SectionHeader[sectionIndex].m_sizeof_raw;
+       for (uint32 addr = startAddr; addr < endAddr; addr++)
        {
            for (int i = 0; i < numberOfInstructions; i++)
            {
                // Loop through the data, checking if we get an exact match
                long sizeOfData = fsInstructions[i].data.size();

+               if (addr + sizeOfData >= endAddr)
+               {
+                   continue;
+               }
+
                if (memcmp((void*)addr, &fsInstructions[i].data[0], sizeOfData) == 0)
                {
                    DbgPrintf("Patching FS Instruction at 0x%08X\n", addr);

It currently crashes when running in Cxbx debug mode due to reading uninitalized memory in one of the cxbx sections (.cxbxplg)

Hardware Testing

I'm looking to spend some time after Christmas writing test programs and running them on real hardware.

My primary goal is to test Kernel functions to make sure they behave the same way between Cxbx-Reloaded and on my Xbox.

I would appreciate it if you all could suggest specific test cases as comments on this issue preferably giving Function names, parameters and expected behavior.

OpenBORX v4 - EmuXB2PC_D3DFormat: Unknown Format

When emulating "OpenBORX - Beats of Rage for XBox v4" an Unknown format is encountered.

EmuD3D8 (0x2A90): EmuIDirect3D8_CreateDevice
(
   Adapter                   : 0x00000000
   DeviceType                : 0x00000001
   hFocusWindow              : 0x00000000
   BehaviorFlags             : 0x00000040
   pPresentationParameters   : 0x0FBEA304
   ppReturnedDeviceInterface : 0x0FBEA348
);
BackBufferWidth:        = 640
BackBufferHeight:       = 480
BackBufferFormat:       = 0x00000016
BackBufferCount:        = 0x00000001
SwapEffect:             = 0x00000001
EnableAutoDepthStencil: = 0x00000001
AutoDepthStencilFormat: = 0x00000050
Flags:                  = 0x00000001

EmuD3D8 (0x455C): CreateDevice proxy thread recieved request.
EmuD3D8 (0x455C): CreateDevice proxy thread releasing old Device.
EmuWarn (0x455C): X_D3DFMT_LIN_R8B8 -> D3DFMT_R5G6B5
EmuMain (0x455C): Recieved Fatal Message:

* EmuXB2PC_D3DFormat: Unknown Format (0x00000050)

Burnout 1 Crash

This is with Cxbx-Reloaded ea95cfc (25 Dec 2016.) I'm able to go through all the menus and even choose a car and track before the crash, although there are quite a lot of graphical issues, and there's no sound.

Here's the last bit of the log when it crashes:

EmuMain (0x1B98): Recieved Exception (Code := 0xC0000005)

EIP := 0x6CA17EA0 EFL := 0x00010282
EAX := 0x83BDFD6D EBX := 0x0AD421FC ECX := 0x6C9F1070 EDX := 0x7FFFFFFF
ESI := 0x00000000 EDI := 0x00000004 ESP := 0x0E45FB34 EBP := 0x0E45FB38
CR2 := 0x00000000

The reason I'm reporting this is because of how similar it is to #63 (at least to a black-box tester of Cxbx like me.)

CxbxCreateSymbolicLink creates incorrect links to the utility drive

Whenever a game calls IoCreateSymbolicLink directly with a path to the utility drive (using Z:\ or \Device\Harddisk0\Partition6), Cxbx is not properly relocating the actual path to the Cxbx_ZDATA_<title ID> subfolder. These links are instead created at the root of the utility drive folder, at %APPDATA%\Cxbx-Reloaded\EmuDisk\Partition6. Some titles attempt to rename, delete or otherwise access these files after copying them, but not before recreating the symbolic link, which means they can no longer find the files since the link now points to a different folder.

Website Compatibility page issues

• When adding an entry, after uploading an xbe, sometimes the fields come back blank and are disabled so no user entry is allowed.
• Allow a notes entry, may be useful for specific issues

will this emulator be available for android

Debug Assertion Failed! on some XBEs

Debug Assertion Failed!

Program:
...\Cxbx.exe
File: minkernel\crts\ucrt\src\appcrt\convert\cfout.cpp
Line: 126

Expression: ("unexpected input value; log10 failed",0)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

XBOX_Connect4_1.1.zip

Complete kernel thunk table

At the very least, we should have correct function signatures and logging stubs for all kernel API's.

TODO:

• search which kernel API's are still registered in the kernel thunk table using PANIC
• For those, create stub implementations with correct signatures
• Log all their arguments and mark each one with LOG_UNIMPLEMENTED
• Register them in the kernel thunk table
• Remove the PANIC symbol

Constantify current codebase

Many constant (string, integer and hexadecimal) values could benefit from being moved into a constant.
This would introduce many meaningful symbol names to the code.
Also, changing a constant value need only be done at one place, where the constant is defined.

Remove all unnecessary patches

Any patch that's currently present just because it originally called unimplemented kernel functions, can be removed once the kernel functions it calls are all present and implemented far enough to be usable.

After this is done, all that's left will be patches over code that accesses hardware and/or still unimplemented kernel functions.

The new file/path funcs break many XBEs (if not all)

EmuKrnlNt.cpp (0x30F8): NtOpenFile forwarding to "IoCreateFile"...
EmuKrnlIo.cpp (0x30F8): IoCreateFile(
 OUT FileHandle              : 0xF1EFE3C
   DesiredAccess             : 100001
   ObjectAttributes          : 0x0F1EFE20 -> POBJECT_ATTRIBUTES {
   .RootDirectory: 00000000
   .ObjectName: 0x0006B000 -> PSTRING {
   .Length: 1D
   .MaximumLength: 1E
   .Buffer: \Device\Harddisk0\partition1\}
   .Attributes: 40}
 OUT IoStatusBlock           : 0xF1EFE2C
   AllocationSize            : 0x00000000
   FileAttributes            : 0
   ShareAccess               : 3
   Disposition               : (CREATE_DISPOSITION) FILE_OPEN = 0x1
   CreateOptions             : (CREATE_OPTION) FILE_DIRECTORY_FILE|FILE_SYNCHRONOUS_IO_NONALERT|FILE_OPEN_FOR_FREE_SPACE_QUERY = 0x800021
   Options                   : 0
);
EmuKrnl : IoCreateFile Corrected path...
  Org:"\Device\Harddisk0\partition1\"
  New:"$XbePath\Device\Harddisk0\partition1\"
EmuKrnl (0x30F8): IoCreateFile Failed! (0xC000003A)
EmuKrnlIo.cpp (0x30F8): IoCreateFile returns -1073741766
EmuXapi.cpp (0x30F8): EmuXLaunchNewImage(
   lpTitlePath               : <nullptr>
   pLaunchData               : 0F1EF238
);
EmuMain (0x30F8): Recieved Fatal Message:

* The xbe rebooted to Dashboard and xboxdash.xbe could not be found

Switch instruction decoding in EmuX86 to use Distorm

Just a suggestion / question :
How about switching to distorm3 (https://github.com/gdabah/distorm) instead of zyan disassembler (zydis)?

distorm lib is only 45kb, as opposed to 350+ kb for zydis.
For cxbx purposes, disassembling to a string is not necessary.
All distorm does is instruction decoding, which seems a better fit.
Furthermore, distorm is probably faster (although that might not be all that important as long as illegal instructions and/or memory access are trapped via an exception handler, which causes huge overhead).

Poor support for titles using multiple executables

Lack of support for XLaunchNewImage & HalReturnToFirmware prevents games using multiple executable files and games which reboot the current executable to switch game mode (eg. Buffy) from working.

At a minimum, an Xbe loader has to be implemented for XLaunchNewImage to work.

A more complete approach would be to properly implement HalReturnToFirmware and MmPersistContiguousMemory, allowing titles to reboot, launch other titles or even launch the Dashboard without patching XLaunchNewImage

Avoid slow access violation exceptions by JITting the offending instructions

One thing that could be done, is patching code on the fly - each time an exception occurs, we could patch the code (via a jmp) and re-route to a handler, so that we won't hit the exception handler penalty afterwards.

If we can get that to work, we pay a performance penalty the first time an instruction is hit, and a little overhead for the handler to check if the opcode still accesses absent hardware (if so, we call the emulation, otherwise, the opcode should be executed as-is).

Do note however that self-modifying code could throw a wrench into this schema, so we should also make it configurable per xbe (perhaps automatically using a xbe hash database)?

Log Filtering/Options

Having a submenu to disable/enable certain API Logs, or even macros like Info/Warning/Error/Fatal would be very useful. Another one which might be a pain and thus wouldn't blame ya if you didnt bother would be a duplicate entry counter. like:
EmuWarn (0x8FC): EmuNV2A_PMC_Read32($00000044) // Unknown PMC Address = $00000000 (Repeated xTimes)

Render NV2A commands using OpenGL

Based on my research on the way the Xbox Direct3D API is translated to NV2A instructions, it's remarkable how closely these instruction match the OpenGL API. Many of the NV2A GPU's internal commands can be mapped directly to OpenGL calls, which makes OpenGL a more suitable rendering API than Direct3D.
(Also, using OpenGL as rendering API would be one less problem when porting to non-windows OS'es.)

NtQuery/SetInformationFile needs to convert the FileInformation structs

For example, the FILE_RENAME_INFORMATION struct has differences between Xbox and Windows;

// Windows
typedef struct _FILE_RENAME_INFORMATION
{
	BOOLEAN ReplaceIfExists;
	HANDLE  RootDirectory;
	ULONG   FileNameLength;
	WCHAR   FileName[1];
}
FILE_RENAME_INFORMATION, *PFILE_RENAME_INFORMATION;

// Xbox
typedef struct _FILE_RENAME_INFORMATION
{
	BOOLEAN         ReplaceIfExists;
	HANDLE          RootDirectory;
	OBJECT_STRING   FileName;
}
FILE_RENAME_INFORMATION;

In addition to that, the information classes FileRenameInformation, FileShortNameInformation and FileLinkInformation use a struct that contains a path which needs to be redirected to the proper EmuDisk folder.

Avoid page faults for NVA2 memory

I'll try to add more specifics to this later, but the general idea here is that miniport API's can be used to move the NV2A command buffer to a pre-allocated memory-range;

As far as I remember from my research, all Direct3D code linked into XBE's aknowledge the miniport-supplied memory range. So, most (perhaps all) Xbox titles don't access hard-coded memory ranges, but will follow what the miniport API dictated.

This means that many page-faults can be avoided, just as long as there's a method in place that will handle writes to the NV2A memory. One method could be to have a separate thread interpreting the data written to the command buffer, translating it to a high level 3D API.

Some titles abort execution after calling EmuIDirect3D8_EnumAdapterModes

I am not entirely sure when this broke exactly, but some titles are either triggering a reboot to dashboard or crashing after calling EmuIDirect3D8_EnumAdapterModes. This could have been caused by attempting to port improvements from Dxbx but I am not certain.

Seems to effect mostly SEGA titles (seen with JSRF and Panzer Dragoon) but also effects a few other games.

Port to Linux using Wine

Cxbx might be ported over to Linux, by using either a dependancy on Wine or by linking to Wine libraries.
This way Cxbx doesn't need to implement many API's again for Linux, but could "just" rely on Wine to handle most of the Xbox kernel API's.

As long as not-available and/or problematic Windows API's are avoided, it might even be possible to launch the windows-targeted Cxbx executable as-is using Wine on Linux.

Remove all compiler hints and warnings

Having no compiler hints and warnings gives a much cleaner build.

Causing new compiler messages should be forbidden - if any appear, the person responsible for that should fix it.

EmuNV2A: Incorrect mappings

The switch statements in EmuNV2A_Read/Write functions are incorrect.

As an example, when hardware is attempting to access the 0x800044 (NV_USER_DMA_GET), the switch case statement interprets the access as an unknown PMC address (0x000044).

I ran into this while experimenting with disabling the CreateDevice patch

Log flags as string

Implement conversions to string for all flag sets.

Use those in the right places in our logging calls.
Try to fit this in the current logging design with the least possible amount of required changes.

Configure Controller Bugs

When configuring the controller i notice 2 things

1. The D-Pad or is not recognised on an Xbox 360 controller.
2. When using configure all inputs option, Escape fails to exit the process properly causing a loop where the last un-entered key is prompted for input.

I would not consider this a priority as i know more xbox-related work is needed

Super MonkeyBall Delux

It makes a whole bunch of stuff then stops. Blank screen. I have an Iso for testing if needed. Most emulators seam to have trouble emulating this game...

NtCreateFile missing files

I'm running some XBE tests files through this fork of Cxbx.

I'm seeing failures trying to access \Device\CdRom0:

EmuKrnl (0x1E38): NtCreateFile
(
FileHandle : 0x01F1FE38
DesiredAccess : 0x80100000
ObjectAttributes : 0x01F1FE24 ("\Device\CdRom0")
IoStatusBlock : 0x01F1FE30
AllocationSize : 0x00000000
FileAttributes : 0x00000000
ShareAccess : 0x00000001
CreateDisposition : 0x00000001
CreateOptions : 0x00000020
);
EmuWarn (0x1E38): Path not available : \Device\CdRom0
EmuKrnl (0x1E38): NtCreateFile Failed! (0xC000000D)
EmuKrnl (0x1E38): MmPersistContiguousMemory
(
BaseAddress : 0x100B0210
NumberOfBytes : 0x00001000
Persist : 0x00000001
);
EmuWarn (0x1E38): MmPersistContiguousMemory is being ignored

EmuKrnl (0x1E38): HalReturnToFirmware
(
Routine : 0x00000002
);

I haven't looked into this much, but this is initialized to the XBE directory:

CxbxRegisterDeviceNativePath(DeviceCdrom0, xbePath);

Debug Assertion Failed! on #ea279e1

Debug Assertion Failed!

Program:
...\Cxbx.exe
File: minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp
Line: 17

Expression: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle)

For more information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to to debug the application)

No Workaround

Solve RDTSC differences

Executing the RDTSC instruction (opcode 0F 31) on the host CPU without emulation probably gives different results than on the Xbox1.

We should measure the characteristics of the host RDTSC instruction;

• if it behaves close enough to the Xbox, it requires no special handling
• if it deviates too much from the Xbox, RDTSC must be emulated.

If the host RDTSC can be used, it's probably wise to base our KeQueryPerformanceCounter implementation on the host RDTSC instruction too (as that results in better interoperability between code using both this kernel API and the opcode).

If the RDTSC must be emulated, there are at least three possible methods:
1: Scan for the opcode and patch if (much like the patching of FS-accesses)
2: If possible, set the TSC flag, which causes an exception when executing the RDTSC instruction.
3: Run all code via a JIT engine, handling the RDTSC instruction specially

When using option 1, the patch must result in a value that increments with the same frequency as on the Xbox.

When using option 2, the RDTSC instruction causes an exception. Emulation of the Xbox characteristics can be done in our exception handler.

When using option 3, most code the JIT engine handles, can be executed as-is. The RDTSC instruction however would need special handling.

Be aware though, that any kind of emulation of RDTSC will incur some overhead, which will reduce the granularity of the resulting value. This might become a problem in tight loops, but otherwise it's not a big deal.

For more defails, see http://x86.renejeschke.de/html/file_module_x86_id_278.html en http://stackoverflow.com/questions/8322782/rdtsc-too-many-cycles

Resolving incorrect paths

Tested on your latest commit de0c650

EmuKrnl (0x159C): RtlInitAnsiString
(
   DestinationString   : 0x0493FC48
   SourceString        : 0x0493FC84 ("t:\media\cour.xft")
);
EmuKrnl (0x159C): NtCreateFile
(
   FileHandle          : 0x0493FC50
   DesiredAccess       : 0x80100080
   ObjectAttributes    : 0x0493FC34 ("t:\media\cour.xft")
   IoStatusBlock       : 0x0493FC40
   AllocationSize      : 0x00000000
   FileAttributes      : 0x00000080
   ShareAccess         : 0x00000001
   CreateDisposition   : 0x00000001
   CreateOptions       : 0x00000060
);
EmuKrnl : NtCreateFile Corrected path..
.  Org:"t:\media\cour.xft"
  New:"$CxbxPath\EmuDiskPartition1\TDATA\5842000cmedia\cour.xft"
EmuKrnl (0x159C): NtCreateFile Failed! (0xC000003A)
EmuKrnl (0x159C): RtlNtStatusToDosError
(
   Status              : 0xC000003A
);
EmuMain (0x159C): Recieved Breakpoint Exception (int 3)

The path resolved for reading local media is incorrect - where the requested file is a symbolic link to the t:\ drive, added like this:

EmuKrnl (0x159C): IoCreateSymbolicLink
(
   SymbolicLinkName    : 0x00037AF8 (\??\U:)
   DeviceName          : 0x0493FDE4 (\Device\Harddisk0\partition1\UDATA\5842000c
)
);

I've uploaded the XBE files + media causing this issue: http://www.speedyshare.com/Xa9dY/xbe-controller-test.7z

Note - this has also initialised D3D by this point.

Xbox dashboard 3944 no longer seems to work

Hello, and I apologize in advance if this is not a suitable place to ask for help, however I feel that it should be made aware just in case.

I recently got the old 3944 dashboard files to try and emulate through Cxbx, however the latest builds seem to just give me constant breakpoint errors, and the emulator ends up crashing every single time.
I have observed the compatability list, and saw that this version of the dash should indeed work, but it seems that it does not.

I have attempted to build the source from the point where 3944 dash was fully implemented and working (Nov 2011), but even then I'm encountering horrible building errors in Visual Studio 2008 and am struggling to fix them. (I can compile the latest builds just fine in VS 2015, but again those builds cannot seem to emulate the 3944 dash on my side)

If you need to know what I'm running on, I am using Windows 10 (x64). Any aid to try and get the dash up and runnning is much appreciated.

EmuKrnl calls NtDll directly

The method Cxbx uses to emulate the Xbox kernel involves redirecting as many NtX kernel calls as possible to the user mode implementations contained in NtDll on Microsoft Windows.

NtDll is an internal library and is not meant to be called directly by user applications, but by API functions that user applications call, because of this, the behavior of these functions is not always consistent between operating system versions.

Ideally, we should never call NtDll but instead implement the kernel functions ourselves.
Wine and ReactOS may be good references

NOTE: This is a long term goal, as replacing these calls is an insane amount of work at this point, but necessary for both consistency and potential future portability to non-windows systems.