FS-UAE for OS X PPC (Not officially supported)

[SnakeCoils]

Originally Posted by FrodeSolheim

The warning is about missing header file, not library; do you have /usr/local/include/SDL2/SDL_ttf.h ?

Hello Frode,
I've just checked, is there. This is the content of my /usr/local/include/SDL2/ directory

SDL.h				SDL_egl.h			SDL_joystick.h			SDL_name.h			SDL_pixels.h			SDL_shape.h			SDL_test_crc32.h		SDL_timer.h
SDL_assert.h			SDL_endian.h			SDL_keyboard.h			SDL_opengl.h			SDL_platform.h			SDL_stdinc.h			SDL_test_font.h			SDL_touch.h
SDL_atomic.h			SDL_error.h			SDL_keycode.h			SDL_opengl_glext.h		SDL_power.h			SDL_surface.h			SDL_test_fuzzer.h		SDL_ttf.h
SDL_audio.h			SDL_events.h			SDL_loadso.h			SDL_opengles.h			SDL_quit.h			SDL_system.h			SDL_test_harness.h		SDL_types.h
SDL_bits.h			SDL_filesystem.h		SDL_log.h			SDL_opengles2.h			SDL_rect.h			SDL_syswm.h			SDL_test_images.h		SDL_version.h
SDL_blendmode.h			SDL_gamecontroller.h		SDL_main.h			SDL_opengles2_gl2.h		SDL_render.h			SDL_test.h			SDL_test_log.h			SDL_video.h
SDL_clipboard.h			SDL_gesture.h			SDL_messagebox.h		SDL_opengles2_gl2ext.h		SDL_revision.h			SDL_test_assert.h		SDL_test_md5.h			SDL_vulkan.h
SDL_config.h			SDL_haptic.h			SDL_mouse.h			SDL_opengles2_gl2platform.h	SDL_rwops.h			SDL_test_common.h		SDL_test_random.h		begin_code.h
SDL_cpuinfo.h			SDL_hints.h			SDL_mutex.h			SDL_opengles2_khrplatform.h	SDL_scancode.h			SDL_test_compare.h		SDL_thread.h			close_code.h

[FrodeSolheim]

Try to add -I/usr/local/include to CFLAGS

[SnakeCoils]

Thanks Frode! The compiling went over that point but now is stuck here:

	g++-mp-7 -DHAVE_CONFIG_H -I.  -DMACOSX -DMACOS -DUAE -DFSUAE    -I./flac/include -I./gen -I./src -I./src/jit -I./src/include -I./src/od-fs -I./src/od-fs/include -I./src/od-win32 -I./src/od-win32/caps -I./libfsemu/include -I./fsemu/src  -I./glad/include  -I./libudis86/include  -I./prowizard/include   -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -DLUA_USE_POSIX -I/opt/local/include/libpng16 -I/opt/local/include  -D_THREAD_SAFE -I/usr/local/include/SDL2 -D_HAVE_SDL_TTF -I/usr/local/include/SDL2 -I/opt/local/include  -fno-strict-overflow -fno-strict-aliasing  -Waddress -Werror=missing-declarations -Wpointer-arith -fvisibility=hidden -I/opt/local/include/mpeg2dec -O3 -maltivec -mabi=altivec -MT src/audio.o -MD -MP -MF $depbase.Tpo -c -o src/audio.o src/audio.cpp &&\
	mv -f $depbase.Tpo $depbase.Po
In file included from ./fsemu/src/fsemu-types.h:7:0,
                 from ./fsemu/src/fsemu-audiobuffer.h:6,
                 from ./src/od-fs/sounddep/sound.h:11,
                 from src/audio.cpp:25:
./fsemu/src/fsemu-sdl.h:20:10: fatal error: SDL2/SDL_ttf.h: No such file or directory
 #include <SDL2/SDL_ttf.h>
          ^~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [src/audio.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [bundle] Error 2

[FrodeSolheim]

It's basically the same problem, but for C++; add -I/usr/local/include to CXXFLAGS (if you added it to CFLAGS earlier. But I actually meant SDL2_CFLAGS which should be included for both C and C++ I believe).

[SnakeCoils]

Perfect! This is the updated list of declarations I now made before configure:

export SDL2_CFLAGS="-D_THREAD_SAFE -I/usr/local/include/SDL2"
export SDL2_LIBS="-L/usr/local/lib -lSDL2"
export SDL2_TTF_CFLAGS="-I/usr/local/include/SDL2"
export SDL2_TTF_LIBS="-L/usr/local/lib -lSDL2_ttf"
export CC="gcc-mp-7"
export CFLAGS="-O3 -maltivec -mabi=altivec -I/usr/local/include"
export CPP="gcc-mp-7 -E"
export CXX="g++-mp-7"
export CXXFLAGS="-O3 -maltivec -mabi=altivec -I/usr/local/include"

Everything went smooth until this...

	g++-mp-7 -DHAVE_CONFIG_H -I.  -DMACOSX -DMACOS -DUAE -DFSUAE    -I./flac/include -I./gen -I./src -I./src/jit -I./src/include -I./src/od-fs -I./src/od-fs/include -I./src/od-win32 -I./src/od-win32/caps -I./libfsemu/include -I./fsemu/src  -I./glad/include  -I./libudis86/include  -I./prowizard/include   -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -DLUA_USE_POSIX -I/opt/local/include/libpng16 -I/opt/local/include  -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/local/include/SDL2 -I/opt/local/include  -fno-strict-overflow -fno-strict-aliasing  -Waddress -Werror=missing-declarations -Wpointer-arith -fvisibility=hidden -I/opt/local/include/mpeg2dec -O3 -maltivec -mabi=altivec -I/usr/local/include -MT src/support/time.o -MD -MP -MF $depbase.Tpo -c -o src/support/time.o src/support/time.cpp &&\
	mv -f $depbase.Tpo $depbase.Po
src/support/time.cpp: In function 'int64_t uae_time_ns()':
src/support/time.cpp:27:16: error: 'CLOCK_MONOTONIC' was not declared in this scope
  clock_gettime(CLOCK_MONOTONIC, &ts);
                ^~~~~~~~~~~~~~~
src/support/time.cpp:27:2: error: 'clock_gettime' was not declared in this scope
  clock_gettime(CLOCK_MONOTONIC, &ts);
  ^~~~~~~~~~~~~
src/support/time.cpp:27:2: note: suggested alternative: 'localtime'
  clock_gettime(CLOCK_MONOTONIC, &ts);
  ^~~~~~~~~~~~~
  localtime
make[3]: *** [src/support/time.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [bundle] Error 2

I am on OSX 10.5.8 PowerPC and I use the GCC 7.5 so I think it could be a feature not supported for a such old operating system, is there a quick fix I can do to go further on build?

EDIT: Copying the time.cpp source from the 3.0.5 archive and disabling the SLIRP references I was able to make a working OSX PPC binary of the 4.0.19 development FS-UAE source.

Since it was not intended for running on anything below the OSX 10.9 it was at least nice to see it running on my G4 MDD but the performance and stability are not very good, the main issues are:

- Wrong colors, no matter about AGA, ECS or P96
- No CD audio
- Static noise instead of Amiga audio
- Terrible performances, a lot of frames skipped

The side LEDs on bezel are working good, Floppy and Hard drive activity, Power, they works as intended. The VSYNC Led instead is flashing wildly, no matter about the options I declare in the configuration file.

I am going to upload this binary in The Zone for everyone curious to see the result :-)

[FrodeSolheim]

- Wrong colors is almost guaranteed to be because of missing byteswapping for bigendian architecture.
- No CD audio - this is a TODO item for the code in the master branch
- Static noise - almost guaranteed to also be due to missing byte swapping for bigendian.
- Terrible performance - not sure, the performance even on Raspberry Pi 4 is quite good with this one...

[SnakeCoils]

Originally Posted by FrodeSolheim

- Wrong colors is almost guaranteed to be because of missing byteswapping for bigendian architecture.
- No CD audio - this is a TODO item for the code in the master branch
- Static noise - almost guaranteed to also be due to missing byte swapping for bigendian.
- Terrible performance - not sure, the performance even on Raspberry Pi 4 is quite good with this one...

The missing big endian support was something expected since I guess it is an unneeded complication in code maintenance, building the PPC executable was anyway funny and with my almost non-existant knowledge of C programming I did not expect to made it at all :-)
Anyway about the performances it is a real regression on my G4 compared to the 3.0.5 PPC build, if there is something I can try to improve the final executable I would be happy to experiment. Is it normal to have the VSYNC led on the left bezel side flashing continously?

[FrodeSolheim]

It's not complicated to fix the bigendian support; I did that previously for FS-UAE as you probably recall. I just might ignore it (when convenient) when experimenting with new code and wait until having a way to test it before bothering with it.

About performance, I think I quite recently removed some forced inlining because it didn't seem to have any effect on x86(64), and had negative effect on ARM. Maybe try compiling with an older commit in case that a big impact on PPC with older GCC?

Commit before that change: 1572da320030b5f762ee19a5db2b8cefbd74886c

(Alternatively, look in history for src/include/uae/inline.h and revert to the previos version of that file?)

As for the flashing VSYNC LED, that is intentional, whether it is a good idea or not remains to be seen, it can certainly be annoying ;-)

The reason it flashes is because if you actually have proper working VSYNC, the alternating red and green will appear to be solid yellow-ish. If v-sync is not stable, you will see flashes of red and/or green. So it works as an indicator of having stable v-sync.

[SnakeCoils]

Uhm, I remember a similar issue on E-UAE JIT based on the choice of using either the OpenGL or the SDL renderer... looking in the FS-UAE source it seems to be possible to choose between those two option too, how I can declare this intention before compiling?

[FrodeSolheim]

E-UAE was based on SDL 1.x, which has software rendering in addition to OpenGL support. SDL 2.x has a renderer system yes, but that's basically also implemented on top of OpenGL, so not at all the same as for SDL 1.x/E-UAE.

The choice of renderer will be runtime configurable, but right now you can change

fsemu_video_set_renderer(FSEMU_VIDEO_RENDERER_OPENGL);

to

fsemu_video_set_renderer(FSEMU_VIDEO_RENDERER_SDL);

in fsuae-main.c if you want to see if that helps with performance.

[SnakeCoils]

Thank you very much Frode, I am going to try it and I'll let you know the results as soon the compile will be succesful! :-)

[FrodeSolheim]

Another possible reason for slowdown is that the chosen OpenGL pixel format hits a slow (conversion) path in the OpenGL driver. Also, on this old system, using 16-bit color should be much faster, so if you locate this code:

static int fsemu_video_default_format(void)
{
#ifdef FSEMU_LINUX_ARM
    return FSEMU_VIDEO_FORMAT_RGB565;
#else
    return FSEMU_VIDEO_FORMAT_BGRA;
#endif
}

in fsemu-video.c, you can change this to always returning FSEMU_VIDEO_FORMAT_RGB565:

static int fsemu_video_default_format(void)
{
    return FSEMU_VIDEO_FORMAT_RGB565;
}

(PS: I would also consider checking out the inline tip I mentioned)

[SnakeCoils]

Unfortunately none of the above modifications had an effect on performances, I would like to try running it in fullscreen and without bezels but the previous option working in 3.0.5 is simply ignored. Looking in the debug log I found only the option

use_gui = yes/no

and it enable/disable the top gui menus but for the bezel I can't guess the right one.

[FrodeSolheim]

Right, the will be an option for that later. For now, go into fsemu-background.c and add an early return in fsemu_background_init, just like for FSEMU_LINUX_ARM.

[SnakeCoils]

This time I think I will wait for this option being implemented in source, I have made some compiling attempts but the bezel is still active. I am for sure missing something but if disabling the bezel will not translate in a performace increase on my PowerMac I think I will look forward for further development. Anyway thank you very much for your time Frode, I hope to will be be able in future to build more and more "unofficial" FS-UAE binaries! :-)

[SnakeCoils]

After a long time I have cleaned up some of my PPC machines and after a complete reinstall of OSX 10.5 on new G4 equipped with an HDD as boot disk I discovered A LOT of stuttering in audio and video in my FS-UAE builds (3.0.5) that were not present at all on the other G4 when booted from an SSD. After testing some of the usual demos/games/workbench I selected for this purpose I discovered that stuttering was due to a wild disk swapping the emulator is doing all the time! My regular G4 is equipped with an SSD since years and the disk access time is almost non existent therefore this FS-UAE behaviour was totally unnoticed but when running from an HDD this become really annoying. I found that declaring the "cachesize" parameter in the config file helped a lot and every stutter went away also when running from old disk drive (cachesize=8192) but I wonder why FS-UAE need to swap to disk also when a simple single ADF is completely loaded in memory like some demos that once loaded they do not acces disk anymore... is there a tweak for the source code to avoid at all this unnecessary swapping?

EDIT: Since I have just purchased for 20 euros a nice working iMac G5 20" iSight (2.1 GHz single core) I was curious to see how faster would run FS-UAE compiled and optimized for PPC970 processors and, guess what? The binary is now available in The Zone for download! Enjoy! :-)

[eastone]

Welcome back @SnakeCoils
Thanks for this version. On my PM 11.2 I didn't notice any problems.

[FrodeSolheim]

Hmm, FS-UAE does not deliberately do any "disk swapping" operations. Also, the (uae_)cachesize parameter does not control disk caching, but the total memory available for the JIT compiler to stored compiled blocks. The JIT compiler is not available for PPC, so the cachesize parameter should not have any effect... Are you certain that this just seemed to help by accident? Maybe your computer was performing disk access (unrelated to FS-UAE) by chance when you were testing it (before you tried with the cachesize parameter).

[Hypex]

Originally Posted by FrodeSolheim

It's not complicated to fix the bigendian support; I did that previously for FS-UAE as you probably recall. I just might ignore it (when convenient) when experimenting with new code and wait until having a way to test it before bothering with it.

Given FS-UAE is running primarily on little endian, and emulating a big endian computer, I am surprised it could be ignored at all or even require little work. It doesn't make sense that it would be harder to get it working on native big endian than it is easily working on little endian. The world doesn't make sense!

[Hypex]

Originally Posted by SnakeCoils

After a long time I have cleaned up some of my PPC machines and after a complete reinstall of OSX 10.5 on new G4 equipped with an HDD as boot disk I discovered A LOT of stuttering in audio and video in my FS-UAE builds (3.0.5) that were not present at all on the other G4 when booted from an SSD.

Given you did a fresh install and if you are feeling keen provided you have the space you could try the OSX 10.6 PPC beta build which is slightly newer. :-D


https://www.macintoshrepository.org/...eopard-powerpc