Uae4arm: Amiga emulator with JIT and DispmanX

[Chips]

The version for RPi2 fully uses the quad core CPU ?
All cores works together ? (I've both Rpi1 and 2)

Not really... and since Amiga was single core and it's chipset needs to be tightly synchronized every few cycles with CPU i don't see any room for parralelization ... only audio rendering use some thread but it's only for synchronization...

Using UAE4ARM on Rpi2 is definitively better than with Rpi1 (at "same" clock speed) ? Why ?

UAe4arm Rpi2 is compiled with neon enabled and armV7 profiling... Rpi1 version is compiled without neon and with armV6 profiling (the Rpi1 is one ARM generation behind)... by choosing armV7 we enable goodies for this architecture which improve efficiency...
Moreover for the same code the cortex are more efficient at same speed that Arm11...

There is an updated guide to understand how to get and install (and easily upgrade to latest versions) only the latest package in Raspbian ?

Just clone the github repository and follow what is in readme. It has been updated for raspbian jessie...

[Chirone72]

Many thanks for your answers Chips,
after reading them I bought a second PI2 to use as an Amiga with direct boot (the other is already inside a C64 case, taken from a broken machine).

I've followed the instructions to compile sources, I've executed them inside the right folder and all was fine.

This evening I'll try your instruction to boot directly to uae4arm, hoping that will work also for Jessie.

Regards

Fabio

[bite_your_idols]

is it possible to use this in OpenELEC?
I am trying to make it run but with no luck.. .

EDIT:

I switched to OSMC but now I get "segmentation fault"...

any help?

EDIT 2: Finally I get it working in OpenELEC flawlessly!!! amazing work!!! a virtual/on-screen keyboard that could be toggled with a joystick button would be perfect

thanks and sorry about my english...

[HoraceAndTheSpider]

@Chips

Is there any plan to improve the controller mapping to something akin to e-uae for example?

Many WHDload games add CD32 pad controls, which would suit the target environment under Retropie very well. I cannot see how these can presently be mapped? (looking at the files under conf/ i could not even add the controls manually as I would with other UAE variants) ... unless i am being really dumb (which is possible) and missing something.

For me this is something of a 'deal breaker' and I think would be a very popular addition, along with controls for mapping mouse controls back to controllers. (although i appreciate this is a harder task, perhaps code for this could be 'borrowed' from something like PSPUAE that has implemented it very well)

It's also helpful to have some other emulator controls such as reset/config menu/quit emulator etc which people can tap into... I didnt notice any of these on the available controls list.


I am using the latest version bundled with RetroPie, so my apologies if i have missed such additions with a new version which hasnt yet been included there.

[Haemogoblin]

I'm also eager to see if key mapping is developed close the WinUAE, I have a Keyrah fitted inside my AmigaPi and would love to have UAE4ARM mapped so that I can make use of it. The Keyrah has two joystick ports, mapped to the num pad and cursor keys. If I could map the emulator to use those keys, I'd be able to use a real Amiga joystick.

[witchmaster]

I'm also eager to see if key mapping is developed close the WinUAE, I have a Keyrah fitted inside my AmigaPi and would love to have UAE4ARM mapped so that I can make use of it. The Keyrah has two joystick ports, mapped to the num pad and cursor keys. If I could map the emulator to use those keys, I'd be able to use a real Amiga joystick.

I just got two real Amiga joysticks working in both the C64 emulator and UAE4ARM using the GPIO module (Db9_gpio_rpi) as described here: https://github.com/RetroPie/RetroPie-se ... IO-Modules . Works flawlessly as far as I can tell. Only components required are some cables that connect to the gpio header and two db9 female connectors. I'm using a Pi3 with Retropie 3.6.

[bite_your_idols]

do these inputs work in pi version:
https://github.com/Chips-fr/uae4arm-rpi ... andora.txt

I can not make them work and it would be awesome using the emu without mouse.

thanks!

[escalade]

@Chips

First off, thanks a lot for the hard work.

I've just spent several hours getting uae4arm and it's dependencies cross compiled for my OpenELEC build. So I got everything built, but when running it I get this:

./uae4arm: symbol lookup error: ./libSDL-1.2.so.0: undefined symbol: FB_InitOSKeymap

Any ideas? I used this SDL: https://github.com/vanfanel/SDL-1.2.15-raspberrypi

[Vanfanel]

@Chips

First off, thanks a lot for the hard work.

I've just spent several hours getting uae4arm and it's dependencies cross compiled for my OpenELEC build. So I got everything built, but when running it I get this:

./uae4arm: symbol lookup error: ./libSDL-1.2.so.0: undefined symbol: FB_InitOSKeymap

Any ideas? I used this SDL: https://github.com/vanfanel/SDL-1.2.15-raspberrypi

Escalade: stop using that version of the SDL 1.x libs. SDL 1.x is broken on the Pi with current raspbian, it's unmantained and bit-rotten: SDL1 is DEAD. There's an official SDL 1.x package on Raspbian that has my dispmanx backend integrated, you would have to install it and use SDL_VIDEODRIVER=dispmanx to use it, no need to build any custom SDL 1.x version, but you will get black screens and console lockups now and then.
All in all, using SDL 1.x on the Pi today is just a bad idea. I ported many programs from SDL1.x to SDL2 when I had time to do so, but I don't have that much time anymore so if you want stable and reliable uae4arm JIT on the Pi, ask chips for an SDL2 port, or just wait for this to happen --> https://github.com/r-type/uae4arm-libretro

@chips, you really need to take this to SDL2, man.
For someone who knows the UAE4ARM code as you do, it's very easy.

[escalade]

Thanks for your reply vanfandel. My goal is to get it compiled and working on OpenELEC, as I don't really like raspbian. I'll have a look at using the SDL1.2 codebase from raspbian instead.

I didn't know that a libretro core was being worked at, that is just awesome. I've already got retroarch packaged up thanks to Lakka.

[escalade]

Sorry for the doublepost, didn't see a way to edit my previous post.

Turns out my SDL was built incorrectly, and after recompiling everything from scratch I've managed to produce a working SDL with dispmanx.

I can compile both uae4all2 and uae4arm just fine, but uae4arm segfaults like this:

# ./uae4arm
Uae4arm v0.4 for Raspberry Pi by Chips
starting sound thread..
Current resolution: 0 x 0 16 bpp
IP: 0xd9800 [e593200c] 0x8f6d600c
Segmentation fault (core dumped)

uae4all2 on the other hand works great, smooth scrolling and good sound. Only problem is, there is seemingly no way to quit the emulator once you run a game?

[bite_your_idols]

escalade, I have uae4arm working in openelec, I just get the binaries from first post and pick up from rapbian all needed libs. You can get it from here:
https://github.com/bite-your-idols/game ... arm.tar.gz

about amiga libretro, here you have a video from a year ago with libretro-uae working in openelec:
https://www.youtube.com/watch?v=9SR2DvcZF3I

In latest recalbox version it is included also but not used, they told me that will work in next release...


About input configs, nobody can tell me if it is possible to simulate mouse clicks with the gamepad? It does not work with my dualshock 3 and 4...

[Chips]

@chips, you really need to take this to SDL2, man.
For someone who knows the UAE4ARM code as you do, it's very easy.

Since dispmanX do exist I would not see any benefit for SDL2... uae4arm as libretro core is a good option though...
Between GLES backend is available too in the github... it can works in Rpi and should works in others Arm board (like odroid and the likes). It is working on a RK3066 board I have... but it's still very early version...

[escalade]

Compiling against GLES sounds interesting, but compiling fails like this:

Code: Select all

src/od-pandora/neon_helper.s:766: Error: selected processor does not support `vst1.8 {d0,d1,d2,d3},[r0]!' in ARM mode

Any ideas how to procede?

[Chips]

You need at least a Pi2 and note that it's only a basic implementation (no fullscreen, no picasso...)

Since raspbian is still Arm11, you need to tell compiler that you truly have a neon platform:

make PLATFORM=gles CPU_FLAGS="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"

But the GLES vesion is more for others ARM board and a starting point for developers... (well i'm still the only one improving this port ) so you'll have no support for it...

Note that you'll need to uncomment a line in latest makefile (see Makefile)...

[Vanfanel]

@Chips: SDL 1.x is bit-rotten. There are many problems now, related to firmware updates. Some where patched, some appear at times...
https://github.com/raspberrypi/firmware/issues/354

SDL 1.x is a dead end. SDL2 on the other hand offers hardware acceleration by default on tthe Pi. No need to mess with dispmanx or GLES.
MUCH better input support, no black screens, and a future for the code.

[escalade]

Got it compiled after adding the compiler flags, thanks! Works very nicely, other than aspect ratio and scaling seems a bit off. Hope you will continue improving it

[escalade]

Just wanted to chime in and say that it's working perfectly with GLES on my RPi3 now, both graphics and sound.

For anyone interested, I've uploaded my custom OpenELEC build with everything ready to go here:

http://openelec.tv/forum/124-raspberry- ... rch#160155

Now back to playing Battle Squadron

[asapreta]

Guys, I dunno if I mistaken but I remember I saw a post with the instructions how to decompress and compile the latest version in the PI itself but I have read again all the thread and couldn`t find it. Can you help/point me?

I already have downloaded the latest version on my macbook and sent it to PI over SSH.

Thanks.

EDIT, I think I just figured it out. As I am on RetroPie (3.6) I need to do this:

sudo apt-get install g++-4.8

Then for Raspberry Pi 2:
make CXX=g++-4.8

Those below are up-to-date:
libsdl1.2-dev
libsdl-gfx1.2-dev
libsdl-ttf2.0-dev
libguichan-dev

[escalade]

@Chips

Is .ipf supported in uae4arm? I see that it's defined as a diskimage extension in zfile.cpp, but I can't seem to load .ipf's.

[noobberrypi]

Has anyone figured out how to set custom controls?

I would like to assign the joypad/stick up to the B button on a Joypad because most Amiga platform games are designed for joystick use not joypad, so pushing upwards on a stick would typically make your sprite jump.

Didn't the CD32 do something along these lines by assigning jump to a button?

It seems that libretro-uae is now a possibility based on some of the previous posts.
Has anyone tried compiling libretro-uae for Retropie? That would seem to be a good option for customising controls and providing all the extra features that Retroarch provides as well as EmulationStation launching of individual disks!

Uae4arm will remain an important project for custom setups.

[Chips]

I just pushed improvement of keyboard management... at least more keys are supported on my french keyboard. One change: now use F12 for switching between emu and gui...
Look like right shift is not doing what is expected... I don't understand why...
Quite come code from pandora has been commented out... i don't know the impact... i will look later

Is .ipf supported in uae4arm? I see that it's defined as a diskimage extension in zfile.cpp, but I can't seem to load .ipf's.

No. Moreover I think the ipf library is closed source and support only x86 ATM...

[Vanfanel]

@chips:

uae4armJIT is being ported to libretro at last, take a look here:

https://github.com/r-type/uae4arm-libretro

retroarch, libretro's front-end part, has different resamplers, perfect physical video rate synchronization, etc.
Maybe you could help r-type, the libretro porter, instead of doing fixes for the bit-rotten and unsupported SDL1.x port?

[Chips]

Yes i see but i've never been a big fan of retro-arch: the default menu sucks, core are always behind the best standalone ones and no frontend are well adapted for computer emulation.
But it's a killer for an all-in-one emulation box... (well I even think that pi can't be perfect due to un-availability of pixel perfect composite mode...)

[Vanfanel]

Yes i see but i've never been a big fan of retro-arch: the default menu sucks, core are always behind the best standalone ones and no frontend are well adapted for computer emulation.
But it's a killer for an all-in-one emulation box... (well I even think that pi can't be perfect due to un-availability of pixel perfect composite mode...)

That's not true. Most cores are in-sync with upstream emulators and engines.
Please don't spread these wrong ideas.

Also, while standalone emulators show graphic/sound problems due to synchronization, they look and sound perfect under Libretro/Retroarch.
As for the menu, please try www.lakka.tv, the "console" solution by the RetroArch team. It will only take a moment to download and burn to SD.

As for "pixel-perfect composite", that would make no sense on a modern display as most users have. NTSC-artifacting shaders and filter is the solution.
For example: try the Genesis Plus GX core with the scanlines shader and Blargg's NTSC filter, on an Rpi2/3 connected to an HDMI monitor. You wil understand what I mean when you see it. Good luck getting these AWESOME results with a real MegaDrive/Genesis connected via crappy composite to a modern TV...