Build Aranym for Raspberry Pi3

[Philippe Noble]

Hi,

I am trying to build the latest snapshot of Aranym for Raspberry Pi3, in order to use host exec NF.

Firstly the screen output under frame buffer generate a lot of garbage when you move an object with the mouse. I found the same issue when building aranym on X86.

With the exact same setup and image, and Aranym 1.02 Raspbian build it works perfectly.

The only solution I have found so far is to install X11 :-(

Secondly, at boot, phWeather complains that it doesn't find the codec. With the exact same setup and image, and Aranym 1.02 Raspbian build it works perfectly. LDG are still loaded and ZView doesn't complain. How come a new build can do this?

I am building aranym snapshot on a raspberry Pi3, with Minibian Jessie.

I have installed the following packages : 

libsdl1.2-dev 

libusb-1.0-0-dev 

sdl-image1.2-dev

libudev-dev

libjpeg-dev

git

make

autoconf

g++

I use ./configure —enable-jit-compiler , make and make install

All the compilation goes on well without error message.

Have I missed something ? What flags and packages are used to build Aranym 1.02 Raspbian?

Cheers,

Philippe

[Paul Wratt]

I have always used console (framebuffer) for Aranym, but I have not
tried a new build recently either. Are you building with SDL1.2 or
SDL2 - Are you using repo lib's or building you own (with DISPLAYMANX
support). Are you passing any "SDL=" options at runtime? On RPi these
can make a lot of difference in how stable SDL apps run (sound and
graphics).

I have always prefered the SDL1.2 builds, as they are more stable and
smaller, but I think SDL2 is now the default build and most popular
among x86 users (Linux & Windows).

On 8/26/18, Philippe Noble <philipp...@gmail.com> wrote:
> Hi,
>
> I am trying to build the latest snapshot of Aranym for Raspberry Pi3, in
> order to use host exec NF.
> Firstly the screen output under frame buffer generate a lot of garbage when
> you move an object with the mouse. I found the same issue when building
> aranym on X86.
> With the exact same setup and image, and Aranym 1.02 Raspbian build it works
> perfectly.
> The only solution I have found so far is to install X11 :-(
>
>

> Secondly, at boot, phWeather complains that it doesn't find the codec. With
> the exact same setup and image, and Aranym 1.02 Raspbian build it works
> perfectly. LDG are still loaded and ZView doesn't complain. How come a new
> build can do this?
>
> I am building aranym snapshot on a raspberry Pi3, with Minibian Jessie.
> I have installed the following packages :
> libsdl1.2-dev
> libusb-1.0-0-dev
> sdl-image1.2-dev
> libudev-dev
> libjpeg-dev
> git
> make
> autoconf
> g++
>
> I use ./configure —enable-jit-compiler , make and make install
> All the compilation goes on well without error message.
>
> Have I missed something ? What flags and packages are used to build Aranym
> 1.02 Raspbian?
>
> Cheers,
>
> Philippe
>
>
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "ARAnyM" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aranym+un...@googlegroups.com.
> To post to this group, send email to ara...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/aranym/E92568E2-3935-4F5E-9309-B04F3C9FA5B8%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Philippe noble]

> I have always used console (framebuffer) for Aranym, but I have not
> tried a new build recently either. Are you building with SDL1.2 or
> SDL2 -

Me too, at least so far.
I build it with SDL 1.2. I found SDL2 too slow on a Pi. The previous Aranym build was also build with SDL 1.2. I don’t know what has changed. Is it SDL 1.2 repo or Aranym last dev version that have an issue?

> Are you using repo lib's or building you own (with DISPLAYMANX
> support).

I use the Raspbian Jessie repository. I have exactly the same issue on X86 and Ubuntu repo by the way.
What is DISPLAYMANX support?
I have never tried to build SDL myself. It seems a bit overkill for my basic skills.

> Are you passing any "SDL=" options at runtime? On RPi these
> can make a lot of difference in how stable SDL apps run (sound and
> graphics).

No, I don’t use SDL options. What would be your suggestion?

> I have always prefered the SDL1.2 builds, as they are more stable and
> smaller, but I think SDL2 is now the default build and most popular
> among x86 users (Linux & Windows).

Yes, SDL2 works well on X86, but needs X11 as the repo version doesn’t support the framebuffer.

Aranym build with SDL1.2 and run under X11 doesn’t show the garbage on screen and works ok (except the issue I have with phweather), but as the memory on the Pi is limited, I would have preferred not to be obliged to use X11.
It looks like a regression to me.

[Ctirad Feřtr]

Hi,

Yes, SDL2 works  well on X86, but needs X11 as the repo version doesn’t support the framebuffer.

SDL2 does not need X11 on neither X86 nor PI, you can use accelerated OpenGL ES/Gles backed (caller "rpi" on pi) on the console.

Just make sure, that the SDL2 in your distribution is compiled with the Gles support enabled (the one in raspbian stretch is not).

I'm currently playing with it on RbPi Zero W, works as a charm, but I'm not able to compile current aranym git with the jit2 support.

The streatch version of aranym have jit2 enabled, but it is Sdl1.2 only. 

 

Ctirad

[Paul Wratt]

Is Stretch the new "stable". I still use Jessie "old-stable" (my
system files says 8.1 I think)

Both SDL are real easy to build, and dont take that long even on
armv6, but you must get ALL the sub-sub-libraries to get the most out
of SDL, especially Fonts (non-TTF) & Sound (MikMod)

I think last time I built it Freetype6 and MikMod were "fixed" for
"non-TTF fonts", and ALL Mod formats.

DISPLAYMANX is one of the SDL graphics driver options, but it has to
be build with the patches, it is a OpenGL ES/Gles backed using the
Mailbox. It is available in source form from the RetroPi build repo,
along with the build recipe (thats how I built it last time). There is
both SDL 1.2 and SDL2 recipes for armv6 & armv7. It was over a year
ago that I build it so it will probably has aarch64 by now as well.

You can not "browse" to find the recipes, you have to know what they
are called to get them, but you can start by looking at the RetroPi
development website and trace the urls from there.

If you need explicit details on that last paragraph, I can track down
the notes I made for getting recipes and patches from their server,
but it is on a different OS than this one, so it might take me a while
to find again (but ask if you need it).

DisplayManX is the original hardware accelerated 2D "driver" for
RaspberryPi, which they are hoping to replace with the Gallium
Hardware 3D driver when it is finished. I dont know if the 3D driver
is out of Beta yet, you will need to search their forum, I have not
checked in over 12 months. It did not support Sound last time I
checked (ie 3D but no sound over HDMI).

> --
> You received this message because you are subscribed to the Google Groups
> "ARAnyM" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aranym+un...@googlegroups.com.
> To post to this group, send email to ara...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/aranym/f42212d2-69cf-4a22-b867-392c254ddfd3%40googlegroups.com.

[Philippe Noble]

Hi Paul, Ctirad

I use Raspbian Stretch light ( yes this is the new stable) on a Pi 3.

I have installed these packages for the build environment of SDL2:

ibfontconfig-dev qt5-default automake mercurial libtool libfreeimage-dev libopenal-dev libpango1.0-dev libsndfile-dev libudev-dev libtiff5-dev libwebp-dev libasound2-dev libaudio-dev libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxss-dev libesd0-dev freeglut3-dev libmodplug-dev libsmpeg-dev

after ./autogen.sh, I used the following configuration :

../configure --host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl

Make and Make install didn't spit errors

I build also SDL2_image without issues

I build Aranym with ./configure —enable-fpe=uae —disable-nfclipbrd

Make and Make install didn't spit errors

I have activated GL (Full KMS) driver with raspi-config, but when I start aranym I got "SDL initialization failed"

So, it's not easy for me :-(

To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/CA%2BzYZ3-oj49tU6qzZYsktyDKiLv384rPyXae7H3T3QF7Lpx2AA%40mail.gmail.com.

[Ctirad Feřtr]

Hi, 

I use Raspbian Stretch light ( yes this is the new stable) on a Pi 3.

I have installed these packages for the build environment of SDL2:

ibfontconfig-dev qt5-default automake mercurial libtool libfreeimage-dev libopenal-dev libpango1.0-dev libsndfile-dev libudev-dev libtiff5-dev libwebp-dev libasound2-dev libaudio-dev libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxss-dev libesd0-dev freeglut3-dev libmodplug-dev libsmpeg-dev

If you want to build SDL2 as a Aranym backend only, you need only, there are a lot of uneeded dependencies like libopenal-dev, qt5-default, all the libx...., libesd0-dev, libmodplug-dev libsmpeg-dev and perhaps even couple of others.

after ./autogen.sh, I used the following configuration :

../configure --host=armv7l-raspberry-linux-gnueabihf --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl

Looks correct. 

You can also check the list at the end of the configure console output to be sure all needed SDL2 drivers are going to be built (the rbpi video driver has to be there)  

 

I build also SDL2_image without issues

And SDL2_Mixer, too? 

I build Aranym with ./configure —enable-fpe=uae —disable-nfclipbrd

That's about right. For a plain arm you shloud be able to compile even jit2 support, but the current aranym git just accept the parameter, however no jit enabled binary is compiled. 

Also, be sure you won't compile Aranym against SDL1.2 or distribuiton SDL2 dev libs!

I have activated GL (Full KMS) driver with raspi-config, but when I start aranym I got "SDL initialization failed"

Yes, this is a bit tricky, because on Rpi you have to keep the Leagacy setting here. The SDL2 rbpi/gles driver uses the default binary driver abi rather than the experimetnal opensource one.

Ctirad

[Paul Wratt]

Yes, I agree with Ctirad, use the 2D hardware driver, not the
experimental 3D driver

here is the RetroPie SDL 1.2 repo ("SDL 1 with rpi fixes / dispmanx"):
https://github.com/RetroPie/sdl1

here is the repo they use to build all SDL for all platforms (not just RPi):
(An unofficial, automated SDL2 and SDL1.2 HG mirror. )
https://github.com/RetroPie/SDL-mirror

I currently can not find my build info file.

Here is the SDL2 recipe:
https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/sdl2.sh

I think that the SDL-mirror mentioned above already has the RPi
patches applied to them, but dont quote me on that.

BTW exactly what version of SDL2 are you compiling (> 2.0.0.7)?

The SDL 1.2 build folder I have on this OS says 1.2.14 according to WhatsNew

Finally: You can specifiy on the command line the SDL graphics and
sound driver to use when running ARAnyM. For example I use the
following:
SDL_VIDEODRIVER=dispmanx SDL_AUDIODRIVER=alsa ./opentyrian

> --
> You received this message because you are subscribed to the Google Groups
> "ARAnyM" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aranym+un...@googlegroups.com.
> To post to this group, send email to ara...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/aranym/4437eed7-b07e-4ffe-8473-5e71394889e2%40googlegroups.com.

[Paul Wratt]

This appears to be the current SDL2 branch, it has "--disable-video-rpi" option:
https://github.com/RetroPie/SDL-mirror/tree/release-2.0.8

which implies it is enabled by default, and so has the patches already
applied. see here for RPI-2.0.6 and RPI-2.0.7:
https://github.com/RetroPie/SDL-mirror/branches/stale?page=2

[Paul Wratt]

oh, and they do use the KMS if it is install, but also build with
"dispmanx" driver as well, so you can choose at run time

[Ctirad Feřtr]

Just to be precise, the default legacy binary "blob" driver is also 3D (OpenGL ES). It is just not the standard Linux type one (KMS/DRM/OpenGL...) as the experimental one.

For a full screen accelerated appliaction without need of the full OpenGL, there is no reason to use experimental driver.

C.  

Dne pondělí 10. září 2018 11:27:42 UTC+2 Paul Wratt napsal(a):

[Philippe Noble]

You can also check the list at the end of the configure console output to be sure all needed SDL2 drivers are going to be built (the rbpi video driver has to be there)  

./configure --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-opengl --host=arm-raspberry-linux-gnueabihf

checking build system type... armv7l-unknown-linux-gnueabihf

checking host system type... arm-raspberry-linux-gnueabihf

checking how to print strings... printf

checking for arm-raspberry-linux-gnueabihf-gcc... no

checking for gcc... gcc

checking whether the C compiler works... yes

checking for C compiler default output file name... a.out

checking for suffix of executables... 

checking whether we are cross compiling... no

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking for gcc option to accept ISO C89... none needed

checking for a sed that does not truncate output... /bin/sed

checking for grep that handles long lines and -e... /bin/grep

checking for egrep... /bin/grep -E

checking for fgrep... /bin/grep -F

checking for ld used by gcc... /usr/bin/ld

checking if the linker (/usr/bin/ld) is GNU ld... yes

checking for BSD- or MS-compatible name lister (nm)... no

checking for arm-raspberry-linux-gnueabihf-dumpbin... no

checking for arm-raspberry-linux-gnueabihf-link... no

checking for dumpbin... no

checking for link... link -dump

checking the name lister (nm) interface... BSD nm

checking whether ln -s works... yes

checking the maximum length of command line arguments... 1572864

checking whether the shell understands some XSI constructs... yes

checking whether the shell understands "+="... yes

checking how to convert armv7l-unknown-linux-gnueabihf file names to arm-raspberry-linux-gnueabihf format... func_convert_file_noop

checking how to convert armv7l-unknown-linux-gnueabihf file names to toolchain format... func_convert_file_noop

checking for /usr/bin/ld option to reload object files... -r

checking for arm-raspberry-linux-gnueabihf-objdump... no

checking for objdump... objdump

checking how to recognize dependent libraries... pass_all

checking for arm-raspberry-linux-gnueabihf-dlltool... no

checking for dlltool... no

checking how to associate runtime and link libraries... printf %s\n

checking for arm-raspberry-linux-gnueabihf-ar... no

checking for ar... ar

checking for archiver @FILE support... @

checking for arm-raspberry-linux-gnueabihf-strip... no

checking for strip... strip

checking for arm-raspberry-linux-gnueabihf-ranlib... no

checking for ranlib... ranlib

checking for gawk... no

checking for mawk... mawk

checking command to parse nm output from gcc object... ok

checking for sysroot... no

checking for arm-raspberry-linux-gnueabihf-mt... no

checking for mt... mt

checking if mt is a manifest tool... no

checking how to run the C preprocessor... gcc -E

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... yes

checking for stdint.h... yes

checking for unistd.h... yes

checking for dlfcn.h... yes

checking for objdir... .libs

checking if gcc supports -fno-rtti -fno-exceptions... no

checking for gcc option to produce PIC... -fPIC -DPIC

checking if gcc PIC flag -fPIC -DPIC works... yes

checking if gcc static flag -static works... yes

checking if gcc supports -c -o file.o... yes

checking if gcc supports -c -o file.o... (cached) yes

checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes

checking whether -lc should be explicitly linked in... no

checking dynamic linker characteristics... GNU/Linux ld.so

checking how to hardcode library paths into programs... immediate

checking whether stripping libraries is possible... yes

checking if libtool supports shared libraries... yes

checking whether to build shared libraries... yes

checking whether to build static libraries... yes

checking for arm-raspberry-linux-gnueabihf-gcc... gcc

checking whether we are using the GNU C compiler... (cached) yes

checking whether gcc accepts -g... (cached) yes

checking for gcc option to accept ISO C89... (cached) none needed

checking for arm-raspberry-linux-gnueabihf-g++... no

checking for arm-raspberry-linux-gnueabihf-c++... no

checking for arm-raspberry-linux-gnueabihf-gpp... no

checking for arm-raspberry-linux-gnueabihf-aCC... no

checking for arm-raspberry-linux-gnueabihf-CC... no

checking for arm-raspberry-linux-gnueabihf-cxx... no

checking for arm-raspberry-linux-gnueabihf-cc++... no

checking for arm-raspberry-linux-gnueabihf-cl.exe... no

checking for arm-raspberry-linux-gnueabihf-FCC... no

checking for arm-raspberry-linux-gnueabihf-KCC... no

checking for arm-raspberry-linux-gnueabihf-RCC... no

checking for arm-raspberry-linux-gnueabihf-xlC_r... no

checking for arm-raspberry-linux-gnueabihf-xlC... no

checking for g++... g++

checking whether we are using the GNU C++ compiler... yes

checking whether g++ accepts -g... yes

checking how to run the C++ preprocessor... g++ -E

checking for ld used by g++... /usr/bin/ld

checking if the linker (/usr/bin/ld) is GNU ld... yes

checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes

checking for g++ option to produce PIC... -fPIC -DPIC

checking if g++ PIC flag -fPIC -DPIC works... yes

checking if g++ static flag -static works... yes

checking if g++ supports -c -o file.o... yes

checking if g++ supports -c -o file.o... (cached) yes

checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes

checking dynamic linker characteristics... (cached) GNU/Linux ld.so

checking how to hardcode library paths into programs... immediate

checking for a BSD-compatible install... /usr/bin/install -c

checking whether make sets $(MAKE)... yes

checking for arm-raspberry-linux-gnueabihf-windres... no

checking for windres... no

checking for an ANSI C-conforming const... yes

checking for inline... inline

checking for working volatile... yes

checking for GCC -MMD -MT option... yes

checking for linker option --no-undefined... yes

checking for ANSI C header files... (cached) yes

checking for sys/types.h... (cached) yes

checking stdio.h usability... yes

checking stdio.h presence... yes

checking for stdio.h... yes

checking for stdlib.h... (cached) yes

checking stddef.h usability... yes

checking stddef.h presence... yes

checking for stddef.h... yes

checking stdarg.h usability... yes

checking stdarg.h presence... yes

checking for stdarg.h... yes

checking malloc.h usability... yes

checking malloc.h presence... yes

checking for malloc.h... yes

checking for memory.h... (cached) yes

checking for string.h... (cached) yes

checking for strings.h... (cached) yes

checking wchar.h usability... yes

checking wchar.h presence... yes

checking for wchar.h... yes

checking for inttypes.h... (cached) yes

checking for stdint.h... (cached) yes

checking limits.h usability... yes

checking limits.h presence... yes

checking for limits.h... yes

checking ctype.h usability... yes

checking ctype.h presence... yes

checking for ctype.h... yes

checking math.h usability... yes

checking math.h presence... yes

checking for math.h... yes

checking float.h usability... yes

checking float.h presence... yes

checking for float.h... yes

checking iconv.h usability... yes

checking iconv.h presence... yes

checking for iconv.h... yes

checking signal.h usability... yes

checking signal.h presence... yes

checking for signal.h... yes

checking for size_t... yes

checking for M_PI in math.h... yes

checking for working alloca.h... yes

checking for alloca... yes

checking for working memcmp... yes

checking for working strtod... yes

checking for mprotect... yes

checking for malloc... yes

checking for calloc... yes

checking for realloc... yes

checking for free... yes

checking for getenv... yes

checking for setenv... yes

checking for putenv... yes

checking for unsetenv... yes

checking for qsort... yes

checking for abs... yes

checking for bcopy... yes

checking for memset... yes

checking for memcpy... yes

checking for memmove... yes

checking for wcslen... yes

checking for wcscmp... yes

checking for strlen... yes

checking for strlcpy... no

checking for strlcat... no

checking for _strrev... no

checking for _strupr... no

checking for _strlwr... no

checking for strchr... yes

checking for strrchr... yes

checking for strstr... yes

checking for itoa... no

checking for _ltoa... no

checking for _uitoa... no

checking for _ultoa... no

checking for strtol... yes

checking for strtoul... yes

checking for _i64toa... no

checking for _ui64toa... no

checking for strtoll... yes

checking for strtoull... yes

checking for atoi... yes

checking for atof... yes

checking for strcmp... yes

checking for strncmp... yes

checking for _stricmp... no

checking for strcasecmp... yes

checking for _strnicmp... no

checking for strncasecmp... yes

checking for vsscanf... yes

checking for vsnprintf... yes

checking for fopen64... yes

checking for fseeko... yes

checking for fseeko64... yes

checking for sigaction... yes

checking for setjmp... yes

checking for nanosleep... yes

checking for sysconf... yes

checking for sysctlbyname... no

checking for getauxval... yes

checking for poll... yes

checking for pow in -lm... yes

checking for acos... yes

checking for acosf... yes

checking for asin... yes

checking for asinf... yes

checking for atan... yes

checking for atanf... yes

checking for atan2... yes

checking for atan2f... yes

checking for ceil... yes

checking for ceilf... yes

checking for copysign... yes

checking for copysignf... yes

checking for cos... yes

checking for cosf... yes

checking for exp... yes

checking for expf... yes

checking for fabs... yes

checking for fabsf... yes

checking for floor... yes

checking for floorf... yes

checking for fmod... yes

checking for fmodf... yes

checking for log... yes

checking for logf... yes

checking for log10... yes

checking for log10f... yes

checking for pow... yes

checking for powf... yes

checking for scalbn... yes

checking for scalbnf... yes

checking for sin... yes

checking for sinf... yes

checking for sqrt... yes

checking for sqrtf... yes

checking for tan... yes

checking for tanf... yes

checking for iconv_open in -liconv... no

checking for iconv... yes

checking for struct sigaction.sa_sigaction... yes

checking libunwind.h usability... no

checking libunwind.h presence... no

checking for libunwind.h... no

checking for GCC builtin atomic operations... yes

checking for GCC -mmmx option... no

checking for GCC -m3dnow option... no

checking for GCC -msse option... no

checking immintrin.h usability... no

checking immintrin.h presence... no

checking for immintrin.h... no

checking for Altivec with GCC altivec.h and -maltivec option... no

checking for Altivec with GCC -maltivec option... no

checking for Altivec with GCC altivec.h and -faltivec option... no

checking for Altivec with GCC -faltivec option... no

checking for GCC -Wall option... yes

checking for necessary GCC -Wno-multichar option... no

checking for GCC -fvisibility=hidden option... yes

checking for GCC -Wdeclaration-after-statement option... yes

checking for dlopen... yes

checking for dlopen in -lc... no

checking for dlopen in -ldl... yes

checking for OSS audio support... yes

checking for ALSA CFLAGS... 

checking for ALSA LDFLAGS...  -lasound -lm -ldl -lpthread

checking for libasound headers version >= 1.0.11... found.

checking for snd_ctl_open in -lasound... yes

-- dynamic libasound -> libasound.so.2

checking for pkg-config... /usr/bin/pkg-config

checking for JACK 0.125 support... no

checking for artsc-config... no

checking audio/audiolib.h usability... yes

checking audio/audiolib.h presence... yes

checking for audio/audiolib.h... yes

checking for AuOpenServer in -laudio... yes

checking for NAS audio support... yes

-- dynamic libaudio -> libaudio.so.2

checking sndio.h usability... no

checking sndio.h presence... no

checking for sndio.h... no

checking for sio_open in -lsndio... no

checking for sndio audio support... no

checking samplerate.h usability... no

checking samplerate.h presence... no

checking for samplerate.h... no

checking for pkg-config... (cached) /usr/bin/pkg-config

checking for Raspberry Pi... yes

checking for X... libraries , headers 

checking for gethostbyname... yes

checking for connect... yes

checking for remove... yes

checking for shmat... yes

checking for IceConnectionNumber in -lICE... yes

checking for X11/extensions/Xext.h... yes

-- dynamic libX11 -> libX11.so.6

-- dynamic libX11ext -> libXext.so.6

checking for const parameter to XextAddDisplay... yes

checking for XGenericEvent... yes

checking for XkbKeycodeToKeysym in -lX11... yes

checking for X11/Xcursor/Xcursor.h... yes

-- dynamic libXcursor -> libXcursor.so.1

checking for X11/extensions/Xdbe.h... yes

checking for X11/extensions/Xinerama.h... yes

-- dynamic libXinerama -> libXinerama.so.1

checking for X11/extensions/XInput2.h... yes

-- dynamic libXi -> libXi.so.6

checking for xinput2 multitouch... yes

-- dynamic libXrandr -> libXrandr.so.2

checking for X11/extensions/scrnsaver.h... yes

-- dynamic libXss -> libXss.so.1

checking for X11/extensions/shape.h... yes

checking for X11/extensions/xf86vmode.h... yes

-- dynamic libXxf86vm -> libXxf86vm.so.1

checking for EGL support... yes

checking for OpenGL ES v1 headers... yes

checking for OpenGL ES v2 headers... yes

checking libudev.h usability... yes

checking libudev.h presence... yes

checking for libudev.h... yes

-- dynamic udev -> libudev.so.1

checking for pkg-config... (cached) /usr/bin/pkg-config

Package dbus-1 was not found in the pkg-config search path.

Perhaps you should add the directory containing `dbus-1.pc'

to the PKG_CONFIG_PATH environment variable

No package 'dbus-1' found

checking dbus/dbus.h usability... no

checking dbus/dbus.h presence... no

checking for dbus/dbus.h... no

checking for pkg-config... (cached) /usr/bin/pkg-config

Package ibus-1.0 was not found in the pkg-config search path.

Perhaps you should add the directory containing `ibus-1.0.pc'

to the PKG_CONFIG_PATH environment variable

No package 'ibus-1.0' found

checking ibus-1.0/ibus.h usability... no

checking ibus-1.0/ibus.h presence... no

checking for ibus-1.0/ibus.h... no

checking sys/inotify.h usability... yes

checking sys/inotify.h presence... yes

checking for sys/inotify.h... yes

checking for pkg-config... (cached) /usr/bin/pkg-config

Package fcitx was not found in the pkg-config search path.

Perhaps you should add the directory containing `fcitx.pc'

to the PKG_CONFIG_PATH environment variable

No package 'fcitx' found

checking fcitx/frontend.h usability... no

checking fcitx/frontend.h presence... no

checking for fcitx/frontend.h... no

checking for Linux 2.4 unified input interface... yes

checking for Linux kd.h... yes

checking for Touchscreen library support... no

checking for pthreads... yes

checking for recursive mutexes... yes

checking for pthread semaphores... yes

checking for sem_timedwait... yes

checking for pthread_np.h... no

checking for pthread_setname_np... yes

checking for pthread_set_name_np... no

checking for clock_gettime in -lrt... yes

checking linux/version.h usability... yes

checking linux/version.h presence... yes

checking for linux/version.h... yes

checking for Vivante VDK API... no

checking for Vivante FB API... no

checking for linker option --enable-new-dtags... yes

configure: creating ./config.status

config.status: creating Makefile

config.status: creating sdl2-config

config.status: creating sdl2-config.cmake

config.status: creating SDL2.spec

config.status: creating sdl2.pc

config.status: creating include/SDL_config.h

config.status: executing libtool commands

config.status: executing sdl2_config commands

config.status: executing summary commands

SDL2 Configure Summary:

Building Shared Libraries

Building Static Libraries

Enabled modules : atomic audio video render events joystick haptic sensor power filesystem threads timers file loadso cpuinfo assembly

Assembly Math   :

Audio drivers   : disk dummy oss alsa(dynamic) nas(dynamic)

Video drivers   : dummy rpi x11(dynamic) opengl_es1 opengl_es2 vulkan

X11 libraries   : xcursor xdbe xinerama xinput2 xinput2_multitouch xrandr xscrnsaver xshape xvidmode

Input drivers   : linuxev linuxkd

Using libsamplerate : NO

Using libudev       : YES

Using dbus          : NO

Using ime           : YES

Using ibus          : NO

Using fcitx         : NO

I build version 2.0.8 from libsdl.org : hg clone http://hg.libsdl.org/SDL

Make seems to work properly, the only strange message I got is : ar: `u' modifier ignored since `D' is the default (see `U')

I don't know if it's important

 

I build also SDL2_image without issues

And SDL2_Mixer, too? 

No I did't built it. I will. What other SDL2 lib are necessary to build for Aranym?

I build Aranym with ./configure —enable-fpe=uae —disable-nfclipbrd

That's about right. For a plain arm you shloud be able to compile even jit2 support, but the current aranym git just accept the parameter, however no jit enabled binary is compiled. 

Also, be sure you won't compile Aranym against SDL1.2 or distribuiton SDL2 dev libs!

There is no other SDL lib installed, nor 1.2, nor standard SDL2 devs. I use RaspBian Stretch light which is a pretty bare bone distrib

I have activated GL (Full KMS) driver with raspi-config, but when I start aranym I got "SDL initialization failed"

Yes, this is a bit tricky, because on Rpi you have to keep the Leagacy setting here. The SDL2 rbpi/gles driver uses the default binary driver abi rather than the experimetnal opensource one.

I don't understand what you mean. What do I have to declare for SDL_VIDEODRIVER and SDL_AUDIODRIVER ?

Sorry guys, but I don't have your level of expertise, all these things are new to me and I don't understand very well what you are trying to explain me.

Paul, I'll try to understand what you suggest me today and come back to you later.

Thanks a lot for your help.

[Philippe Noble]

I have tried to build SDL2 from : https://github.com/RetroPie/SDL-mirror/tree/release-2.0.8 with :

./configure --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-opengl --host=arm-raspberry-linux-gnueabihf

It gave me :

SDL2 Configure Summary:

Building Shared Libraries

Building Static Libraries

Enabled modules : atomic audio video render events joystick haptic power filesystem threads timers file loadso cpuinfo assembly

Assembly Math   :

Audio drivers   : disk dummy oss alsa(dynamic) nas(dynamic)

Video drivers   : dummy rpi x11(dynamic) opengl_es1 opengl_es2 vulkan

X11 libraries   : xcursor xdbe xinerama xinput2 xinput2_multitouch xrandr xscrnsaver xshape xvidmode

Input drivers   : linuxev linuxkd

Using libsamplerate : NO

Using libudev       : YES

Using dbus          : NO

Using ime           : YES

Using ibus          : NO

Using fcitx         : NO

I don't see the dispmanx video driver, and make gave me an error message, but it got build up to the end and installed properly.

 CC     build/SDL_test_common.lo

/home/pi/builds/SDL-mirror/src/test/SDL_test_common.c: In function 'SDLTest_CommonInit':

/home/pi/builds/SDL-mirror/src/test/SDL_test_common.c:942:38: warning: suggest parentheses around arithmetic in operand of '' [-Wparentheses]

             if ((state->window_flags & SDL_WINDOW_RESIZABLE|SDL_WINDOW_BORDERLESS) ==

                  ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

I configured aranym build with ./configure --enable-fpe=uae --disable-nfclipbrd

make gave me this message but build and got install properly.

AR       libaranym.a

ar: `u' modifier ignored since `D' is the default (see `U')

SDL_VIDEODRIVER=dispmanx SDL_AUDIODRIVER=alsa ./aranym gave me SDL initialization failed: dispmanx not available

SDL_VIDEODRIVER=rpi SDL_AUDIODRIVER=alsa ./aranym I got SDL initialization failed

I have tried with the other video drivers and SDL says they are not available.

So, let's try SDL1.2.15 from https://github.com/RetroPie/sdl1

I used : ./configure --disable-pulseaudio --disable-esd --disable-video-opengl --host=arm-raspberry-linux-gnueabihf

And got these error messages, but it got build up to the end and installed properly.

./src/video/x11/SDL_x11events.c: In function ‘X11_TranslateKeycode’:

./src/video/x11/SDL_x11events.c:1124:2: warning: ‘XKeycodeToKeysym’ is deprecated [-Wdeprecated-declarations]

  xsym = XKeycodeToKeysym(display, kc, 0);

  ^~~~

In file included from ./src/video/x11/SDL_x11events.c:27:0:

/usr/include/X11/Xlib.h:1687:15: note: declared here

 extern KeySym XKeycodeToKeysym(

               ^~~~~~~~~~~~~~~~

./src/video/x11/SDL_x11events.c: In function ‘get_modifier_masks’:

./src/video/x11/SDL_x11events.c:1216:4: warning: ‘XKeycodeToKeysym’ is deprecated [-Wdeprecated-declarations]

    KeySym ks = XKeycodeToKeysym(display, kc, 0);

    ^~~~~~

In file included from ./src/video/x11/SDL_x11events.c:27:0:

/usr/include/X11/Xlib.h:1687:15: note: declared here

 extern KeySym XKeycodeToKeysym(

I build Aranym with ./configure --enable-fpe=uae --disable-nfclipbrd --disable-sdl2

Got this message : 

AR       libaranym.a

ar: `u' modifier ignored since `D' is the default (see `U')

And … hurra … SDL_VIDEODRIVER=dispmanx SDL_AUDIODRIVER=alsa ./aranym started correctly !

But, I have the same redraw issue as described in my first post :-(

[Philippe Noble]

And … hurra … SDL_VIDEODRIVER=dispmanx SDL_AUDIODRIVER=alsa ./aranym started correctly !

But, I have the same redraw issue as described in my first post :-(

In the config file I have changed VDI from soft to opengl, and the garbage redraw disappeared.

I still can see a fast blinking square just below the mouse cursor when I move a window, but it's redrawn correctly and doesn't put garbage on the screen.

I never saw this in previous aranym version. What could it be?

[Philippe Noble]

This is the problem, but when I release the mouse button it is redrawn correctly.

[Philippe Noble]

I don't know why but the image attached in the previous message wasn't sent. So here is it.

Anyway, I did some further test, and back to square one.

- The garbage on the screen are still there with SDL1.2 and accelerated driver, but less frequent than with the default sdl1.2.

- I tried to build JIT version, and I still got the error message with PhWeather and Kronos. It seems that LDG doesn't work.

- I have not been successful in building SDL2 with hardware acceleration

- Latest aranym version seems to have serious bugs … or I have missed something.

[Vincent Rivière]

On 10/09/2018 à 21:56, Philippe Noble wrote:
> I never saw this in previous aranym version. What could it be?

I didn't follow closely your discussion, I have just seen your screenshots.
Anyway.

Some fVDI drivers (i.e. mine ;-) ) have buggy mouse pointer support, and
such artifacts sometimes appear on the screen. However, I never saw such
artifacts with the ARAnyM accelerated driver.

I just want to warn you that when you see such artifacts, the bug doesn't
necessarily come from ARAnyM. It could come from the emulated OS. Or even a
combination of both.

--
Vincent Rivière

[Philippe Noble]

>> I never saw this in previous aranym version. What could it be?
>
> I didn't follow closely your discussion, I have just seen your screenshots. Anyway.
>
> Some fVDI drivers (i.e. mine ;-) ) have buggy mouse pointer support, and such artifacts sometimes appear on the screen. However, I never saw such artifacts with the ARAnyM accelerated driver.
>
> I just want to warn you that when you see such artifacts, the bug doesn't necessarily come from ARAnyM. It could come from the emulated OS. Or even a combination of both.

Thanks Vincent for pointing this out. I would have never thought about it. I am going to test with another version of fvdi.

[Ctirad Feřtr]

Dne pondělí 10. září 2018 14:34:15 UTC+2 philippe.noble napsal(a):

Audio drivers   : disk dummy oss alsa(dynamic) nas(dynamic)

Video drivers   : dummy rpi x11(dynamic) opengl_es1 opengl_es2 vulkan

X11 libraries   : xcursor xdbe xinerama xinput2 xinput2_multitouch xrandr xscrnsaver xshape xvidmode

Despite the unneeded X11 libs, vulkan, oss, etc. This build should work in console via rpi driver-

 

I build version 2.0.8 from libsdl.org : hg clone http://hg.libsdl.org/SDL

The 2.0.8 release works for me as well.

 

Make seems to work properly, the only strange message I got is : ar: `u' modifier ignored since `D' is the default (see `U')

I don't know if it's important

Same her, but the resulting library works for me, so it is probably harmless.

No I did't built it. I will. What other SDL2 lib are necessary to build for Aranym?

SDL2_Image and SDL2_Mixer should be enough 

I have activated GL (Full KMS) driver with raspi-config, but when I start aranym I got "SDL initialization failed"

Yes, this is a bit tricky, because on Rpi you have to keep the Leagacy setting here. The SDL2 rbpi/gles driver uses the default binary driver abi rather than the experimetnal opensource one.

I don't understand what you mean. What do I have to declare for SDL_VIDEODRIVER and SDL_AUDIODRIVER ?

No. I mean you have to start raspi-config and revert previously activated Full KMS mode (which enables experimental KMS/DRM GL opensource driver) back to the default Legacy driver that is used by the SDL2 rpi driver.

 

Sorry guys, but I don't have your level of expertise, all these things are new to me and I don't understand very well what you are trying to explain me.

That is fine. I'm glad I'm not alone that play with the Aranym on a small ARM machines. :)

Ctirad

[Thorsten Otto]

On Dienstag, 11. September 2018 00:24:12 CEST Vincent Rivière wrote:
> I just want to warn you that when you see such artifacts, the bug doesn't
> necessarily come from ARAnyM. It could come from the emulated OS. Or even a
> combination of both.

I think you are right, and it is some kind of bad interaction. The picture
reminds me of something that was reported when running the MacOS version of
Aranym on High Sierra (where the mouse-cursor actually sometimes leaves
artifacts behind), but the same version runs flawlessly on MacOS Sierra. IIRC
it had something to do with the fact that SDL 1.2 builds the surface for the
mouse cursor without an explicit alpha channel, and some drivers don't seem to
like that.

[Paul Wratt]

A note here: I was using the 1.0.2 armv7 build on RPi2 that was
available before alot of the new stuff got added, including the
default use of SDL2. I never had any artifact issues under console
(fullscreen) or X-Windows (windowed or fullscreen), and I hand built
the SDL builds on one system I used it on.

Is it possible that some SDL 1 & 2 fixes were introduced after that,
that now affect the RPi build.

Is anyone able to build armv6 or armv7 for non-RPi SBC to verify any
introduced bug in either ARAnyM or SDL1 or SDL2.

Philip, I would still build the RPi SDL2 from the 2.0.0.8-release
branch of the RetroPie SDL Mirror on GitHub. It is guaranteed to work
with "rpi" driver, but it also builds the "dispmanx" driver.

Also, Philip is there a branch or tag you can build of ARAnyM that is
not the latest, but after v1.0.2, preferably after Mikro's NF-HOST
additions? That might show when and where the artifact issue on RPi
started (there were some SDL changes for MAC/OSX at some point).

I also believe there is a "good" fvdi repo on the mint libs user at
GitHub (its the one pTOS is looking at atm).

Hope something here helps.

Cheers

Paul

> --
> You received this message because you are subscribed to the Google Groups
> "ARAnyM" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aranym+un...@googlegroups.com.
> To post to this group, send email to ara...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/aranym/1841773.h6AUK95kiM%40earendil.

[Philippe Noble]

Hi all,

Also, Philip is there a branch or tag you can build of ARAnyM that is
not the latest, but after v1.0.2, preferably after Mikro's NF-HOST
additions? That might show when and where the artifact issue on RPi
started (there were some SDL changes for MAC/OSX at some point).

Well, I have done some testing in a more structured way and crossed different parameters, one by one.

I have first started with repository SDL1.2. I will do later the same tests with SDL2 own builds.

In order to be able to reproduce these tests, I have used the following build environment :

System : BeePi-b9f based on MiniBian Jessie

http://www.philippeworld.net/ftp/Install/beepi-b9f.zip

Build environment : 

apt-get install build-essential autoconf git libsdl1.2-dev sdl-image1.2-dev libusb-1.0-0-dev libudev-dev

root@beepi:~/builds/aranym-1.0.2# dpkg -l | grep sdl

ii  libsdl-image1.2:armhf          1.2.12-5+deb8u1   armhf  Image loading library for Simple DirectMedia Layer 1.2, libraries

ii  libsdl-image1.2-dev:armhf   1.2.12-5+deb8u1   armhf  Image loading library for Simple DirectMedia Layer 1.2, development files

ii  libsdl1.2-dev                   1.2.15-10+rpi1   armhf  Simple DirectMedia Layer development files

ii  libsdl1.2debian:armhf          1.2.15-10+rpi1   armhf  Simple DirectMedia Layer

Versions tested :

- Build of Aranym 1.0.2 for ARM Raspbian, that I have called "Base" : https://sourceforge.net/projects/aranym/files/aranym/1.0.2/aranym_1.0.2-2.raspbian_armhf.deb/download

- Source of Aranym 1.0.2 from 17/10/2014, that I have called "Orig" : https://sourceforge.net/projects/aranym/files/aranym/1.0.2/aranym_1.0.2.orig.tar.gz/download

- Sources of Aranym 1.0.2 from 21/03/2016, that I have called "2016" (only source backup that I had kept)

- Sources of Aranym 1.0.2 from latest GIT, that I have called "GIT"

You can find in the text file bellow, the configuration used, messages from make and detailed results.

[Philippe Noble]

Garbage means that the mouse cursor leaves a trail on the screen Ok means that there is no mouse trail on the screen.

Error FPU is a message that gives Kronos : "error test time evalue fpu_float fonction". Test completes without more problem

Base and Orig source : everything works fine !

2016 version works the same in both IEEE and UAE FPU mode. UAE mode is just slower

2016 version non-JIT runs 50% slower than Base and Orig versions from 2014 (Assembly optimization?)

2016 version : phweather crashed, XaesSnapshot crashed Mint

GIT version : impossible to build with IEEE FPU

GIT UAE JIT : Kronos freeze and doesn't run, phweather can't find LDG codec

I also believe there is a "good" fvdi repo on the mint libs user at
GitHub (its the one pTOS is looking at atm).

I have done tests with fvdi version used in BeePi (0.968b3) and the one found in freemint builds for aranym

https://bintray.com/freemint/freemint/download_file?file_path=snapshots%2Faranym-1-19-809.zip

Version: SVN-20130124-patch-20170425-bin-aranym-20170429

Both gives the same screen garbage. Is there another version that I can test?

At that stage, it may be to early to conclude, so I will use hypothesis :

First hypothesis : something got wrong between the 27/10/2014 and 21/03/2016 ( SDL2 integration?)

Second hypothesis : optimization has been done for JIT to the detriment of non-JIT which has lost 50% speed. (Assembly optimization?)

Third hypothesis : EasyAraMint is totally screwed. I have faced the same frame buffer issue with aranym X86-64 builds for linux (automatic build), but not the crashes of Kronos, XaesSnapshot nor Phweather. Under X11, version with host_exec works perfectly. 

Vincent hypothesis that fvdi could be the culprit has not given any positive result, but I may not use the correct one. Where can I find it?

Last hypothesis : I have missed something and I am building it wrong and need some rest. ;-)

Philip, I would still build the RPi SDL2 from the 2.0.0.8-release
branch of the RetroPie SDL Mirror on GitHub. It is guaranteed to work
with "rpi" driver, but it also builds the "dispmanx" driver.

That will be my tomorrow task.

[Thorsten Otto]

On Freitag, 14. September 2018 22:23:30 CEST Philippe Noble wrote:
> Sources of Aranym 1.0.2 from 21/03/2016, that I have called "2016" (only
> source backup that I had kept)

You can easily recreate any version you want by just doing a "checkout
<commitname>" in your local repo. Just take care that this sometimes also
changes Makefile.am and/or configure.ac, and you may have to run autogen.sh
afterwards. Also if there are deleted/new/moved files, you may have to remove
the ".deps" directory(s) or make complains about the dependencies. When you
are done with the tests, do a "checkout master", that should take you back to
the last version.

If you have done local changes that are not commited, you can also try to do a
"git diff" > somefile, and undo those changes by "patch -p1 -R < somefile"
before doing the checkout, then try to patch in your changes again.

If you are sure that the problem is from some changes in Aranym, you can also
have a look at "git bisect", that can greatly simplify tracking down which
patch caused problems.

[Thorsten Otto]

On Freitag, 14. September 2018 22:23:30 CEST Philippe Noble wrote:

> 2016 version non-JIT runs 50% slower than Base and Orig versions from 2014
> (Assembly optimization?

Might be that it is not correctly detected. Different toolchains seem to give
different results there, and some fixes were done for the android builds,
could be that it broke other builds in that respect. I think the configuration
summary after running configure should give you a hint already. But 50% sounds
a bit much for only missing assembly optimizations. Is that the overall
performance, or just the result from running FPU tests in Khronos?

>GIT version : impossible to build with IEEE FPU

Maybe i can a look at it. I cannot test the result reliably, but i can compile
for arm.

There is also the option to build with MPFR, although that might be a bit
slower. The old UAE core should actually be obsolete, as it only uses 64bit
doubles, and cannot accurately emulate the m68k FPU.

> Where can I find it?

Maybe try the attached one. It was build from a version
that i still have to sync with Vincents repo, but IIRC he had some problems
with the one he build.

PS.: Damn, **cking google, cannot attach anything here. You can find it at
http://tho-otto.de/download/fvdi.tar.bz2

[Philippe Noble]

> Might be that it is not correctly detected. Different toolchains seem to give
> different results there, and some fixes were done for the android builds,
> could be that it broke other builds in that respect. I think the configuration
> summary after running configure should give you a hint already. But 50% sounds
> a bit much for only missing assembly optimizations. Is that the overall
> performance, or just the result from running FPU tests in Khronos?

In my previous post I attached a benchmark file, and the configure summary, but this is an extract :
TEST 1 : Build aranym std orig IEEE FPU with repo SDL1.2
./configure
ARAnyM configuration summary:
SDL version ................... ........ : 1.2.15
Use exclusive spcflags handling ........ : yes
Use JIT compiler ....................... : no
Use JIT compiler for FPU instructions .. : no
JIT debug mode ......................... : no
Floating-Point emulation core .......... : IEEE fpu core
Assembly optimizations ................. : ARM/generic w optimized flags
Addressing mode ........................ : direct
Full MMU support ....................... : no
Linux /dev/rtc source timer ............ : yes
Real STOP implementation ............... : yes
DSP 56001 support ...................... : yes
DSP 56001 disassembly support .......... : no
Debugger ............................... : no
Check memory ........................... : page
First 2kB of RAM Supervisor protected... : yes
FastRAM fixed size ..................... : no
Fixed position of VideoRAM ............. : no
Blitter memmove acceleration ........... : no
Blitter SDL blit acceleration .......... : no
Support for hostfs ..................... : yes
Support for ethernet ................... : yes
GUI .................................... : yes
OpenGL ................................. : yes
Linux-m68k loader ...................... : no
Zlib ................................... : not required
libusb-1.0.............................. : no
NatFeat CD-ROM driver .................. : linux,sdl
NatFeat PCI driver ..................... : no
NatFeat USB driver ..................... : no
NatFeat OSMesa driver .................. : no
NatFeat JPEG decoder ................... : yes
NatFeat Clipboard ...................... : yes
NatFeat VDI driver ..................... : yes
Exception per second limiter ........... : no
Linux/X86 h/w access for parallel port.. : no
Linux /dev/parport for parallel port.... : yes
Unix /dev/ttySn for serial port......... : yes
Use C++ exceptions for m68k exceptions.. : yes

TEST 5 : Build aranym std v 21-03-2016 (50% slower)
./configure --disable-sdl2
ARAnyM configuration summary:
SDL version ................... ........ : 1.2.15
Use exclusive spcflags handling ........ : yes
Use JIT compiler ....................... : no
Use JIT compiler for FPU instructions .. : no
JIT debug mode ......................... : no
Floating-Point emulation core .......... : IEEE fpu core
Assembly optimizations ................. : ARM/V6 architecture w optimized flags
Addressing mode ........................ : direct
Full MMU support ....................... : no
Linux /dev/rtc source timer ............ : yes
Real STOP implementation ............... : yes
DSP 56001 support ...................... : yes
DSP 56001 disassembly support .......... : no
Debugger ............................... : no
Check memory ........................... : page
First 2kB of RAM Supervisor protected... : yes
FastRAM fixed size ..................... : no
Fixed position of VideoRAM ............. : no
Blitter memmove acceleration ........... : no
Blitter SDL blit acceleration .......... : no
Support for hostfs ..................... : yes
Support for ethernet ................... : yes
GUI .................................... : yes
OpenGL ................................. : yes
Linux-m68k loader ...................... : no
Zlib ................................... : not required
libusb-1.0.............................. : no
NatFeat CD-ROM driver .................. : linux,sdl
NatFeat PCI driver ..................... : no
NatFeat USB driver ..................... : no
NatFeat OSMesa driver .................. : no
NatFeat JPEG decoder ................... : yes
NatFeat Clipboard ...................... : yes
NatFeat VDI driver ..................... : yes
NatFeat SCSI driver .................... : yes
Exception per second limiter ........... : no
Linux/X86 h/w access for parallel port.. : no
Linux /dev/parport for parallel port.... : yes
Unix /dev/ttySn for serial port......... : yes
Use C++ exceptions for m68k exceptions.. : yes

Basically the processor speed between TEST 1and TEST 5, goes from 14 to 7, FPU from 1237 to 690, Memory & video bus speed from 80 to 44, disk for 1129 to 607, OpenGL from 135 to 70
The assembly optimization changes from ARM generic to ARM v6. Should it be the culprit?

I have build commit d769d1e from 25/11/2014 with optimization for Android/arm which gives the same speed decrease. So the change is between 17/10/2014 and 25/11/2014 in term of speed. On the other hand, there is no screen garbage with this version, so I am going to have a look later for that.

> There is also the option to build with MPFR, although that might be a bit
> slower. The old UAE core should actually be obsolete, as it only uses 64bit
> doubles, and cannot accurately emulate the m68k FPU.

Ok I'll give a try with MPFR

> PS.: Damn, **cking google, cannot attach anything here. You can find it at
> http://tho-otto.de/download/fvdi.tar.bz2

thanks

[Thorsten Otto]

On Samstag, 15. September 2018 00:07:24 CEST Philippe Noble wrote:
> The assembly optimization changes from ARM generic to ARM v6. Should it be
> the culprit?

That would be a surprise. ARMV6 also does some V6 specific assembly
optimizations, so should actually be better. I get the feeling that it's just
the timing calculation in Khronos that gets wrong. Could you try some other
benchmark, and check the real time vs the reported time?
The only other reason i can think of: the compiler uses -march=armv6. IIRC pi3
is armv7.

>So the change is between 17/10/2014 and 25/11/2014 in term of speed.

That's already quite close. git bisect could help you to find out the actual
commit that caused the speed decrease.

[Philippe Noble]

>> The assembly optimization changes from ARM generic to ARM v6. Should it be
>> the culprit?
>
> That would be a surprise. ARMV6 also does some V6 specific assembly
> optimizations, so should actually be better. I get the feeling that it's just
> the timing calculation in Khronos that gets wrong. Could you try some other
> benchmark, and check the real time vs the reported time?
> The only other reason i can think of: the compiler uses -march=armv6. IIRC pi3
> is armv7.

So get prepared to be surprised ;-)
commit 7373ac9 from 1/11/2014 is good. It uses ARM/generic optimization. Kronos gives the same benchmark as base build from 17/10/2014
commit a030b4c from 1/11/2014 is bad. it uses ARM/V6 optimization. Kronos gives 1/2 speed, and phweather crash

To measure system speed with another way, I used :
time tar -zcvf test.tar.gz /folder/to/compress

Builds are aranym standard with a default ./configure.
commit 7373ac9 : 55.440 s
commit a030b4c : 100.980 s
so roughly the same ratio as with Kronos
My Raspberry Pi scaling governor is forced to full speed @1.2 Ghz in both case and there is no thermal throttling during the tests with a stable temperature of 43 degrees, and 47 degrees at full load, so it's not the Pi slowing done the proc by half.

>> So the change is between 17/10/2014 and 25/11/2014 in term of speed.
>
> That's already quite close. git bisect could help you to find out the actual
> commit that caused the speed decrease.

Thanks a lot for teaching me new stuffs. I will use it to find when the screen garbage issue is happening.

[Thorsten Otto]

On Samstag, 15. September 2018 13:10:16 CEST Philippe Noble wrote:
> So get prepared to be surprised

I still doubt that it is only because of -DARMV6_AESSEMBLY ;) the same line
from configure.ac also adds -march=armv6 and -marm to the compile flags, i
would bet that this is the actual culprit of the speed decrease. The define
might be the cause of the crash of phwheather maybe, should there somewhere be
bugs in the assembly code. The -marm switch was only needed for the JIT
version and has been moved there later, so that should not affect the normal
version. But that might depend upon what default target the toolchain was
configured for.

I'm not sure what environment Jens used at the time he worked on the code, i
guess it was some android device.

[Philippe Noble]

On the screen garbage front, I have tested the latest fvdi build you sent me : no improvement, same mouse trail garbage on screen when build with SDL1.2 and run from the console under frame buffer.

After 6 bisects I have found the first version showing this defect :

e4014d5514e1bb775749508fde412c06a2870112 is the first bad commit

commit e4014d5514e1bb775749508fde412c06a2870112

Author: Thorsten Otto <tho...@users.sourceforge.net>

Date:   Sun May 31 16:41:40 2015 +0200

    Inject loaded TOS instead of calling linea functions from aranym,

    making linea68000() obsolete

:100644 100644 305c24f8c0e375c6fbb565e5e3f8e4bfe17d4f02 27d8150f80296a717a21b22cefee35a73b95f937 M ChangeLog

:040000 040000 b783e162bf29e19ebac1f5307cfc23d0be03a107 26d91acb38a945d6754a6fc93f3ad675a7499b28 M src

I have also build this commit for X86-64 and got the same mouse trail garbage on screen with SDL1.2 and run from the console under frame buffer, both for non JIT and JIT builds.

This issue doesn't appear if aranym is run under X11

Regarding the slow down, it happens only on ARM builds, not on X86. 

Digging into the defects caused by the slow down version on ARM, I also noticed that VDI drawing is shifted to the left in windows and the size of windows bar elevator is totally screwed up (see picture attached, left border disappears and vertical elevator size should be 2/3 of the window)

This happens in different apps, like Atari Works, TosWin2 ….

So in summary :

commit 7373ac9 : works fine under SDL1.2 and frame buffer

commit a030b4c : Pi 3 build : slow down 50%, phweather crash, VDI drawing shifted to the left, elevator size wrong, but no mouse trail garbage.

commit 6d99e4f : Pi 3 build same as above. X86 build works fine

commit e4014d5 : mouse trail garbage both on Pi 3 and X86 builds.

Somebody nice should teach me how to cross compile on X86 for ARM. Building directly on the Pi 3 is so slow compared to a core i5 that I have now grey hairs after 20 builds ;-)

cheers,

Philippe

[Philippe Noble]

I have found another strange bug. Aniplayer is no longer showing video, just a grey screen. This issue appears also with commit e4014d5, but to the difference of the mouse trail it is not solved if Aranym runs under X11 instead of frame buffer.

So in summary :
commit 7373ac9 : works fine under SDL1.2 and frame buffer and X11 for both Pi and X86
commit a030b4c : Pi 3 build non JIT is 50% slower, phweather crash, VDI drawing shifted to the left, elevator size wrong, but no mouse trail garbage. In JIT. phweather can't find ldg codec. X86 builds work fine.
commit 6d99e4f : Pi 3 builds, same as above. X86 builds work fine
commit e4014d5 : Pi 3 builds, same as above. mouse trail garbage both on Pi 3 and X86 builds when run under frame buffer. No mouse trail garbage if run under X11.Aniplayer shows grey screen instead of video

Should I report these bugs on Aranym GitHub?

[Thorsten Otto]

On Montag, 17. September 2018 22:54:27 CEST Philippe Noble wrote:
> Should I report these bugs on Aranym GitHub?

You can do that if you want, so its easier to keep track of the issues.
However most of these seem to be RPi related, either caused by the arm code,
or the special SDL version, or the use of the framebuffer device, so i fear i
can't help much with these.

[Philippe Noble]

>> Should I report these bugs on Aranym GitHub?
>
> You can do that if you want, so its easier to keep track of the issues.
> However most of these seem to be RPi related, either caused by the arm code,
> or the special SDL version, or the use of the framebuffer device, so i fear i
> can't help much with these.

Ok, I will report it on GitHub.
I understand for the RPI related bugs which are very specific (slow down, JIT compiler and IEE FPU broken) but for the X86 related bugs nothing can be done?
Do you mean that I am the only one to have this issue?

Since commit e4014d5 , X86 linux builds no longer works with SDL 1.2 on frame buffer (repo version, not an exotic build) generating Mouse trail garbage. This bug is not present when running under X11. Do you mean that Aranym must be run exclusively under X11 and starting it from the console is deprecated since 2015?

Since commit e4014d5 Aniplayer no longer works for videos for X86 builds. This happens with both SDL1.2 and SDL2 ( SDL2.0.5 from Ubuntu 16.04 repo)
Also with SDL2, keyboard is no longer working, so useless.

I am not a developper, so excuse me if I sound lost and confused. I have tried to revert the defective commits as you suggest, but git said it's not possible.
So I am stuck on a dead end.

[Thorsten Otto]

On Dienstag, 18. September 2018 15:56:43 CEST Philippe Noble wrote:
> Do you mean that Aranym must be run exclusively under X11 and starting it
> from the console is deprecated since 2015?

Apparently yes. The fbcon device that is used for it, is not compiled in by
default, so you would have to compile it explicitly yourself. In SDL2.x, that
device isn't even supported anymore. Instead, DirectFB is used, but again,
that is not compiled in by default.

>Also with SDL2, keyboard is no longer working, so useless.

Hu? Is that a new bug?

>I am not a developper, so excuse me if I sound lost and confused.

For that you have already done quite some amount of work to help track down
the issues, so hopefully some day that will help to fix it. Just for now, i
can't track the arm related bugs down, but maybe someone else can help (wished
Jens could take a look at these, but haven't heard anything from him since a
long time). I will have a look at the others of course.

>but git said it's not possible.

That's unfortunately not unusual, if there had been later changes to the same
source. It only can revert changes that still exactly match, everything else
needs some manual work.

BTW i can't imagine that this elevator bug has something to do with SDL, as
long as it is drawn correctly. Its size purely depends on what the application
calculates, maybe with the AES applying some restrictions.

[Philippe Noble]

>> Also with SDL2, keyboard is no longer working, so useless.
>
> Hu? Is that a new bug?

I don't know, it's a problem that I found when building Aranym with SDL 2.0.5 on Ubuntu 16.04 X86. I have read on emustation forum that it could be a SDL 2.05 bug especially when you use xmodmap to remap the keyboard under X11, which is my case. But removing xmodmap hasn't solved the issue, so I'm cautious before calling that a bug.

>
> BTW i can't imagine that this elevator bug has something to do with SDL, as
> long as it is drawn correctly. Its size purely depends on what the application
> calculates, maybe with the AES applying some restrictions.

I don't thing neither that this bug is SDL related.
In fact, as I couldn't use git to revert the compile parameters automatically for the RPi, I have edited manually the configure.ac as it was in commit 7373ac9 (1 line to change)
I did it on the master commit and build Aranym non JIT on the RPi with the repo SDL 1.2 as previously. Speed was back to 100%, the VDI shifted to the left together with the elevator size were back to normal, and Phweather was no lo longer crashing. So it seems to be more compiler related. But with this manual patch Aranym JIT was still giving trouble and phweather still complaining that it wasn't finding the LDG codec. So I gave up.

[Thorsten Otto]

On Dienstag, 18. September 2018 20:21:39 CEST Philippe Noble wrote:
> In fact, as I couldn't use git to revert the compile parameters
> automatically for the RPi, I have edited manually the configure.ac as it
> was in commit 7373ac9 (1 line to change)

Maybe it is better not to do too much automatically there for ARM targets, and
let you specify any extra CPU parameters when calling configure, and also put
a message in the configuration summary which flags are actually used. That
should solve at least the cases where working, but bad optimizations are used.

>But with this manual patch Aranym JIT was still giving trouble

I think this was missing the -marm switch then. JIT only works with that,
because otherwise thumb instructions may be generated that cannot be handled
by the segfault handler.

[Paul Wratt]

> The assembly optimization changes from ARM generic to ARM v6. Should it be the culprit?

for RPi 3 yes. armv6 support THUMB (16bit ARM code), armv7 supports
that and THUMB2, armv8 (aarch64) does not support any THUMB, but just
armv7 (32bit ARM code)

BTW that told me the main reason for the change from generic ARM to
ARM v6, because there was no RPi 3 when it was done, and ARM v7
supports it.

> SDL2 2.0.5
You should be using SDL2 2.0.8 (or 2.0.0.8). When SDL2 was first
ported to RPi, there was even a problem with it in the Raspbian repo.
The same version has issues on other platforms as well. So always use
a PPA with the latest SDL2 from the Ubuntu PPA lists (Incl. Linux Mint
and other Ubuntu derivitives)

> build options
the best per CPU build options (not just RPi) can be found here (lines
266 - 292):
https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/system.sh

I would use "-j4" instead, and most recommend "cores+1" (-j5), but at
least you still do something else with "-j4". There are some
"dispmanx" specific further up (lines 186 - 202) in the "function
get_rpi_video()"

I can help out with both these, but I will need to start a new OS on
the RPi to do it, to be able to use latest GCC builds etc.

It seems you have traced a few issues, just use the same strategy,
even though it takes a lot of time. If we can get this ironed out, I
will put together a build environment for RK3288 armv7 platforms that
have 2->4 Gb which speeds up RPi builds no end with GCC (like 15hrs
down to 15min for GGC building).

Thanks very very very much for isolating the commit issues. I can help
to test and supply the patch, but I just dont have the resources to be
able to track that stuff down myself. So again, Thanks Phillipe, a lot
of developers cant even do that much :)

Paul

[Philippe Noble]

>> SDL2 2.0.5
> You should be using SDL2 2.0.8 (or 2.0.0.8). When SDL2 was first
> ported to RPi, there was even a problem with it in the Raspbian repo.
> The same version has issues on other platforms as well. So always use
> a PPA with the latest SDL2 from the Ubuntu PPA lists (Incl. Linux Mint

> and other Ubuntu derivatives)

I have been able to build finally SDL1.2 with kms-vc4 and Dispmanx :-)
I used this source : https://github.com/vanfanel/SDL-1.2.15-raspberrypi
With this highly optimized fork, VDI is 50% faster, pretty impressive.

Also regarding SDL2, I have been able to build it correctly for the console and accelerated frame buffer driver. I found also packages from retropie already build : both work perfectly with Hatari under the console
https://files.retropie.org.uk/binaries/stretch/rpi3/libsdl2-dev_2.0.8+1rpi_armhf.deb

So where was my problem coming from?

First I didn't know that after building the library I had to set it up with ld config, secondly that by default the lib was installed in /usr/lib or /usr/local/lib, but aranym wants it in /usr/lib/arm-linux-gnueabihf, and thirdly that aranym commits updated for SDL2 were crashing all crashing during build due the FPU IEEE bug. I am still completing my training of young padawan ;-)

So now thanks to last commit, Aranym can be build with SDL2, but the other bugs remain … so to be continued until a full fix for ARM.

Regarding fvdi, I have found an annoying bug : circles are not longer drawn in Kandinsky, drawing just a diameter. It even crashes Kandinsky if you open a GEM file with circles.
This happens with the new v0.970beta3 supplied in this thread. Old v0.968beta3 doesn't exhibit this issue.
I don't know where I have to report it, but as Aranym and FVDI are pretty tight together, it may be of interest.