08 April 2021, 20:53 | #381 | |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
Quote:
I've just checked, is there. This is the content of my /usr/local/include/SDL2/ directory Code:
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 |
|
08 April 2021, 21:09 | #382 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
Try to add -I/usr/local/include to CFLAGS
|
08 April 2021, 21:19 | #383 |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
Thanks Frode! The compiling went over that point but now is stuck here:
Code:
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 |
08 April 2021, 21:41 | #384 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
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).
|
08 April 2021, 22:16 | #385 |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
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... Code:
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 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 :-) Last edited by SnakeCoils; 09 April 2021 at 01:42. |
09 April 2021, 16:18 | #386 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
- 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... |
09 April 2021, 22:38 | #387 | |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
Quote:
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? |
|
09 April 2021, 22:55 | #388 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
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. |
09 April 2021, 23:12 | #389 |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
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?
|
09 April 2021, 23:20 | #390 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
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. |
09 April 2021, 23:22 | #391 |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
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! :-)
|
09 April 2021, 23:33 | #392 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
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:
Code:
static int fsemu_video_default_format(void) { #ifdef FSEMU_LINUX_ARM return FSEMU_VIDEO_FORMAT_RGB565; #else return FSEMU_VIDEO_FORMAT_BGRA; #endif } Code:
static int fsemu_video_default_format(void) { return FSEMU_VIDEO_FORMAT_RGB565; } |
10 April 2021, 14:49 | #393 |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
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. |
10 April 2021, 20:29 | #394 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
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.
|
12 April 2021, 21:11 | #395 |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
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! :-)
|
01 September 2021, 20:02 | #396 |
Registered User
Join Date: Mar 2014
Location: Italy
Posts: 164
|
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! :-) Last edited by SnakeCoils; 01 September 2021 at 22:39. |
12 September 2021, 10:04 | #397 |
Registered User
Join Date: Nov 2014
Location: Vaasa
Posts: 23
|
Welcome back @SnakeCoils
Thanks for this version. On my PM 11.2 I didn't notice any problems. |
12 September 2021, 11:29 | #398 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
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).
|
20 September 2021, 08:00 | #399 | |
Registered User
Join Date: May 2015
Location: Australia
Posts: 131
|
Quote:
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! |
|
20 September 2021, 08:11 | #400 | |
Registered User
Join Date: May 2015
Location: Australia
Posts: 131
|
Quote:
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 Last edited by Hypex; 20 September 2021 at 08:17. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FS-UAE for G4 ppc OSX 10.5.8 | elowan | support.FS-UAE | 35 | 10 November 2014 19:22 |
[QUESTION] Will we see PPC support in FS-UAE too? | amigafreak68k | support.FS-UAE | 39 | 09 September 2014 22:28 |
JIT on E-UAE PPC? | _ThEcRoW | support.OtherUAE | 8 | 06 May 2011 23:55 |
PPC Emulation in UAE | Beakster | support.WinUAE | 9 | 15 March 2008 11:28 |
PPC UAE on os 3.9 | DDNI | request.UAE Wishlist | 7 | 26 October 2006 19:09 |
|
|