Using Steve's latest build, I have tried to run IOQuake 3 on the
Beagleboard. However when I try to install the Quake 3 using opkg, it
says that the dependency with SGX drivers version 3.00.08 are needed
(I could have skipped a zero or two, but it's the "8" that bugs
me ;-)) and that this dependency cannot be satisfied.
I also found a binary on DCemu for the Pandora, which should be pretty
much compatible, but running this binary yields a segmentation fault.
Being less ambitious I also tried SDLQuake with the shareware .pak
file and this also yielded a segmentation fault. Has anyone gotten one
of the two quakes working? What kind of setup did you use?
I am also curious what kind of beneficial effects a joint effort
between the beagleboard and the openpandora could yield, I see some
pretty nice things, but I do have the feeling that the software stack
of the Pandora is more up to date. (it does use OE as I can see on
some of the videos).
Has anyone gotten one
of the two quakes working? What kind of setup did you use?
I also would like to hear any information anyone might have on setting up similar software. The whole hardware accelleration arena seems to be as much of a mysterious art as cross-compiling.
I am also curious what kind of beneficial effects a joint effort
between the beagleboard and the openpandora could yield, I see some
pretty nice things, but I do have the feeling that the software stack
of the Pandora is more up to date.
A friend and I are working on a project called "Gentoo for Pandora" and, as far as we can tell, the only real differences hardware-wise between the OpenPandora hardware and the Beagle are the peripherals (screen, gaming controls, keyboard, etc). Really, everything written for the Pandora ought to work on the Beagle just as well with only a few minor changes. To prove this point, we're planning on providing Gentoo images for both the Beagle and the Pandora simultaneously.
However, the Pandora handheld is designed to be a consumer-ready handheld, whereas the Beagle is obviously targetted towards hardware and low(er)-level software hackers. As far as we know, the code for the Pandora OS is based on Angstrom, but is patched to be stable and compatible with the extra built-in peripherals. Whenever they create a patch that is applicable to OMAP devices in general, they forward them upstream. (You can already find their patches in the main omap kernel.)
What I'm trying to get at is this: the Pandora will benefit from the Beagle, and vice-versa, and already is, but the two have different goals, so they'll never be able to (officially) come together into a single team effort.
Has anyone gotten one
of the two quakes working? What kind of setup did you use?
I also would like to hear any information anyone might have on setting up similar software. The whole hardware accelleration arena seems to be as much of a mysterious art as cross-compiling.
I am also curious what kind of beneficial effects a joint effort
between the beagleboard and the openpandora could yield, I see some
pretty nice things, but I do have the feeling that the software stack
of the Pandora is more up to date.
A friend and I are working on a project called "Gentoo for Pandora" and, as far as we can tell, the only real differences hardware-wise between the OpenPandora hardware and the Beagle are the peripherals (screen, gaming controls, keyboard, etc). Really, everything written for the Pandora ought to work on the Beagle just as well with only a few minor changes. To prove this point, we're planning on providing Gentoo images for both the Beagle and the Pandora simultaneously.
However, the Pandora handheld is designed to be a consumer-ready handheld, whereas the Beagle is obviously targetted towards hardware and low(er)-level software hackers. As far as we know, the code for the Pandora OS is based on Angstrom, but is patched to be stable and compatible with the extra built-in peripherals. Whenever they create a patch that is applicable to OMAP devices in general, they forward them upstream. (You can already find their patches in the main omap kernel.)
What I'm trying to get at is this: the Pandora will benefit from the Beagle, and vice-versa, and already is, but the two have different goals, so they'll never be able to (officially) come together into a single team effort.