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

In anticipation of the port to the two similar arm cortex 8 devices running the linux kernel (Pandora and N900), i thought i'd start a thread here for discussion. I am not very familiar with MAME internals, so i hope to get up to speed and get to the point that i can contribute upstream from the to-be Maemo package.

0.135u2
I grabbed the 0.135u2 release and built it for the host system (Kubuntu Karmic/AMD64) and tested a few ROMs. Building is so effortless and the project is so much more polished than last time i visited it--kudos to all the devs.

I have the scratchbox environment of the SDK for debian-based maemo5 (Nokia's N900 OS) on an x86 virtual box. I tried to build for the x86 target, and had no trouble. However,

> ./mame sf2yyc -sdlvideofps -video soft -oslog -v
Build version: 0.135u2 (Dec 1 2009)
Build architecure: SDLMAME_ARCH=
Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1: LSB_FIRST=1 NDEBUG=1 DISTRO=generic SYNC_IMPLEMENTATION=tc
SDL/OpenGL defines: SDL_COMPILEDVERSION=1212 USE_OPENGL=1 USE_DISPATCH_GL=1
Compiler defines A: __GNUC__=4 __GNUC_MINOR__=2 __GNUC_PATCHLEVEL__=1 __VERSION__="4.2.1"
Compiler defines B: __unix__=1 __i386__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0
SDL Device Driver : x11
SDL Monitor Dimensions: 800 x 480

And then a whole lot of this:
'maincpu' (0C066A): unmapped program memory word write to 180000 = 0000 & FFFF
'maincpu' (0C068E): unmapped program memory word write to 180000 = 0014 & FFFF
'maincpu' (000320): unmapped program memory word write to 8001FE = 0000 & FFFF

Nothing is ever displayed.


./mame gngt -v
Parsing mame.ini
Build version: 0.135u2 (Dec 1 2009)
Build architecure: SDLMAME_ARCH=
Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1: LSB_FIRST=1 NDEBUG=1 DISTRO=generic SYNC_IMPLEMENTATION=tc
SDL/OpenGL defines: SDL_COMPILEDVERSION=1212 USE_OPENGL=1 USE_DISPATCH_GL=1
Compiler defines A: __GNUC__=4 __GNUC_MINOR__=2 __GNUC_PATCHLEVEL__=1 __VERSION__="4.2.1"
Compiler defines B: __unix__=1 __i386__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0
SDL Device Driver : x11
SDL Monitor Dimensions: 800 x 480
Using SDL single-window soft driver (SDL 1.2)
Keyboard: Start initialization
Input: Adding Kbd #1: System keyboard
Keyboard: Registered System keyboard
Keyboard: End initialization
Mouse: Start initialization
Input: Adding Mouse #1: System mouse
Mouse: Registered System mouse
Mouse: End initialization
Joystick: Start initialization
Joystick: End initialization
Audio initialized - driver: alsa, frequency: 48000, channels: 2, samples: 1024
sdl_create_buffers: creating stream buffer of 57344 bytes
ouput: unable to open output notifier file /tmp/sdlmame_out
AY-3-8910/YM2149 using legacy output levels!
AY-3-8910/YM2149 using legacy output levels!
Soft reset
'maincpu' (6036): unmapped program memory byte write to 3D01 = 00
'maincpu' (615C): unmapped program memory byte write to 3D01 = 01

This one shows a single frame just as it is killed (<ESC>), so i'm guessing i messed up something with the display. Should it be compiled without OGL at all? I couldn't see a setting for it.

That looks like possibly an endian issue - is the N900 big-endian?

Little endian. This is still on the SDK running in scratchbox. I'm taking it one step at a time.

Host PC -> SDK scratchbox in x86 VM -> armel target compile -> N900 test.

To clarify, the SDK isn't an emulator. It tries to replicate the OS and repos of the N900, but runs binaries compiled for the x86 target.

Only made it to step 2.

Understood. The scrachbox is x86 (ie, 32-bit) even though you're running on an x64 host?

The SDK supposedly has issues with AMD64, so for simplicity the virtual box image is Karmic x86. The host for that virtual box is indeed 64-bit. Whether that actually simplifies things i don't know, but it seemed a good idea at the time.

Understood. I was just trying to figure out if you needed PTR64=1, although normally having it set wrong results in many compiler errors

I switched to armel target to see if it would build there. It didn't get very far:

Compiling src/osd/sdl/strconv.c...
cc1: warnings being treated as errors
In file included from src/emu/devintrf.h:19,
from src/emu/video.h:18,
from src/emu/mame.h:16,
from src/osd/sdl/strconv.c:21:
src/emu/memory.h: In function 'memory_decrypted_read_word':
src/emu/memory.h:1109: warning: cast increases required alignment of target type
src/emu/memory.h: In function 'memory_decrypted_read_dword':
src/emu/memory.h:1116: warning: cast increases required alignment of target type
src/emu/memory.h: In function 'memory_decrypted_read_qword':
src/emu/memory.h:1123: warning: cast increases required alignment of target type
src/emu/memory.h: In function 'memory_raw_read_word':
src/emu/memory.h:1152: warning: cast increases required alignment of target type
src/emu/memory.h: In function 'memory_raw_read_dword':
src/emu/memory.h:1159: warning: cast increases required alignment of target type
src/emu/memory.h: In function 'memory_raw_read_qword':
src/emu/memory.h:1166: warning: cast increases required alignment of target type
make: *** [obj/sdl/mame/osd/sdl/strconv.o] Error 1

Right, so i turned off optimizations so it wouldn't treat warnings as errors and ran into the expected problem of no opengl support. How do i disable opengl for building, not just during execution?

I think going to software rendering first and then worrying about gles is the way to go.

Change src/osd/sdl/sdl.mak and uncomment the line reading

I've never tried it, though.

Hmm, that option compiles on the host (where opengl.h is available, so that doesn't necessarily mean much), but in the armel target, it fails like this:

Linking mame...
obj/sdl/mame/libocore.a(sdlwork.o): In function `osd_work_queue_wait':
sdlwork.c:(.text+0x404): undefined reference to `osd_yield_processor'
obj/sdl/mame/libocore.a(sdlwork.o): In function `osd_work_item_wait':
sdlwork.c:(.text+0xbc8): undefined reference to `osd_yield_processor'
obj/sdl/mame/libocore.a(sdlwork.o): In function `worker_thread_entry':
sdlwork.c:(.text+0x10b0): undefined reference to `osd_yield_processor'
collect2: ld returned 1 exit status
make: *** [mame] Error 1


Progress, anyway--got as far as linking.