Problems trying to run self-built version

[vanfanel]

Hi,

I am trying to run a self-built version of the sdl2-dev branch, and all I get is that it returns to the system prompt (x-less system here, no X installed at all).
I have tried passing a basic Amiga 500 config file in text .conf format, where the kickstart file and path are specified (in fact it lives in the same directory where the emulator is).

./amiberry-sdl2-dev a500.conf

It keeps returnning to the commandline prompt. Seems to init and deinit SDL2, however, as I can see the SDL2 cursor briefly.
Any basic instructions would be good.

These are the contents of the a500.conf file:

button_for_quit=16
use_gui=no
use_debugger=false
show_leds=false
;bios
rom_path=/home/pi/amiga
kickstart_rom_file=kick.rom
;gfx
gfx_width=640
gfx_height=256
gfx_correct_aspect=true
gfx_center_horizontal=simple
gfx_center_vertical=simple
;sound
sound_output=exact
sound_bits=16
sound_channels=stereo
sound_stereo_separation=7
sound_stereo_mixing_delay=0
sound_frequency=44100
sound_interpol=none
sound_filter=off
sound_filter_type=standard
sound_volume=0
sound_auto=yes
cachesize=0
synchronize_clock=yes
rtg_nocustom=true
;paths
filesystem2=rw,DH0:DH0:/tmp/amiga/WHDL/,0
uaehf0=dir,rw,DH0:DH0:/tmp/amiga/WHDL/,0

kick.rom lives in /home/pi/amiga/kick.rom

Thanks!

[midwan]

Sounds like SDL2 can't initialize a screenmode?
Did you build SDL2 from source? Did you configure it to have the "rpi" driver included?

Another test would be if you could start a minimal SDL2 application in your system, to see if that initializes correctly or not. Something simple, like opening a screen and displaying a bitmap there for example, would be enough.

[vanfanel]

@midwan: all my SDL2 programs work fine (I am an SDL2 contributor myself, so that's not the problem at all).

[midwan]

@vanfanel could you try the current "dev" branch instead? I've merged dev-sdl1 and dev-sdl2 into one, and made several corrections afterwards...
You'll have to use platform "rpi3-sdl2" (check the Makefile) if you want to build the SDL2 version, but last I checked here, it worked. :)

[vanfanel]

@midwan I have just built the "dev" branch and it works! Well, I can see the GUI (nice font and cursor! yay!) but I have seen a big problem: if I save a configuration (a default Amiga500 configuration without changing ANYTHING) and then load it again, clicking "START" will make the emulator exit back to the commandline.
Directly hitting "START" without saving or loading configurations, with the default Amiga500 config, works well.

[midwan]

@vanfanel Yeah, there are some glitches left there after the merge and latest changes, which I'll be working on the next few days. Hopefully we'll sort them all out soon and get it back to working 100% :)

[vanfanel]

@midwan I have also seen some unnecessary libs being linked: -licui18n -licuuc -licudata...
I could remove them from the Makefile and the emulator still builds fine. I hope those don't become a new dependency, please...

I will be testing this "dev" branch in the next days: non-working config file loading is a bit of a show-stopper fir now, but as soon as that is working, it will be GREAT! 💃

[midwan]

@vanfanel Those will be removed, they were added with the latest updates but if they are not necessary, we will take them away.

[vanfanel]

That's very good to hear!
Also, optional CD32 building would be great: it would shave a lot of dependencies for "small" builds. These would become unnecessary if CD32 support is optional and is disabled:
-lFLAC -lmpg123 -ldl -lmpeg2convert -lmpeg2

Most CD32 stuff is already between #ifdefs already anyway (look for #ifdef CD32 in the code. It's all there. ) so it's a small task really.
Add a simple -DCD32 on the Makefile in case the user wants CD32, and those deps can go away, too!

[midwan]

@vanfanel interesting idea, I'll check it out in a few tests...

[solskogen]

Can you run amiberry without the configuration file? Does it start up?
I had that issue, and it was fixed when I switched off distcc. I used distcc to compile amiberry (I used a cross compiler on the other end) - and then the same thing happend to me.

[vanfanel]

@solskogen : It runs fine without a config file, I explained it already. According to @midwan , if I have understood him right, the dev branch is broken at the moment so loading a config file and then hitting "START" does not work. I am waiting for him to fix it to build again and test.

[solskogen]

Heh, sorry. Didn't read the whole thread.
Well, I'm having problems starting amiberry even without a config file. It segfaults at start up.

[midwan]

@vanfanel It currently doesn't crash, but I still must have something broken as at least in my tests, I only get a black screen after "start". I can return to the GUI normally, but can't see anything in the emulation screen.

I'll keep working on it until it's fixed of course... :)

[midwan]

@vanfanel hm, strange, I tested the same exact files on another fresh distro (Stretch Lite) and it works. :)
Which means there's something wrong in my main dev environment on Stretch full.

Please let me know if you find a problem as well!

[midwan]

@vanfanel The latest commit should have addressed these problems, please give it another try and let me know if you still have a problem!

[vanfanel]

@midwan : Yes! Latest git version on the dev branch allows to load configs and click START, good! :)
Passing a .uae config file also works great now!

Also, I have noticed there are problems with the sound: once on a while, there are "too long" samples (music gets out of rythm in games like Lemmings). I guess this is because the audio buffer is depleted.

I believe you are syncing emulation to video, which is a great idea because this way I see perfectly smooth scrolls, etc. But you need to resample the audio to compensate. (I am talking about an NTSC Amiga chipset on a 60HZ physical display, where the difference is minimal I guess)
For example, the Amiga may be outputting internally at ~59.9XXXX, but my monitor physical refresh rate is 60.017XXX in it's native video mode. So, if emulation is synced to video, some audio resampling is required to avoid occasional audio repeats/dropouts due to buffer problems. (Please don't synchronize to audio, it's OK to synchronize to video!)
Are you using resampling as RetroArch does to compensate between internal Amiga video refresh rate and physical refresh rate?
Maybe this is why porting to libretro would be so great, as it would solve the problem.

PD: The audio problems do not seem to happen if I run amiberry on an EXACT 50HZ physical video mode (CEA mode number 19, you can set it via tvservice) and I emulate a PAL chipset, because it's 50.0000 on both sides. But for NTSC, there's no exact equivalent between the NTSC chipset refresh rate and a physical video mode.

[midwan]

@vanfanel thanks for the details,
Porting to libretro is certainly in the plans, after fixing the most urgent bugs and preparing a new stable release. We can only do so much with the time we have... :)

In SDL1, we manually do vsync based on the information we get from the display. If there's a difference between the emulated chipset and the actual display (e.g. emulating a PAL Amiga on a 60Hz screen) then we adjust the drawn frames accordingly - but we don't do much for the audio, which is probably why you see the glitch.
In SDL2, we use the built-in Vsync mode currently so you'll have a different behavior.

Perhaps going to libretro would be the best approach to this, depending on the effort required to fix it.

[midwan]

@vanfanel
I've added a new (experimental for now) target, SDL2 with Dispmanx. This one uses the same logic of handling v-sync as the SDL1 version, uses the Dispmanx back-end to talk to the GPU directly (=faster) and at the same time, uses SDL2 for the GUI and handling everything else (events, audio, etc).

Could you give that a try and see if it's any better for you? Keep in mind that it's not fully polished yet, more work is needed on it and it hasn't been tested much (only tested under Raspbian Stretch, using the Legacy driver, launching it directly from the console for now).

[vanfanel]

@midwan : Just tried this with the dispmanx direct path.
There's a bit less CPU usage according to TOP, but the audio problems if I emulate an NTSC Amiga on a ~60Hz (60.0186 or so, really) video mode, the same audio problems are still present.
Please note that emulating a PAL Amiga on an EXACT 50.0000Hz mode there are no audio problems at all: the audio problems in NTSC Amiga on APPROXIMATELY 60Hz mode come from the video differences, you have to resample audio to avoid those. PLEASE DON'T sync on audio to hide the problem, that will break video smoothness.

Aside from that, I think a DispmanX backend is not a good idea anymore, use SDL2 instead since SDL2 runs on KMSDRM+GLES, which is the future in the Pi anyway. Dispmanx is a dead path too, and there are no real benefits.

[midwan]

@vanfanel
Thanks for the feedback.

Regarding Dispmanx, I realize that it's considered "deprecated" but it's still faster than using SDL2, even when it's using the "rpi" driver. The KMSDRM driver was consistently slower for me, and more buggy as well. Maybe it will eventually mature enough to change that, but for now it's just not fast enough when compared to using dispmanx...

[vanfanel]

@midwan : SDL2 supports KMSDRM and Dispmanx. In both cases, GLES is used for rendering.
I did part of the KMSDRM driver for SDL2 and it's well tested: SDL2 on KMSDRM it's not slower than SDL2 on Dispmanx. Are you sure of that part?
However, DIRECT Dispmanx (no SDL2) is a different story. That's a bit faster, but not much.

Anyway, SDL2 abstracts the underlying windowing API for you, and has good video synchronization on the Pi, so I wouldn't invest time in custom backends: SDL2 is alright. You use SDL2 and you know the emulator will run in everything that SDL2 runs on, no need to worry about dispmanx, kms...etc.
In the SDL1 days, which had very broken video support on the Pi, I did a dispmanx driver for SDL1 myself, and I ported many games to use dispmanx directly too, but I wouldn't do that anymore.

[solskogen]

With SDL2 (lastest from mercurial) compiled with kmsdrm and fkms, sysinfo tells me that the emulated machine is somewhat faster than with SDL1 and dispmanx. But the mouse is really sloppy and not as "slick" as with SDL1.

[vanfanel]

@solskogen : If you want a smooth cursor movement with SDL2, you need to set a PHYSICAL 50Hz video mode. I use mode CEA 19, and I set it with the tvservice command before executing amiberry.
That way, cursor movement (and in fact any movement) is as smooth as on a real Amiga. No hiccups. Ever.

[midwan]

@vanfanel I was referring to using Dispmanx directly, not through SDL2.
The speed difference I noticed was between using SDL2 with "rpi" (=dispmanx) and using Dispmanx directly to draw the emulation screen. I still use SDL2 for everything else (events, input, the GUI).

The KMSDRM option didn't seem any faster in my tests, and at the same time I had some glitches: mouse input seemed a bit buggy, the texture refresh didn't always clear the previous frame as it should, etc.

Perhaps I missed something in my environment? In that case, I'd love to give it another shot... Is there some documentation on how to "properly" set this up? What I did was download the latest SDL2 sources (2.0.7 currently), do a "configure" (does that pick up the kmsdrm option or do I need to enable it with a parameter?) and then "make" and "make install" like the README says...

@solskogen How did you test this? In my tests I run benchmarks (which give numbers so they are easy to compare) but also tested various demos and games, checking for framerate drop and choppy audio (if it starts to struggle, the audio will break up also). For example the "World of Commodore 92" demo has a section with zooming in/out effects, that always went under 50FPS in SDL2 with "rpi", but it managed to stay at 50 when using Dispmanx directly (in SDL1 and the new SDL2 target).

[midwan]

@vanfanel
After checking a bit more, it seems that I had missed a dependency: libgbm-dev was not installed, so the kmsdrm driver was not used in SDL2 in my tests.. Doh!
I will run another batch of tests with that, though I'm not sure if I have to disable the "rpi" driver to make also, after reading that they may have conflicts with each other?

Edit: It seems you have to disable the "rpi" driver otherwise it has higher priority, and it fails to initialize if you've switched to KMS.

I see that some of the glitches with the mouse are not there (they must have been related to the x11 driver then) and you can launch it from the console as well. The framerate is still lower, so I'll see if I can find the reason for that. It's reporting 33 fps on PAL and around 24-25 fps on P96 modes, instead of 50 and 60 respectively. That would be the reason you see a choppy mouse movement and benchmarks being faster (because you essentially have "frameskip"), but it will also show choppy audio/video if you try to run a demo.

[solskogen]

You can run like this: "SDL_VIDEODRIVER=kmsdrm ./amiberry"

…

On Sun, Dec 31, 2017 at 6:48 AM, Dimitris Panokostas < ***@***.***> wrote: @vanfanel <https://github.com/vanfanel> After checking a bit more, it seems that I had missed a dependency: libgbm-dev was not installed, so the kmsdrm driver was not used in SDL2 in my tests.. Doh! I will run another batch of tests with that, though I'm not sure if I have to disable the "rpi" driver to make also, after reading that they may have conflicts with each other? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#163 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-P6LwaduZQbDXeN92oJKBFJQQBAOTbks5tFyAbgaJpZM4Q38hx> .

[solskogen]

I only tested with sysinfo. On Sun, Dec 31, 2017 at 9:29 AM, Christer Solskogen < christer.solskogen@gmail.com> wrote:

…

You can run like this: "SDL_VIDEODRIVER=kmsdrm ./amiberry" On Sun, Dec 31, 2017 at 6:48 AM, Dimitris Panokostas < ***@***.***> wrote: > @vanfanel <https://github.com/vanfanel> > After checking a bit more, it seems that I had missed a dependency: > libgbm-dev was not installed, so the kmsdrm driver was not used in SDL2 in > my tests.. Doh! > I will run another batch of tests with that, though I'm not sure if I > have to disable the "rpi" driver to make also, after reading that they may > have conflicts with each other? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#163 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA-P6LwaduZQbDXeN92oJKBFJQQBAOTbks5tFyAbgaJpZM4Q38hx> > . >

[midwan]

@vanfanel I think it would be best to clean up this thread...

The main issue about not being able to compile/run the emulator is now fixed, so we should close that. There's a separate issue / suggestion to have CD32 support as an option in the Makefile, and one about the audio resampling for 60Hz. We should open those as separate issues to better monitor what's still open and what's done, and not get lost in big lists of discussions... :)

I'll close this one and open those 2, feel free to comment if you have any further observations!