Home Page Forums MAME Non-Windows MAME Support Arm Akimbo SDLMAME

Hello, Flandry:

Currently, I have compile the mame 0.136 for s3c6410(arm11 running linux 2.6.28.6) soc chip. But the mame speed is very slow, I found you say that using the yuv overlay will give pretty good performance. Can you tell me how to open the yuv overlay in mame.

Thank you!

zircon

You probably want to set the 'scalemode' option:

But I'm not sure if that makes it faster for you... or if that answers your question .

I have try the none, async, yv12, yuy2, yv12x2, yuy2x2 options. But if using any y* options, the speed is slower than the none option.

I think the N900 have the yuv overlay accelerated function in framebuffer driver, but my linux no support it.

Is it just a scaling problem, that is, how well does it perform in "native" resolutions? Try "-window -nomaximize"... if it's not fast enough either, than it's no X driver issue anyway.

Or to just test the CPU, try running with "-str 30 -video none".

Did you even run with "-video soft" -- the scalemode settings are only valid with software video (that's the default).

IIRC, the N900 has an SGX chip and the latest X.org fbdev drivers should at least contain parts of the hw-accel features, but I've no clue about the details...

After running into problems during 0.136 releases, 0.137 builds and runs on Maemo 5 with just a few tweaks to the
src/osd/osdmini/miniwork.c file. I added a cast and changed the calls to free and malloc to osd_free and osd_malloc, respectively.

Very nice work.

I'm pretty sure changing those calls means you're going to trash memory or something, but couriersud knows the details and I don't.

Eek, that doesn't sound good.

From looking at the .h file it seemed like the wrapper functions were the appropriate fixes. Hopefully he'll chime in if that's not the case.

It seems to work ok so far anyway.

Did you give up on your Pandora ever coming?

Apparently the power bricks for the Pandora arrived at the assembly site in the UK but not the cases or PCBs yet. I'm pretty much just laughing it off at this point.

Palm's PDK (native-code devkit) is out but annoyingly it requires either Mac or Windows, which is funny since the actual devices run Linux, SDL, and OpenGL.

Currently using 0.138 on Maemo 5 (N900). There's a pronounced slowdown at the beginning of rtype that lasts for about 30 seconds, and then it runs at ~90%.

Profiling shows that libgcc_s.so is consuming 21% of the cycles during this initial period and the highest mame routine (cpuexec_timeslice(running_machine*)) 17%.

After that initial slow period, the distribution of cycles changes, with ym2151_update_one consuming 11.6% and all the rest of the routines less than 10%.

What is going on here? Is there some kind of dynarec built in?

There is no dynarec for rtype. Probably just that the startup code of the game incurs more reschedules due to testing timers and such. I gather from ym2151 being expensive that the N900 doesn't have hardware floating point?