Print

[Keo-Keo]

Good to see that your back.. Perhaps OpenDash can get the ball rolling with USB(xpad) support!

[Carcharius]

QUOTE

VIDEO SUPPORT - Carcharius has written some excellent code that gives us better video mode support, and apparently may help solve the problem with OpenXDK apps not working for various BIOS/chips. Not sure of how complete the testing of that is... Carcharius, any thoughts?

Well I've tested it with several bios' and dashboards and it's worked fine in all of my tests. All of those tests have been on a v1.0 conexant xbox.

I don't envisage there being any major problems with it. I'll add the code to the cvs in the next few days or so.

Carcharius

[d0wnlab]

.  I haven't tried doing the SDL related GL stuff, but Carch said that there was an SDL driver I think that uses OS_Mesa?  Unsure, also unsure if this should be that tightly integrated into the core openXDK SDL stuff..

c++ support - there's a sourceforge message post in the openXDK project regarding c++ support.  The person included the code for new and delete operators and found that by linking against stdc++ makes the virtual function tables linking properly.

opendash (first version) - those were screenshots you saw from it running in linux.  I had made a PPF patching app for Halo originally and adapted it to browse and run XBEs (and prettied it up a bit).  All it really needs is input working, and it can browse and run XBEs.  Keo-Keo has been putting together a mini-linux distro that will be able to give the person networking access to their box, so we could have a cumbersome, but working legal dash without needing networking integrated in the openXDK.

opendash (second version) - I'm working on a framework that could turn into a nicer dash, more like an evox clone.

cromwell - I've been working on getting the cromwell usb stack working but it isn't going the greatest.  First off, what do you suggest as a better alternative for waiting x milliseconds?  I did a quick hack to use XSleep(), but it was crashing the xbox.  I guess something in XSleep doesn't go too well with integral timing in the middle of usb initializations.  Aside from that, my (iirc) 1.2 xbox get's to the point where in usbBoot it tries to read 30 events and freezes (and I've been tracing that freeze slowly), and my 1.1 freezes somewhere before that in the bootup code.  Once I get a better wait_ms replacement I'll try a bit more and send you what I have.

other things I'm working on:

libXML - pretty soon to be working.

SDL_mixer/SDL_sound - I think I have one of these _seemingly_ working, but they aren't playing any music.  Debugging shows the file to be loaded and playing but nothing's coming out of the speakers.  I gave up in frustration but will go back to it eventually.

oh, and I have a tetris clone that needs 4-player input support


problems I'm experiencing:

compiling the openXDK in linux has been broken since the update to automake .  Could someone post the entire list of their environment settings in cygwin? I think gentoo users are missing a few.  This was posted some time ago in the forums but the answer didn't fix it completely for me and I haven't gotten it working yet.

Things are definitely looking up though, we have a lot of people here working with the openXDK and things can only get better!

You can find links for the libraries in my sig, a link for the beta source of the opendash beta in the opendash thread, and everything else email me if you want it

[edwardaux]

Thanks d0wnlab for your update.  A couple of comments...

> SDL_image / SDL_ttf

They sound good... do you have a plan for them?  Did you want to maintain them separately, or did you want to integrate them into the base OpenXDK build?

> libmesa / openGL

At this stage, I would be inclined to keep them separate from the main OpenXDK tree, which hopefully will reduce some confusion.

> c++ support - there's a sourceforge message post ...

Indeed there is.  I must have missed that somehow.  There are a couple of things that I need to do/test, but it looks very promising.  The only thing I am a bit nervous about is linking to the stdc++ library... the linking process is very finicky about everything being statically included from the provided newlib, so I need to make sure that linking in this way won't start dynamically linking in functions.  

> OpenDash (I and II)

Ignoring (for the moment) booting into Linux, all we need for an OpenXDK-compiled dashboard is decent USB/controller support, yes?  

> USB / Cromwell

Are you sure it is XSleep() that is crashing?  It is just about the simplest/dumbest function in OpenXDK (see below).  XGetTickCount() just returns the value of KeTickCount which is an exported global variable in xboxkrnl.exe.

void XSleep(int milliseconds)
{
        int target = XGetTickCount()+milliseconds;
        while(XGetTickCount() < target);
}

> libXML - pretty soon to be working.

I trying to decide what to do with all these extra libraries (such as libpng, zlib, libXML, libmesa, etc) that are not strictly part of OpenXDK, but are all very useful.  Maybe, I'll have a collection of links that point to other libraries - not sure yet.  It is a good problem to have though :-)

> SDL_mixer / SDL_sound

Likewise.  Have a look at the Sample project... there is a file there called sdlMixer.c that I almost had working, but not quite.  Problem is that it has been so long since I worked on it, I can't even remember what it was that wasn't working :-)

> Compiling the openXDK in linux has been broken

Hmm... it should work OK.  I tested under Redhat 9.0, and I received an email from a guy saying that he got it working under Debian.  What problems are you having?

Thanks for all your work and the lengthy update.

--
Edwardaux

[Carcharius]

QUOTE(TMaul @ Mar 17 2005, 02:00 AM)

I've tried it on my 1.2/1.3 and a friends 1.4, again with a variety of bioses and quite a few different bioses. No problems that I can see, other than a crash with a debug enabled x3 bios but that could just as easily be a problem with something else in the openxdk.

[d0wnlab]

QUOTE

SDL_image / SDL_ttf

They sound good... do you have a plan for them? Did you want to maintain them separately, or did you want to integrate them into the base OpenXDK build?

I'd be happy with those integrated into the base OpenXDK build.  I don't know how to use automake atm, though, so if it's to all be converted I might have a harder time maintaining than someone else..  I'm also fine with someone else maintaining them or whatever and I'll just contribute as I see fit.

QUOTE

> libmesa / openGL

At this stage, I would be inclined to keep them separate from the main OpenXDK tree, which hopefully will reduce some confusion.

Sounds good.  I'll see what the limitations of this are at some point, I'm sure they're quite low.

QUOTE

> OpenDash (I and II)

Ignoring (for the moment) booting into Linux, all we need for an OpenXDK-compiled dashboard is decent USB/controller support, yes?

That is correct.  The dumbest of input handling is required - there's no requirement for a speedy handler or multi-joystick input or anything.

QUOTE

USB / Cromwell

Are you sure it is XSleep() that is crashing? It is just about the simplest/dumbest function in OpenXDK (see below). XGetTickCount() just returns the value of KeTickCount which is an exported global variable in xboxkrnl.exe.

I'm sure it was XSleep(), in one specific place in the code (not at every instance of a XSleep() call).  It was in the middle of some rather low-level initialization stuff (I can probably find the actual source line if needed).  I added debugPrint() statements directly before and after a XSleep call and to my amazement the one following the XSleep() didn't execute.  Commenting out the call worked but I'm sure the sleep was there for a reason and me randomly changing timing isn't helping the usb initialization any..

QUOTE

I trying to decide what to do with all these extra libraries (such as libpng, zlib, libXML, libmesa, etc) that are not strictly part of OpenXDK, but are all very useful. Maybe, I'll have a collection of links that point to other libraries - not sure yet. It is a good problem to have though :-)

What if we were to:

  - integrate the sources into the CVS, in it's own module if you will.
  - release a seperate download release corresponding to each future openXDK release containing the binaries and headers, and in the CVS having a script in the module that can compile and install all the libraries one after another.

If it's too much to put into CVS (beginning to get out of place since it's not the core openXDK really), we could make a seperate sf.net project like "openxdk-libs" or something, or I could just host on my website.

QUOTE

> Compiling the openXDK in linux has been broken

Hmm... it should work OK. (snip..)

I'll try this again.  I think gentoo users might be missing a couple environment variables that automake uses.  I'll get back to you on this.

QUOTE

Thanks for all your work and the lengthy update.

My pleasure .  Thanks for making this all possible (that goes for everyone contributing here..)

[Carcharius]

I've just commited the new video code to the sourceforge cvs. This also includes modifications to the SDL code and comingsoon sample so that they use the new video code as well.

This means any SDL based apps should work with no changes. Any other (non-SDL) OpenXDK projects should work with only minor changes.

The main change that will be needed is because the define for XBOX_VIDEO_ADDRESS no longer exists. So replace any calls to XBOX_VIDEO_ADDRESS with a call to the new function XVideoGetFB() and everything should be fine.

As it stands at the moment a default video mode of 640x480x32 is set both for SDL and non-SDL apps. Non-SDL apps can also change modes if needed. Currently supported modes are 640x480 and 720x480 in both 16 and 32bpp.

I've left the SDL code limited to 640x480x32 for now. This will be looked at as and when the video code becomes more complete.

The new code also includes the scrolling debug output (submitted by Robin Mulloy) that edwardaux spoke about.


There's more to come - but it's a start and means OpenXDK apps don't have to be launched from EvoX to work properly anymore. Suggestions for features/methods in the video code are welcome.


Carcharius