Pandora The Pandora Has No Fpu? Could There Be A Workaround?


CCmachined

Member
Joined
Nov 3, 2007
Messages
347
after asking about a port to the Pandora console on the cube/sauerbraten forums (cubeengine.com) we had this reply from the head of the cube/sauer project:
Aardappel_ said:
sounds to me like it has no hardware floating point. Porting Cube to fixpoint is a LOT of work.

The OpenGL ES part should be doable since Cube uses absolutely simplistic OpenGL. I wouldn't think of sauer as that would require major reworking.

The intel PDA that Jeff Rous ported it to seemed to have similar power to this thing, and it didn't run all that fast. It would probably be easiest to use exactly his version of Cube. Maybe he'd like to help?
I noticed i had troubles getting C++ code with floats to run on the :gp2x ... never looked for a solution. is this situation the same on the :pandora1:confused: can there be a workaround of some sort, or will a port of Sauerbraten become impossible or very difficult? :( i hear emulation will significantly slow down the application...
 
Last edited by a moderator:
CC_machine said:
after asking about a port to the Pandora console on the cube/sauerbraten forums (cubeengine.com) we had this reply from the head of the cube/sauer project:
Aardappel_ said:
sounds to me like it has no hardware floating point. Porting Cube to fixpoint is a LOT of work.
The OpenGL ES part should be doable since Cube uses absolutely simplistic OpenGL. I wouldn't think of sauer as that would require major reworking.

The intel PDA that Jeff Rous ported it to seemed to have similar power to this thing, and it didn't run all that fast. It would probably be easiest to use exactly his version of Cube. Maybe he'd like to help?
I noticed i had troubles getting C++ code with floats to run on the :gp2x ... never looked for a solution. is this situation the same on the :pandora1: ? can there be a workaround of some sort, or will a port of Sauerbraten become impossible or very difficult? :( i hear emulation will significantly slow down the application...

Isnt this what the NEON instructions are for?
 
Last edited by a moderator:
Last edited by a moderator:
Pickle said:
Arialia said:
First Pandora CPU support floating data by NEON unit including
http://www.arm.com/products/CPUs/ARM_Cortex-A8.html
http://www.arm.com/products/CPUs/NEON.html

if compiler support NEON instructions everything is good :)

also i don't know this game , on what platform is run ?



The game he is asking about is a mainly linux based fps shooter,. I think its quake3 based.
I think I read the gcc compilier are codesourcery supports NEON.


It's not q3-based. Aardappel wrote it from scratch.
About gcc: http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html
 
Last edited by a moderator:
conso said:
Pickle said:
Arialia said:
First Pandora CPU support floating data by NEON unit including
http://www.arm.com/products/CPUs/ARM_Cortex-A8.html
http://www.arm.com/products/CPUs/NEON.html

if compiler support NEON instructions everything is good :)

also i don't know this game , on what platform is run ?



The game he is asking about is a mainly linux based fps shooter,. I think its quake3 based.
I think I read the gcc compilier are codesourcery supports NEON.


It's not q3-based. Aardappel wrote it from scratch.
About gcc: http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html
Thanks for the correction.
 
Last edited by a moderator:
CC_machine said:
Aardappel_ said:
sounds to me like it has no hardware floating point. Porting Cube to fixpoint is a LOT of work.
Just to add to what the others said, the Cortex-A8 has two FPUs (don't get excited, they can't work in parallel :p):
- VFPlite : it has support for single and double precision floats; it's not pipelined and hence slow
- NEON : it only supports single precision floats and is pipelined.
 
Last edited by a moderator:
It doesn't matter as the kernel and gcc provide different paths of floating point emulation, as well as the option to use neon etc.

All of the stuff that runs on the GP2X was not ported to fixed point :)
 
So is sauerbraten possible? It would be really cool to be modding right from a Pandora.
 
cb88 said:
yeah it has already be said that saubraten might be ported... only thing is that is it opengl and not opengl es
ES doesn't automagically prevent porting. ES is a subset of OpenGL. In many cases, you only need to make minimal changes to your code to make it compile properly against it. If you're using fixed functionality, you'll tweak a little bit at most and work against 1.1. If you're using any shader based stuff, you'll clean up any fixed functionality so that you're purely shader based and then do any minimal changes from OpenGL 2.0 to ES 2.0 that might be needed. ES 1.1 is largely identical to OpenGL 1.4 sans the immediate mode rendering and the addition of fixed point math support. ES 2.0 is largely identical to 2.0 sans immediate and fixed point rendering and the addition of fixed point math support. To be sure, I'm making it sound simpler than it actually is- but it's not a big overall nightmare to make a version if there's enough CPU and GPU muscle to have it run on.
 
Last edited by a moderator:
Back
Top