The Following 26 Users Say Thank You to Flandry For This Useful Post: | ||
ArnimS, Bazza, bigears5000, Chrome, corduroysack, Cue, elie-7, Fargus, FlashInTheNight86, gordonshowers, Helmuth, ivgalvez, leetut, NvyUs, OVK, pantera1989, russo_br, sbock, skalogre, Straycat, TooMuchMoney, twaelti, uris, v13, whaleyboy |
|
2010-01-31
, 06:54
|
|
Posts: 1,559 |
Thanked: 1,786 times |
Joined on Oct 2009
@ Boston
|
#2
|
The Following 5 Users Say Thank You to Flandry For This Useful Post: | ||
|
2010-01-31
, 15:27
|
|
Posts: 733 |
Thanked: 249 times |
Joined on Jan 2010
@ UK
|
#3
|
The Following 5 Users Say Thank You to Bazza For This Useful Post: | ||
|
2010-01-31
, 17:42
|
|
Posts: 103 |
Thanked: 162 times |
Joined on Jan 2010
@ Germany
|
#4
|
The Following User Says Thank You to sbock For This Useful Post: | ||
|
2010-01-31
, 21:44
|
|
Posts: 1,559 |
Thanked: 1,786 times |
Joined on Oct 2009
@ Boston
|
#5
|
Flandry, what do you think about adding some ARM optimizations from MAME4all (e.g. Cylone and Dr80 CPU cores)?
The source is available here: http://www.talfi.net/gp32_franxis/
GL ES support is not as easy as flipping a switch and it's not something i'm going to look into until it's clear it's the best way to get where i want MAME to be. There is no 3D rendering going on in MAME--it's all emulated--and from the few conversations on drawing performance i was privy to, the memory bandwidth of the device is often the limiting factor for graphics-intensive apps. I hope someone who knows the details better can pitch in with better knowledge, but my understanding is that without independent RAM of its own to use, bringing in the GPU for drawing can actually reduce performance because of extra transfers to/from RAM. Whether that's actually the case or not, the limitations of the N900 hardware compared to a PC are such that i'm not at all sure that GL ES is going to be worth the effort. I haven't done any detailed profiling yet since the update.
Regarding the question of how much the PR1.1 system updates influence SDLMAME performance, here's what i found (using just a single older ROM):
No hardware scaling: 34% -> 52%
YUV overlay: 86% -> 88%
Which is kinda what i expected as mentioned earlier.
One interesting thing is that the kernel is now more occupied during execution than the mame binary is, in either case. I'm not sure what that means, but it suggests that the actual emulation is still the minor part of the cycle usage.
Still not ready to take feature requests, but i have profiled the program again and the drawing and YUV translation functins are the holdups, so i am faced with coding optimized assembler routines or implementing GL ES to pursue any significant speedup. Before doing that i will probably do more thorough testing and tweak the keymaps and other control setups to see how the current codebase compares with my expectations. As has been noticed, much of the UI is still unaltered from upstream, which is intended for PCs wih full keyboards.
Community todo #3
A summary of which controls are actually important and which keys should be mapped to what is still welcome as i mentioned a while ago. Time spent messing with keymaps could probably better be spent on development.
The Following User Says Thank You to Flandry For This Useful Post: | ||
|
2010-01-31
, 22:18
|
|
Posts: 103 |
Thanked: 162 times |
Joined on Jan 2010
@ Germany
|
#6
|
I have added my quote about my philosophy and plans for SDLMAME from the emulators thread to the first post here. Short answer to your question: probably not, unless it turns out that the goals are unattainable otherwise. I want to track the upstream source as much as is possible, diverging only for customizations necessary for Maemo.
Here are a couple relevant posts about optimizing MAME from the emulators thread.
|
2010-02-01
, 06:17
|
|
Posts: 1,107 |
Thanked: 720 times |
Joined on Mar 2007
@ Germany
|
#8
|
The Following User Says Thank You to ArnimS For This Useful Post: | ||
|
2010-02-01
, 14:31
|
|
Posts: 1,559 |
Thanked: 1,786 times |
Joined on Oct 2009
@ Boston
|
#9
|
|
2010-02-01
, 15:47
|
Posts: 1,397 |
Thanked: 2,126 times |
Joined on Nov 2009
@ Dublin, Ireland
|
#10
|
Community Involvement
First, a warning: SDLMAME is not ready for general users. That's why it's only in Extras-devel. It can and will crash and/or lock up your N900, requiring a reboot. It could do worse. In short, it is a Work In Progress.
1: Bug reports
If you are going to just go ahead and install it anyway, which a surprising number of people seem to be doing, then you are recruiting yourselves as alpha testers. I will keep a list of known issues here. These issues will most likely become known because somebody experiences them and reports them, and that's the most likely way they will get fixed. I can't fix a problem i don't know exists, and i simply don't have time to
playahem, test most of the 0.135 ROM set.So, if SDLMAME crashes or doesn't work with a specific ROM, please give a detailed report here. If something seems to be broken or poorly working, please report it.
2: ROM status maintainers
There are some real hardcore MAME junkies here. Your task, should you choose to accept it, is to help maintain the ROM Status wiki. It should be an alphabetically-ordered list, divided into sections (Playable, Problematic, and Broken) and ideally contain information such as % speed performance. Also mark the Broken and Problematic ROMs with a "Confirmed" if you verify an existing report, so we can be sure it's not just one particular person's setup that's the problem. This will give me a better idea which machines are in need of help and it will give users an idea what is possible with MAME on the N900.
Currently i have a basic list in the second post, but i'm not going to update that without help.
3: Custom Configurations
Because there are so many ROMs with different control schemes, some are not going to work well with the defaults. It would be especially useful if some power users could try fiddling with the controls (.cfg files) and main mame.ini file to find the best settings.
All of the configuration files are in /home/user/.mame/ and its subdirectories. (That's just a "cd .mame" from the default x terminal prompt.)
Here's a guide to the mame.ini settings.
Status
Version
Package page
Old package page
The current version is 0.138u1.
The name was changed in version 0.137because SDLMAME was merged into the main MAME project.
Directories
Configuration base: /home/user/.mame/ Guide to mame.ini settings.
ROM base: /home/user/roms; /home/user/MyDocs/roms; /media/mmc1/roms (i.e. ./roms, ./MyDocs/roms (N900/roms from mass storage), and microSD card)
Controls
Besides the arrow keys and the keys on the lower left as various player 1 buttons, the 'q' key ('1' in Fn-land) is both the player 1 coin and player 1 start key. This seems to work ok in the games i've tried--you just press it twice to get going.
I suggest trying the accelemymote accelerometer-to-joystick driver. That utility can really add a new dimension to a lot of ROMs.
Known issues
- UI not adapted for N900
- Incomplete keymaps;
- Some ROMs cause lockups
- Performance is not where it could be. GL ES support is probably needed to accelerate drawing and scaling. This is a long-term goal but is not planned before the first public release.
TODOalso the Nokia keyboard localization bugFixed in 0.137-0maemo2Re-add arch and cpu flags to compilerDone(try reducing -o for starters)As you can see, there's a lot to do before this is ready for general release. Please be patient and consider helping out as requested.
Plans and goals for SDLMAME on Maemo
Originally posted here.
I'll make a few follow-up comments for context and expectation management. I will probably wax philosophical.
Philosophy of the SDLMAME Maemo port
The advantage of using the latest release of SDLMAME instead of an old MAME branch project like most mobile device port maintainers do is that all the improvements of the main upstream source go directly into the port for "free". In this case, there's an added bonus in that the SDLMAME maintainer has an interest in arm support for his own devices (which is why this port is possible right now). My intent is to just be a maintainer of the port, not a MAME developer. I don't have time to get fully into the MAME codebase, so this is a way to contribute to MAME and Maemo and possibly my own uses without a huge investment.
Similar to my reasons for using a modern MAME upstream source are my reasons for picking MAME itself. The good thing and bad thing about MAME is that it's a very thorough emulator. It's good because it means that if it emulates on any system it runs on, it should work on all of them. It's bad because it means there is more overhead than there would be if it had all kinds of speed hacks.
It's basically the stability and versatility vs. performance tradeoff common in the tech world. The N900 is a powerful enough system to run the ROM drivers i'm interested in seeing emulated without resorting to cheap hacks and custom projects, and future Maemo devices will only get better. Making a port that tracks the improvements in MAME and doesn't introduce hard-to-maintain device-specific changes will be a more useful contribution in the long run.
Expectations for SDLMAME on Maemo
All of that was basically an elaborate excuse to justify the minimal amount of changes to the upstream source i plan on making for this port. Besides the initial optified packaging that is done, getting the UI, config and keymaps into useful condition and any optimizations necessary to get reasonable performance on the old ROMs are the only other changes i plan on making.
And as for compatbility, if it is a pre-1990 ROM and works well in MAME on the PC, it should work well in this port when completed. That's my target.
Last edited by Flandry; 2010-06-13 at 19:57. Reason: SDLMAME merged into MAME