Ok, I've got as far as compiling a couple of things, the best I've got out of it sadly is a black screen, are there still issues with xecutor bioses as that what I'm using? :(
Not sure if this is the problem or not but might help.
Have you patched the xbe after compiling it? There is a program called something like xbepatcher that you can get from www.xbox-scene.com
Might work for you.
Has there been any further news on the "blank screen o' death" when using openXDK samples?
It's kinda dead in this forum and the one at xbox-scene has pretty well skipped over this issue too.
I'm using the .06 pre-compiled release of the xdk, I can build the samples just fine, but when launched out of XBMC they hang. When launched from evox they work fine.
The one I'm having issues with currently is simply launchXBE.
Anything we can do to help debug this?
A contributor sent me some code two days ago that looks as though it will go a long way toward fixing that problem. I need to confirm, though, whether the problem has been completely (or only partially) solved.
I will get back to you when I know for sure. Thanks for your patience.
I just tried the 07 version and my launchXBE is still giving me a black screen o' death when trying to execute it from within XBMC. I can run the same xbe from avalaunch and evox without any problems though. What in the world could XBMC be doing differently?
One thing that is interesting is that when launchXBE runs from evox or avalaunch, I get the upper 1/3 of the screen filled with garbage just before the program I'm trying to launch loads up. I just get a black screen when running from XBMC. This is on an NTSC xbox and XBMC from may 1st 2005
Here's my program in its entirety:
// if we return from the XLaunchXBE function, then
// we couldn't find the file, or there was some problem
// launching it.
// execve("c:\\doom.xbe", NULL, NULL);
debugPrint("Crap... couldn't find it\n");
as you can see, all I did was change the xbe I was trying to launch.
I'm trying to make a program that you can load up specific roms in an emulator from within the dashboard without having to select them from the emulator's select menu. Command line passing is going to be the next hurdle for me to try and wedge into openXDK, as I don't believe there is any support for it yet.
thanks for reading.
Can you give more exact details of your setup?
What version xbox is it?
What type of A/V pack are you using?
What are the video settings in XBMC?
Can you also add a debugPrint statement before the call to XLaunchXBE? I'd suggest something like debugPrint("About to start\n"); XSleep(5000);
Please try that and let us know the results.
Adding the debug print and sleep, it goes like this from XBMC:
screen goes blank
"about to start" shows up in the upper left corner of the screen.
5 seconds passes, and the machine locks up. The about to start message is still on the screen when it locks up.
So, it's getting into xlaunchxbe, but without more debug messages in there, I won't be able to tell where it's dying.
I get the same lockup when launching it from XBMC's file browser.
When launching it from evox or avalaunch, the screen goes blank, the message shows up, 5 seconds later the screen flickers a bit with the top 1/3 of the screen with garbage characters for a split-second, then the desired app is loaded.
I'm running on standard 4:3 video with the default AV pack on a 1.2 version xbox. I'm using evox M8 bios, but I don't believe that my xbox hardware has anything to do with this since the launchxbe app works from other dashboards.
Both XBMC and avalaunch are located on the E: drive, the app I'm running is on the F: drive, so it's not a drive/path issue.
XBMC is reporting I have 26 of 64mb of memory available.
I changed it to launch my atari 2600 emulator, which is 1.2mb in size, thinking there may be a memory issue, but I was to believe that nothing remains resident when a program launches another program, so I don't think it's a memory thing either.
Adding more debug print messages inside of xlaunchxbe is probably the next step, provided I can figure out how to recompile the libraries.
Thanks for the help so far!
It certainly does look as though the issue lies with XlaunchXBE somewhere.
Recompiling that lib is very straightforward - just edit the necessary files in the OPENXDK_ROOT/src/hal directory
where OPENXDK_ROOT is where you have the openxdk source tree.
Once you've made the changes you want to make, just run 'make all install' in the same directory.
Let us know what results you get from your further testing.
Just a quick question... does it work if you try to invoke another XBE (ie. not your colecovision app)?
No, it doesn't seem to matter what xbe I try to launch, they all hang.
Ok, here's the results of my additional debug messages (drumroll please....)
* Launches an XBE. Examples of xbePath might be:
* If the XBE is able to be launched, this method will
* not return. If there is a problem, then it return.
void XLaunchXBE(char *xbePath)
struct stat statbuf;
if (stat(xbePath, &statbuf) < 0)
memset((void*)LaunchDataPage, 0, 0x1000);
LaunchDataPage->Header.dwLaunchDataType = 0xFFFFFFFF;
LaunchDataPage->Header.dwTitleId = 0;
// one last thing... xbePath now looks like:
// but it has to look like:
char *lastSlash = strrchr(LaunchDataPage->Header.szLaunchPath, '\\');
if (lastSlash != NULL)
*lastSlash = ';';
// if we couldn't find a trailing slash, the conversion to
// the xbox path mustn't have worked, so we will return
And it hangs after displaying "1111" on the screen.
So something in memset obviously. I'll dig into that function and repeat my output messages until I can go no further. Stay tuned...
Hmmm... interesting. I was reading this post (http://forums.xbox-scene.com/index.php?showtopic=403919 - specifically the second post) on Friday, and it made me wonder if that was your problem. Now they are talking about the video buffer address, but the LaunchDataPage is a globally exported variable from the kernel. I wonder if it is being set to something a bit dodgy.
I don't think that memset is the problem... I suspect that the address that LaunchDataPage is pointing to is not valid. I will investigate and report back here.
Funny, I'm involved in that thread too, and was thinking roughly the same thing. I've also come to the same conclusion that memset is fine (as it's not even xbox specific as I have recently learned) and that it's most certainly just memset overwriting something important.
I'll try and change the code to print out what launchDataPage is set to and run it from both xbmc and avalaunch.
I think I have an idea what the problem might be. I can't check it at the minue but will do so when I get home later.
Took me a bit longer to get round to looking at it than I thought but it should be fixed in the cvs code now.
Give it a try and let us know how you get on.
Thanks so much for the fix!
Tested from XBMC and from avalaunch, both work the same now.
I still get a screenfull of garbage right before the launched xbe pops up on the screen. I can certainly deal with it, but something is still a bit wonky. Doesn't seem to affect anything.
I may have to ask your assistance again to figure out how to make it launch the new xbe with a command line argument, but let me poke around in the code a bit and see if I can figure it out on my own. This is a huge step forward though.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.