Uae4arm: Amiga emulator with JIT and DispmanX

[Haemogoblin]

Chips on a totally different subject and not wanting to sound like a broken record. Are there any plans to improve or look at the keymapping in uaerarm? So that it's a little more versatile like winuae?

[windale]

@chips

I'm not blaming any of the features, your port is excellent, even better than the Android version (more up-to-date/less bugs). I just thought that because the Pi is only 900mhz the emulator can only speed things up so far and the Pandora is even less powered. I repeat, your port is excellent, i'm very happy with it.

[Chips]

Looks like AGA is broken on Rpi1... the same binary is OK on Rpi2 but on Rpi1 it loops before kickstart get displayed...
I was wondering, who is anyway fool enough to use AGA on Rpi1
It looks like 68020 JIT generate ARM code which is not supported on Rpi1...(strange since i was expecting JIT to generate ARMV6 code...)

Chips on a totally different subject and not wanting to sound like a broken record. Are there any plans to improve or look at the keymapping in uaerarm? So that it's a little more versatile like winuae?

I would like to improve this, but since there is all thoses small issue taking my time and new versions from TomB giving small regression it's delaying improvements... note that i didn't catch exactly your problem, what i would like to improve on uae4arm is to handle correctly international keyboard mapping (currently it's hard coded for US mapping)

[Haemogoblin]

Hi Chips

The problem I'm having with the keyboard, is that it doesn't look like it is being registered properly by the emulator. I think AmigaPI was looking in to it and said they had found something was wrong.

In Workbench, I ran the program keyshow, which gives you a graphical representation of the keyboard. If you press a key on the keyboard, the corresponding key lights up on the screen. However in the emulator, the only keys that worked were left and right shift. If I recall, left shift registered as Shift and right shift registered as Alt.

[amigapi]

Yes I'm currently working on it.

This part of the sources is very strange. Every key is set in the right term but not all of them are registred the right way.

One example arethe Amiga-Keys.

I have to look a little deeper into the sources to fix this.

[Haemogoblin]

Another annoying feature of uae4arm, is the cursor keys move the cursor around in workbench. Made life a pain trying to edit my startup sequence lol

[amigapi]

This should be an issue with the Joystick 2 Keyboard mapper. Hopefully Chips can tell you where you have to alter the sources

[Haemogoblin]

Hope so, I've no doubt that eventually this will be a really nice emulator for the pi, it's just getting there that takes time.

[Trixster]

I've just tried a fresh Classic WB advsp setup on the latest uae4arm. It works really well especially with a load of z3 ram added. Starstruck works surprisingly well. I'd say about 040 performance which I'm pretty impressed with.

Is there any way to stop the interlace flicker when setting Screenmode prefs to 640x480 hires pal interlaced? Or do I have to setup a Picasso Classic WB for this?

[amigapi]

There is currently no flicker-fixer implemented. To get this someone has to implement the double-renderer.

To use a better resolution just install picasso with the latest uaegfx drivers. This will also make your Workbench response faster.

[windale]

So does the ClassicWB P96 package work on this emulator ? I noticed that there isn't an option for RTG memory and the screen resolution doesn't do 'Hi-Res' resolutions. Would it work ?

[amigapi]

It should work. The Classic WB P96 Package includes the uae-drivers.

I think you should find the GFX-RAM under the misc options.

[windale]

It should work. The Classic WB P96 Package includes the uae-drivers.

I think you should find the GFX-RAM under the misc options.

Just tried it and it doesn't work. There's no RTG in the Pi version (broken/no option).

[Trixster]

Actually, running c:Magictv makes a noticeable improvement.

[amigapi]

Are you shure that you are using the latest uae4arm from github?

If you are using uae4all it isn't possible to use p96 and you have no jit-compiler

[windale]

Are you shure that you are using the latest uae4arm from github?

If you are using uae4all it isn't possible to use p96 and you have no jit-compiler

Yes, I don't use UAE4All, it's obsolete/only for Pi 1 users (in my opinion).

[pawelkrak]

Hi @chips

i'd like to say You big thanx (in latest compilation PICASSO working very well, sounds work good no lags) but I have still that same question. Can you make a working status LEDs like WINUAE and USB KEYBOARD (ex. POWER LED is NUMLOCK, HDD LED is CAPS LOCK and DF0 LED is SCROLL LOCK). Im using keyrah but leds dont lit.

regards Paul

[pawelkrak]

Are you shure that you are using the latest uae4arm from github?

If you are using uae4all it isn't possible to use p96 and you have no jit-compiler

Yes, I don't use UAE4All, it's obsolete/only for Pi 1 users (in my opinion).

Try to recompile from github. Im do this and p96 now work. Compilng time take a 15 mins.

[pawelkrak]

For anyone whos have problems with Picasso working or have problems with compiling. Unpack, delete old non working uae4arm and copy this one. Make chmod 0755 and run. Happy 2016 year

http://www.filedropper.com/uae4arm

/opt/retropie/emulators/uae4arm

[DarkGiver]

Hello,

I've got some troubles with latest version.

The mouse response is very laggy (tested on raspberry pi2 jessie), it was not the case with previous 0.4 (but picasso96 was not working properly). Anyone else noticed this problem?

Thank you.

[pawelkrak]

Yes confrim. Try to decrease mouse speed in GUI. For me work

[DarkGiver]

It seems to be more than the mouse... something is broken since the 0.4 "align with Tomb 1.0.2"

Try a version just before everything run smooth except picasso96 uaegfx totally bugged

[Chips]

Strange, i don't have so much lag on my setup and i don't feel any difference with 0.4. CPU set as fastest seems to add a little bit lag compared to fixed clock but not so much...
Is it only on Picasso ? Are you sure you set your Rpi to a 50 Hz mode ?
I remember an update from TomB was leading to some frame stall, i didn't have time to check for a proper solution but you can try what i proposed in this post:
viewtopic.php?p=835093#p835093

[DarkGiver]

Hello,

Tested the sound_sdl_new.cpp modification.. no change.

No change with 50hz or 60hz

Mouse moves are laggy (move horizontaly slowly and faster and you will notice the stuttering) no matter the screen resolution or cpu configuration. It can be barely noticable when using a pad or something else but is an evidence when using a true mouse and trying to draw something with deluxe paint

That's especially odd because everything is fine with this version compiled and before : https://github.com/Chips-fr/uae4arm-rpi ... 2e2f50de42

And trouble starts with this one : https://github.com/Chips-fr/uae4arm-rpi ... 12e63175dd

[Chips]

Is only fast mouse speed that is affected ?
There is 2 strange lines related to mouse in the latest tomB which has been integrated:

Lines 913 & 914 in pandora.cpp :

if(rEvent.motion.xrel > 20 || rEvent.motion.xrel < -20 || rEvent.motion.yrel > 20 || rEvent.motion.yrel < -20)
break;

Try to comment both...

EDIT: or simply take the solution push in github minutes ago... thoses lines give only troubles on Rpi ...