
Although that's possible, I'd much rather see a version with support for AmigaLive instead: http://www.amigalive.com/neuro_999 wrote: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.
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 wrote:Although that's possible, I'd much rather see a version with support for AmigaLive instead: http://www.amigalive.com/neuro_999 wrote: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.
Why limit yourself to serial and not go all the way?
Well, it's nice to have a target to aim at...HoraceAndTheSpider wrote: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 wrote:Although that's possible, I'd much rather see a version with support for AmigaLive instead: http://www.amigalive.com/neuro_999 wrote: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.
Why limit yourself to serial and not go all the way?
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.MiDWaN wrote: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?
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.escalade wrote: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.MiDWaN wrote: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?
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.
May the gods grant you lots of spare time and motivation (moonstone music playing in the background)MiDWaN wrote: 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.
So how many different ports is that now? Gonna get confusing....Chips wrote:Looks like someone just did a libretro uae4arm port:
https://github.com/repojohnray/libretro-uae4arm
Nice!Chips wrote:Looks like someone just did a libretro uae4arm port:
https://github.com/repojohnray/libretro-uae4arm
Do you have your changes on some repository, so we can take a look?yzi wrote:With my changes, I don't get buffer underruns either. With the original semaphore thing in place, there are occasional buffer underruns.
yzi wrote: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
Fantastic!MiDWaN wrote:I'm in the process of doing that already, in my SDL2 branch.
Did you check that it's not only this modification that remove the graphical glich appearing each couple of seconds ?yzi wrote:- remove "#define SOUND_USE_SEMAPHORES"
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.Chips wrote:Did you check that it's not only this modification that remove the graphical glich appearing each couple of seconds ?yzi wrote:- remove "#define SOUND_USE_SEMAPHORES"
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
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.Chips wrote:Did you check that it's not only this modification that remove the graphical glich appearing each couple of seconds ?yzi wrote:- remove "#define SOUND_USE_SEMAPHORES"
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.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.
Not exactly. No pauses, but no buffer overflows or underflows either.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.
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.So i feel like you move the consequence from video to audio side.
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)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.
Despite having multiple clocked sub system could generate dis-synchronization, it should not be so much visible.yzi wrote: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.
Users browsing this forum: No registered users and 8 guests