Uae4arm: Amiga emulator with JIT and DispmanX

[neuro_999]

If you can make a serial emulation trought Pi GPIOs to emulate Amiga Serial Comms (To play serial conected games like fire power, stun car racer...) you will be my hero.

[MiDWaN]

If you can make a serial emulation trought Pi GPIOs to emulate Amiga Serial Comms (To play serial conected games like fire power, stun car racer...) you will be my hero.

Although that's possible, I'd much rather see a version with support for AmigaLive instead: http://www.amigalive.com/
Why limit yourself to serial and not go all the way?

[HoraceAndTheSpider]

If you can make a serial emulation trought Pi GPIOs to emulate Amiga Serial Comms (To play serial conected games like fire power, stun car racer...) you will be my hero.

Although that's possible, I'd much rather see a version with support for AmigaLive instead: http://www.amigalive.com/
Why limit yourself to serial and not go all the way?

That's just a front-end for FS-UAE's existing NetPlay support ... which i would very much endorse being added! (although you'd then get into needing to add other FS-UAE features like database/file management!)

[MiDWaN]

If you can make a serial emulation trought Pi GPIOs to emulate Amiga Serial Comms (To play serial conected games like fire power, stun car racer...) you will be my hero.

Although that's possible, I'd much rather see a version with support for AmigaLive instead: http://www.amigalive.com/
Why limit yourself to serial and not go all the way?

That's just a front-end for FS-UAE's existing NetPlay support ... which i would very much endorse being added! (although you'd then get into needing to add other FS-UAE features like database/file management!)

Well, it's nice to have a target to aim at...

[escalade]

Hi all,

I've forked this project in order to fix some bugs, add a few new features I wanted and try to improve it.
https://github.com/midwan/uae4arm-rpi

Currently, some of the things I've changed are:
[*]New target platform: Pi 3
[*]Optimizations for Pi 3 added
[*]Pi 3 is now the default target if no Platform is specified
[*]Added support for custom functions assignable to keyboard LEDs (e.g. HD activity)
[*]Code formatting and cleanup
[*]FullHD (1080p) resolution supported in Picasso96 mode.
[*]Pi Zero / Pi 1 version now has full Picasso96 support.
[*]Removed Pandora specific keyboard shortcuts which caused crashes
[*]Loading the Configuration file now respects the input settings
[*]Fixed bugs and crashes in GUI keyboard navigation

There is a pull request waiting for almost a month now, but unfortunately I haven't heard anything from Chips about it. Perhaps he's busy of course.

The next logical step is to move it to SDL2. I've already started working on that on a separate branch:
https://github.com/midwan/uae4arm-rpi/tree/sdl2

The SDL2 stuff is not finished yet, so it will compile but not work yet. And that's the part I would like to ask about.

From what I checked and tested, the "official" SDL2 package for Raspbian does not use DispmanX as the backend. It seems to need an X11 environment in order to create a Window, which is obviously not ideal for the Pi. I saw some customized SDL2 ports on Github that were created to include DispmanX as the backend, but I didn't try those yet.

So the question is, if we want to use SDL2 with hardware acceleration from the console, which package should we use? Compile a custom version and include that in our projects, or is there something I've missed?

While an SDL2 port is very welcome, I can't help but think that your efforts would be better spent on porting it to libretro. R-type started porting it, but seems to have abandoned that project. The core works but sound is messed up.

There's also ongoing work to port FS-UAE to libretro. This core is already working very well, even on ARM/RPi3 (with accuracy=0).

The advantage of using libretro are many, but having audio/graphics/controls abstracted is quite awesome. Controllers can be hotplugged and detected by udev, and you get support for stuff like KMS/EGL and Vulkan for free. The RetroArch frontend also allows for enabling shaders, scraping games, displaying boxart and such.

[MiDWaN]

Hi all,

I've forked this project in order to fix some bugs, add a few new features I wanted and try to improve it.
https://github.com/midwan/uae4arm-rpi

Currently, some of the things I've changed are:
[*]New target platform: Pi 3
[*]Optimizations for Pi 3 added
[*]Pi 3 is now the default target if no Platform is specified
[*]Added support for custom functions assignable to keyboard LEDs (e.g. HD activity)
[*]Code formatting and cleanup
[*]FullHD (1080p) resolution supported in Picasso96 mode.
[*]Pi Zero / Pi 1 version now has full Picasso96 support.
[*]Removed Pandora specific keyboard shortcuts which caused crashes
[*]Loading the Configuration file now respects the input settings
[*]Fixed bugs and crashes in GUI keyboard navigation

There is a pull request waiting for almost a month now, but unfortunately I haven't heard anything from Chips about it. Perhaps he's busy of course.

The next logical step is to move it to SDL2. I've already started working on that on a separate branch:
https://github.com/midwan/uae4arm-rpi/tree/sdl2

The SDL2 stuff is not finished yet, so it will compile but not work yet. And that's the part I would like to ask about.

From what I checked and tested, the "official" SDL2 package for Raspbian does not use DispmanX as the backend. It seems to need an X11 environment in order to create a Window, which is obviously not ideal for the Pi. I saw some customized SDL2 ports on Github that were created to include DispmanX as the backend, but I didn't try those yet.

So the question is, if we want to use SDL2 with hardware acceleration from the console, which package should we use? Compile a custom version and include that in our projects, or is there something I've missed?

While an SDL2 port is very welcome, I can't help but think that your efforts would be better spent on porting it to libretro. R-type started porting it, but seems to have abandoned that project. The core works but sound is messed up.

There's also ongoing work to port FS-UAE to libretro. This core is already working very well, even on ARM/RPi3 (with accuracy=0).

The advantage of using libretro are many, but having audio/graphics/controls abstracted is quite awesome. Controllers can be hotplugged and detected by udev, and you get support for stuff like KMS/EGL and Vulkan for free. The RetroArch frontend also allows for enabling shaders, scraping games, displaying boxart and such.

I have no problem helping in that project as well, but my first priority for now is to get this done as a standalone emulator.
We have several distros that are making use of it, besides libretro...

I have the GUI part almost done (there's only one glitch I need to fix) but the emulator screen after that needs more work.
It shouldn't take too long to finish it, after which we can look into libretro as well.

[Haemogoblin]

Hi there

I've not updated the emulator since 0.4, because of the performance issues. How is the latest version fairing now? Any better?

[escalade]

I have no problem helping in that project as well, but my first priority for now is to get this done as a standalone emulator.
We have several distros that are making use of it, besides libretro...

I have the GUI part almost done (there's only one glitch I need to fix) but the emulator screen after that needs more work.
It shouldn't take too long to finish it, after which we can look into libretro as well.

May the gods grant you lots of spare time and motivation (moonstone music playing in the background)

[Chips]

Looks like someone just did a libretro uae4arm port:
https://github.com/repojohnray/libretro-uae4arm

[Methanoid]

Looks like someone just did a libretro uae4arm port:
https://github.com/repojohnray/libretro-uae4arm

So how many different ports is that now? Gonna get confusing....

[MiDWaN]

Looks like someone just did a libretro uae4arm port:
https://github.com/repojohnray/libretro-uae4arm

Nice!

The way I see it, the more people get involved the better. Eventually forks that don't continue to develop will die, but those that remain should give us a better product.

[yzi]

Has Chips's uae4arm-rpi worked perfectly for everyone else? I've been using it in a Raspi2 for about a year now, 720p50 video mode. In version 0.4, there was a small glitch with video sync - every 6 or 7 seconds, the emulator would "pause" for one frame, making a tiny little stop e.g. in scrollers, which was _very_ annoying. Audio was not interrupted. Now I updated to version 0.5, and the video is now competely continuous without the single-frame stops, but audio got broken - there were random silent pauses.

After toying around for awhile it seemed to me that the audio issue was somehow caused by the "audio producer" i.e. the emulator side which calls finish_sound_buffer() every now and then, and the "audio consumer" i.e. the SDL audio callback, both waiting for each other's semaphores with sem_wait(). How is that meant to work, if the emulator side sometimes has to wait for an audio callback? I was able to fix the audio issue by separating the audio producer and consumer, with these changes:
* Disable the semaphore syncing.
* Have the audio producer side use its own buffer size, and much smaller buffers. I used 32 buffers of 256 samples each, i.e. the same total size as originally, 8192 samples.
* Have the audio consumer (SDL audio callback) read stuff from the producer's filled buffers at its own pace to fill the SDL audio buffer, whatever its size is. I used 2048 samples SDL audio buffer size, i.e. the same length as originally.
* Theoretically, I guess the wrcnt variable (like any other data that's accessed by multiple threads) should be mutex-protected, but I didn't bother doing that yet. Maybe the wrcnt++ operation is atomic, or I'm just lucky.

This arrangement lets both sides operate at their own speed, allows for flexible adjusting of buffer sizes and latencies, and it enables many things to be done on the consumer side, if the emulator's and the audio output's positions drift apart. I made a very simple overflow/underflow fall-back mechanism on the consumer side (SDL audio callback), which would simply skip over or repeat (re-play) those small consumer buffers, but it didn't seem to be necessary after all, because the sync doesn't seem to drift too far away. The difference between the "write-head" and "read-head" positions fluctuates somewhat but doesn't really drift far away permanently. I don't know how the clock/time sources are really derived for the various parts of the system. I'm using HDMI video and audio, so perhaps the clocks derive from the same master source, but basically, for example if the sound goes to a separate external USB audio interface, it should be self-evident that the audio clock is bound to drift apart at some point.

I don't understand the software completely, but to me it feels that the program's use of multiple clocks is a bit questionable. There's "vsync" from the SDL video side, there's audio buffering from the SDL audio, and it even seems to read the system time for some timing-related things? The way I see it, in theory the master clock "pulse" for an emulated Amiga or any other emulated system, including emulated audio and all other parts, should be locked to the host machine's video output's vsync, to get smooth 50 fps motion with absolutely no stopped or skipped frames, ever. Assuming the video output is actually 50 fps. If you don't have that, then what kind of an Amiga is it anyway. Audio is more flexible, because it can be stretched without being noticeable, as long as there are no gaps of silence. (well, you could argue that Youtube is a proof that smooth motion doesn't matter)

Anyway. My hacking around was probably unnecessary, because I just didn't understand something, but now at least I can read scrollers without having suffer from the stop-frame hickups and with uninterrupted music. The next thing I'm trying to do is to hack the GLES version to be able to use some sort of a CRT-emulating fragment shader.

Thanks to Chips and other contributors for all the great work!

[MiDWaN]

I didn't experiment much with the audio yet, but on the SDL2 tests I've made so far, it seems to work better.
There are no buffer underruns mentioned (which happens whenever you switch resolution or quit the emulator currently) for example.

[yzi]

With my changes, I don't get buffer underruns either. With the original semaphore thing in place, there are occasional buffer underruns.

[MiDWaN]

With my changes, I don't get buffer underruns either. With the original semaphore thing in place, there are occasional buffer underruns.

Do you have your changes on some repository, so we can take a look?

[Vanfanel]

@yzi: Do you think you could port from SDL1 to SDL2?

[MiDWaN]

I'm in the process of doing that already, in my SDL2 branch.

[yzi]

No, I don't have the changes in any publicly available repo.

The changes I made were quite simple

* in sd-pandora/sound.h, change the number and size of buffers from
#define SOUND_BUFFERS_COUNT 4
#define SNDBUFFER_LEN 2048
to:
#define SOUND_BUFFERS_COUNT 32
#define SNDBUFFER_LEN 256

so now "SNDBUFFER_LEN" means SOUND PRODUCER i.e. emulator buffer length, and it is conceptually separated from physical audio output. The emulator just does not know or care about physical audio output. It does its own thing at its own pace and it's up to the physical audio output to follow and adjust itself as well as it can, in order to somehow try and represent what the emulator is producing.

* in sd-sdl/sound_sdl_new.cpp_
- remove "#define SOUND_USE_SEMAPHORES"
- add "#define CONSUMER_SNDBUFFER_LEN 2048"

* in sd-sdl/sound_sdl_new.cpp, in all SDL output handling, change "SNDBUFFER_LEN" to "CONSUMER_SNDBUFFER_LEN", meaning the physical SDL output buffer length (in samples)

* in sd-sdl/sound_sdl_new.cpp
- copy/paste the sound_thread_mixer() into a new "mix_block_from_producer_buffer_to_consumer_buffer()" routine
- have the real sound_thread_mixer() callback routine use the new mix_block_from_producer_buffer_to_consumer_buffer() routine in a while loop, so that it copies stuff from the small producer buffers (and advances "read position" of course) until the SDL output buffer is full

[MiDWaN]

Thanks for sharing, I'll give this approach a try.
Although it might not be necessary under SDL2, I'll have to check. I haven't made many tests with audio yet.

No, I don't have the changes in any publicly available repo.

The changes I made were quite simple

* in sd-pandora/sound.h, change the number and size of buffers from
#define SOUND_BUFFERS_COUNT 4
#define SNDBUFFER_LEN 2048
to:
#define SOUND_BUFFERS_COUNT 32
#define SNDBUFFER_LEN 256

so now "SNDBUFFER_LEN" means SOUND PRODUCER i.e. emulator buffer length, and it is conceptually separated from physical audio output. The emulator just does not know or care about physical audio output. It does its own thing at its own pace and it's up to the physical audio output to follow and adjust itself as well as it can, in order to somehow try and represent what the emulator is producing.

* in sd-sdl/sound_sdl_new.cpp_
- remove "#define SOUND_USE_SEMAPHORES"
- add "#define CONSUMER_SNDBUFFER_LEN 2048"

* in sd-sdl/sound_sdl_new.cpp, in all SDL output handling, change "SNDBUFFER_LEN" to "CONSUMER_SNDBUFFER_LEN", meaning the physical SDL output buffer length (in samples)

* in sd-sdl/sound_sdl_new.cpp
- copy/paste the sound_thread_mixer() into a new "mix_block_from_producer_buffer_to_consumer_buffer()" routine
- have the real sound_thread_mixer() callback routine use the new mix_block_from_producer_buffer_to_consumer_buffer() routine in a while loop, so that it copies stuff from the small producer buffers (and advances "read position" of course) until the SDL output buffer is full

[Vanfanel]

I'm in the process of doing that already, in my SDL2 branch.

Fantastic!

[Chips]

- remove "#define SOUND_USE_SEMAPHORES"

Did you check that it's not only this modification that remove the graphical glich appearing each couple of seconds ?
From my debugging, the core was generating more samples than what is expected. So the issue was more on emulation core side. Having more samples generated leads to de-synchronization hence the pause.
By removing semaphore, you're never have pause but instead you should have buffer overflow: the producer will overlap consumer buffer and audio glich should happens. So i feel like you move the consequence from video to audio side.

Note that buffer underruns message came from Alsa. So if you're using another audio layer than alsa (SDL1 use ALSA as audio sublayer by default) you don't see the message, it doesn't means there is no buffer underruns. For example If you switch to original sound.cpp with OSS emulation activated (so no alsa) you get ride of this message. But you don't solve anything

[Vanfanel]

- remove "#define SOUND_USE_SEMAPHORES"

Did you check that it's not only this modification that remove the graphical glich appearing each couple of seconds ?
From my debugging, the core was generating more samples than what is expected. So the issue was more on emulation core side. Having more samples generated leads to de-synchronization hence the pause.
By removing semaphore, you're never have pause but instead you should have buffer overflow: the producer will overlap consumer buffer and audio glich should happens. So i feel like you move the consequence from video to audio side.

Note that buffer underruns message came from Alsa. So if you're using another audio layer than alsa (SDL1 use ALSA as audio sublayer by default) you don't see the message, it doesn't means there is no buffer underruns. For example If you switch to original sound.cpp with OSS emulation activated (so no alsa) you get ride of this message. But you don't solve anything

In fact, this is why RetroArch uses resampling... There's no way around it. If you want perfec audio and video, without hiccups or audio glitches, resampling is a must.

[yzi]

- remove "#define SOUND_USE_SEMAPHORES"

Did you check that it's not only this modification that remove the graphical glich appearing each couple of seconds ?

No, I don't think I tested that in v 0.4. But updating to v 0.5 removed the _graphics_ glitches, even though the semaphore-locking thing was intact. But removing the semaphore-waits removed the audio glitches.

From my debugging, the core was generating more samples than what is expected. So the issue was more on emulation core side. Having more samples generated leads to de-synchronization hence the pause.

That's what I assumed as well, based on my hacking-around with the previous version. But the problem is, there seemed to be several "master clocks" and a complex network of "A waits on B" dependencies.

The semaphore thing looked like, in some circumstances, the emulator core (finish_sound_buffer() is run in and by the emulator core thread, right?) will have to _wait_ for audio output!? To me this seems like a broken idea. And consider that 2048 samples at 44100 Hz rate takes 46 milliseconds to play, which is longer than 2 full PAL 50 Hz frames.

By removing semaphore, you're never have pause but instead you should have buffer overflow: the producer will overlap consumer buffer and audio glich should happens.

Not exactly. No pauses, but no buffer overflows or underflows either. That's why my audio consumer is comparing the producer position vs. consumer position, and if the consumer is getting close to draining the ready-made producer buffers, it will re-play the latest producer buffer (256 samples per buffer). It is kind of like resampling, but with "grains" of 256 samples.

So i feel like you move the consequence from video to audio side.

Absolutely. That's what needs to be done. There can only be one master clock. HDMI audio+video out might be a special case, but generally speaking, the audio and video output devices have their own independent clocks. Inevitably at some point, the audio clock will have ticked a different number of audio samples clock ticks than what would theoretically be exact for the video clock.

I don't claim to understand too much about UAE or UAE4ARM or emulators, but to me the right way to split the responsibilities between the emulation core's "virtual world" and I/O interfacing to the host world is
* The emulator core runs in total virtual isolation, and it is essentially a "real-time video+audio movie producer". Its clocks are ticking virtual Amiga time, or whatever.
* Audio and video outputs do their best to try and play the "movie" produced by the core. It's some kind of an approximation anyway. Audio outputs have to be able to resample, video outputs will have to do impossible magic like show 50 fps stream on a 60 fps screen, etc.
* Because audio and video outputs (and inputs) can all have their own independent clocks, it must be decided what kind of a compromise we want to make. It is definitely impossible, in the general case, to have EVERYTHING perfectly synchronized at the same time. Only in the special case where multiple external host I/O devices happen to be in sync with each other because they are driven by a common master-clock, can you have all "sample-accurately" in sync and aligned. But even then, there is still only one master clock.
(* Not related to audio/video, but controller inputs and other I/O stuff like that has to be time-stamped and the timings translated to/from virtual time, through some sort of translator layer)

Raspi's HDMI output might be a special case. But anyway, the software has to adapt to whatever APIs we have, and if video goes out with, say, GLES/EGL, and audio goes out with, say, ALSA, then we have to assume that the things are not in sync.

Note that buffer underruns message came from Alsa. So if you're using another audio layer than alsa (SDL1 use ALSA as audio sublayer by default) you don't see the message, it doesn't means there is no buffer underruns.

I'm pretty sure that there are no audio buffer underruns with my current simple audio consumer code, because the audio callback handler _always_ fills the requested buffer _immediately_ without waiting for anything. The question is only, from where it copies the stuff. If the consumer thinks it's is getting behind too much, it will skip over buffers, discarding a producer buffer. If it's ahead, it will re-play a buffer, repeating a producer buffer. But in my experience, repeating or skipping happens very, very rarely. Only with some demo effects like some plasma-type things in Sanity's World of Commodore, the emulator is unable to produce stuff fast enough, and then the audio consumer will play things at half-speed. (Or maybe that's not the problem? I'm not sure why that happens, but the audio consumer just isn't getting stuff and has to slow down)

Anyway, I've been very happy with the simple 256-sample buffering thing.

I'm now trying to make a CRT filter fragment shader. To get shaders working, I had to hack the GLES code a bit towards GLES2. I got a simple "every second line is darker" thing working, though there is the problem that if the physical output is, say, 720p, then half of that is 360 lines and the Amiga screen should be aligned to that grid. But even without aligning it made everything look better.

I will upload these thingies somewhere at some point.

Thanks for your work and comments.

[deepx]

That CRT shader you are talking about, if it works, will that then be implemented in a new version of UAE4ARM??

[Chips]

That's what I assumed as well, based on my hacking-around with the previous version. But the problem is, there seemed to be several "master clocks" and a complex network of "A waits on B" dependencies.

The semaphore thing looked like, in some circumstances, the emulator core (finish_sound_buffer() is run in and by the emulator core thread, right?) will have to _wait_ for audio output!? To me this seems like a broken idea. And consider that 2048 samples at 44100 Hz rate takes 46 milliseconds to play, which is longer than 2 full PAL 50 Hz frames.

Despite having multiple clocked sub system could generate dis-synchronization, it should not be so much visible.
Note that in early version this audio dis-synchronization was not there (or at least not visible) despite semaphore where already used. So definitely we have something that could be improve on core side.

One way to confirm this could be to try other uae emulator. ex: fs-uae is available with gles and it even use semaphore for audio.