OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: chiark on February 01, 2006, 05:56:03 am
-
I've built UAE from source - a mercifully simple job - and am wondering if there's any particular compiler optimisations that are recommended for the Zaurus platform?
Performance is pretty good, but at the moment it couldn't really be used for games. It's not too far off though, particularly if frameskip is set to 3 and sound is turned off.
Advice on how to package up an ipk would be good, too?
I'm going to try the package with and without SDL graphics, and with and without SDL sound. The SDL graphics version seems fine, but SDL sound seems slow.
Anyone else interested?
-
don't know for the optimization.
how to make an ipk:
http://mail.pdaxrom.org/contrib/docs/making_ipkg_howto.html (http://mail.pdaxrom.org/contrib/docs/making_ipkg_howto.html)
is this the same as
e-uae_0.8.28-RC2-1_armv5tel.ipk (http://mail.pdaxrom.org/1.1.0beta1/Zaurus-7x0-860/feed/e-uae_0.8.28-RC2-1_armv5tel.ipk)?
-
That one is based on the 0.8.28 RC2 codebase; I've built using the formal release of 0.8.28. The delta's not huge, but
There are many many many options for compilation too (provided by configure) so I guess I should contact whoever created that version to see if they found any optimisations and also what worked better for the sound/gfx output.
A weird bug: the program segfaults if the on screen keyboard is present when the app starts, however starting after UAE has started causes no problems.
Thanks for the link to the guide - how embarassing that I couldnt' find that for myself
I'll carry on playing and see what gives me the best performance. I'm assuming that SDL in the beta1 feed is pretty much optimised and that there's no benefit of playing around with that?
I'll also see if I can find what compiler opts might work. Given that a configure/build takes around 20 minutes on the Z, this could be a long process
-
so I guess I should contact whoever created that version to see if they found any optimisations and also what worked better for the sound/gfx output.
It's compiled by sash with the pdaxrom-builder, you should find the info you need by looking into it (in something like rules-ipk/e-uae.make)
-
pgas: What's the bests CFLAGS for SL-Cxx00?
How to activate iwmmx support?
-
Thanks again pgas for your help with what must be a pretty n00b question
-
pgas: What's the bests CFLAGS for SL-Cxx00?
How to activate iwmmx support?
sorry I don't know, I don't have a CXX00 ....
-
Hmm, there's nothing in the ipk, so I'll drop sash a mail. I know he's busy, but it's worth a try
-
Hmm, there's nothing in the ipk
yeah, the rules are in the builder:
http://mail.pdaxrom.org/1.1.0beta1/pdaXrom...7.12.05.tar.bz2 (http://mail.pdaxrom.org/1.1.0beta1/pdaXrom-builder-20.49_27.12.05.tar.bz2)
I had a look at rules-ipk/e-uae.make sash doesn't seem to use something special.
-
"D'oh!"
I'll get to a basic level of knowledge on the system soon
-
I'm presuming that both of these Zaurus UAE ports don't include the cyclone ARM ASM M68k emulator? If somebody gets that integrated into uae it should speed things up a lot.
I know there are lots of GP2X owners who want to run uae so I wouldn't be surprised to see some Gp2X devs teaming up with some Z devs, as we've seen with zpsx, to get this done. I hope so anyway!
-
I'll look into the Cyclone side of things - thanks for the tip. Do you have any experience of how well cyclone compares with other (C/C++) implementations of a 68k?
I know e-uae supports JIT compilation on the x86 platform only, so there might be quite a bit more we can squeeze out of the arm side of things.
-
How to activate iwmmx support?
-march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt as I remember...
-
An early version of UAE for the GP2X is out now but its quite slow at the mo apparently. It is a port of a UAE version for the Dreamcast called UAE4ALL
I was reading this thread
http://www.gp32x.com/board/index.php?showtopic=25056 (http://www.gp32x.com/board/index.php?showtopic=25056)
and the bad news is that someone else who tried porting UAE to the GP2X says that cyclone doesn't seem to be compatible with it
I'm sure there is still hope for getting UAE running well on ARM.
-
Cheers for the updates everyone. That's sad about cyclone... I haven't yet looked into the cpu emulation of UAE, but it might be possible to nastily hack it in, surely?
It's a pure 68k emulator, not an 020/040 emulator, so it'd be definitely best for old games, etc...
-
I once participated in an elliptic curve cryptography cracking project hosted by Robert Harley. On the Alpha processor-based computer that I used for that effort, Robert Harley's code ran faster with the -O2 optimization flag than the -O3 optimization flag. I am guessing that the speed optimizations such as loop unrolling and function inlining, which cause the size of the code to grow, caused instructions in the instruction cache to be displaced by redundant code, slowing down the execution of the non-redundant code as it had to be fetched from main memory. You could try the -O2 compiler option and see if the code runs faster.
-
Thanks for that - it's currently being built with -O2 optimisations.
I've rebuilt with iwmmxt support for CPU and Architecture, but am omitting the -mtune option as that seems to cause a segfault.
UAE is running acceptably fast without sound like this, and is usable on most things with a frameskip of less than 4 which is good.
Turning on sound completely slows down emulation. There must be a way to deal with this somehow - I'll have a play.
-
Well, I've been playing and am stuck.
Sound blows emulation out of the water still. I've mailed Rich Drummond and got a responce suggesting something that might help (using a lookup table rather than relying on CPU multiplication for sound) but that doesn't make any difference.
I've built with both the SDL and non-SDL sound side of things, both seem about the same.
Any ideas? :-)