Various additions to support dash.xex

[emoose]

Here are some extra changes needed to get dash.xex to run (and also help get xshell.xex to start running)

Two other PRs are also needed for dash.xex to work: #1245 which adds exports, and #1244 for some bugfixes (originally they were part of this PR, but split away to make this one less crowded)

The fixes in this PR are just some minor things that are also needed to help get them running:

• PVR register added to mfspr, used by xshell just to print out a simple string... could be helpful for other apps though (if xshell.xex can access it any other xex possibly could too)
• extra mount paths for the local folder: the commit message goes into the reasons for these (https://github.com/xenia-project/xenia/pull/1243/commits/9309e1ac20da7878be159bcfad605ea01564ff2d)
• extra XConfig settings, needed to stop dash.xex crashing from an uninitialised buffer.

This PR will also set XCONFIG_USER_RETAIL_FLAGS to 0x40 by default, which skips the dashboard initial setup/OOBE (currently broken due to missing profile exports AFAIK), but this can be unset with --xconfig_initial_setup if needed.

Other info from older PR comment:

dash.xex also requires some resources from the NAND, luckily it's easy to make it load these resources from a local file instead (which doesn't even require a code patch neither!).

Put these files in the same folder as dash.xex:

• gamercrd.xzp & shrdres.xzp - need to be extracted from xam.xex's XEX resources, preferably from same version as dash.xex (use "xextool -d . xam.xex" and add .xzp extension to them)
• xenonclatin.xtt & xenonjklatin.xtt - need to be taken from a NAND. RGBuild can extract these fine, maybe 360 Flash Tool too.

This PR also has some fixes to help get xshell.xex running (PVR register & /Device/LauncherData mount path), but xshell won't run with this commit since it needs some import libraries to be loaded on launch, which Xenia doesn't seem to do yet... I did find a fix for that which was pretty simple, and let XShell load up fine, but I'm not sure if that was a proper way to do it, might have some side-effects so I haven't included that in the PR. I'll post about that fix in the issue section soon.

[gibbed]

There's only four commits here and you're making a lot of changes.

IMO, all of the bugfixes should be made their own PRs as it's not directly related to the dash stuff. Too much of this is bundled together under generic commit messages.

Edit: this is so we can get the bugfixes approved as soon as possible, while the new stuff can be reviewed appropriately. At the very least, I'd like to see commits per bugfix instead of them being bundled with unrelated stuff.

[emoose]

I guess maybe the export commit could be split up, I figured most of it was tied together and didn't really deserve their own commits... but looking at it now it does seem pretty huge though, I'll remove that from this PR and redo it in a different one.

Anyway sorry for the huge commits, I usually code & test things out of tree and then copy out/commit the things that work, will try keeping them smaller next time.

[gibbed]

No worries at all, that's what reviews are good for.

[emoose]

Alright, I've split the bugfixes and the exports into seperate PRs: https://github.com/xenia-project/xenia/pull/1245 and https://github.com/xenia-project/xenia/pull/1244

I've left the miscellaneous stuff needed for dash.xex in this PR, I suppose at least now even if this doesn't get merged the other stuff could be :)

Hopefully the new commits are a lot better than before too :P I'll also try and keep my PRs more focused in future.

[emoose]

Hmm, seems I was wrong about these PRs not working anymore, just tried merging them again with latest master and 1888 dash seems to load fine now, guess I was doing something wrong before.

Could someone else try it out so I can be sure? You'll have to:

• clone latest master
• merge in changes from this PR and #1245
• search google for "1888 dashboard update", you should find a download for the 1888 NAND files (xam.xex, dash.xex etc...)
• extract all those files somewhere
• download xextool, put xextool.exe in same folder as 1888's xam.xex
• from command prompt, go to your extracted 1888 folder and run "xextool.exe -d . xam.xex", this should extract 4 new files from xam: gamercrd, mplayer, shrdres and xam
• rename those 4 files so that they have a .xzp extension (gamercrd.xzp, shrdres.xzp, xam.xzp...)
• now run dash.xex from your merged xenia build

With any luck hopefully the dashboard will run fine, if someone can try this and report back it'd really be appreciated!

(edit: 0x8080 confirmed it working on discord too, hopefully these PRs should be pretty much good to go)

[RohanRahman-s]

I get error when running "xextool.exe -d . xam.xex" in powershelll from the same folder as xam.xex. So I can't test this out

[randprint]

I am using this merged with latest master and can confirm it still works screenshot

[RohanRahman-s]

So it's safe to say this PR is working.

[emoose]

Dash itself still works but looks like initial setup/OOBE is now crashing after selecting a language, log shows it calling _vscwprintf & vswprintf tons of times before it crashes, and running with debugger attached shows it crashing inside ntdll with a messed up stack, so I guess some loop is broken somewhere...

It did work fine before though, previously would at least get up to a screen asking you to input a new gamertag (which I was hoping to try out with the new UI notification fixes), not really sure what could have broken it, will have to try a bisect soon.

[jgoyvaerts]

Could any of these be the issue? https://github.com/xenia-project/xenia/commit/8b1f728d85f5521a1212c51aab16657050c4aa96 https://github.com/xenia-project/xenia/commit/40cc8c52d78a53186a2a6abaa7a7627a09b79f36

[gibbed]

I'm sure emoose meant the guest imports of those functions, not host usage.

[emoose]

I was wondering that too, but it looks like those changes should only really affect Xenia's logging stuff? Not really sure...

Still, pretty funny that just after some printf changes were made, we find out dash.xex is having printf problems - but then again I don't think dash's OOBE has been tried out in a long time, there's been a lot changed since the last time I posted about it anyway 😛

EDIT: Just tried with 0ac83f99 and same result, so guess it's from something before the d3d12 merge at least, I'll try bisecting some more later.

E2: Just enabled symbols for ntdll and seems it's looping two exception handler funcs ntdll.dll!RtlDispatchException() & ntdll.dll!KiUserExceptionDispatch(), odd.

Also the _vscwprintf stuff might be innocent, seems some valid data is being passed/returned from it at least (which is different for each call)

...and now I enabled loading from symbol server VS is taking years to start debugging since it wants to load in the symbols for every Windows DLL that exists, ugh

E3: Weird, tried some commit from around when I made this PR and it still crashes on OOBE after choosing language, I'm sure at one point it was going to a screen that would show an input window asking for gamertag though, which was the whole reason I started looking into the Xam UI exports... very strange.

Maybe I don't have the dash files setup correctly or something like that, not sure.