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

[SnakeCoils]

The new FS-UAE 2.5.7dev for OSX Tiger is available in The Zone!
This time I have done a more accurate work and now the external configuration files can be used as usual, no more need to inject a Config.fs-uae in the App bundle.
Al the other bugs are still present, but I am already happy with this result :-D
At present I have to set up a new 10.5 machine to compile the Leopard version, I will do it in the next few days.

[eastone]

Originally Posted by SnakeCoils

At present I have to set up a new 10.5 machine to compile the Leopard version, I will do it in the next few days.

I'm waiting

[SnakeCoils]

The Leopard PPC version of FS-UAE 2.5.7 is available in The Zone! for download.
Sorry for the delay, I have done a deep clean-up and reinstall of the whole 10.5.8 thing on my G4 MDD :-)

[SnakeCoils]

I have just made a rebuild of latest FS-UAE source with minor optimizations together with a "clean" compile of SDL 2.0.3 for OSX Leopard PPC that now is included in the executable bundle in the form of a system library instead of a binary extracted from the Framework.
I have also uploaded the CAPSimage plugin needed for loading the protected disk images (.ipf extension) in FS-UAE.
This plugin is the same released by Luigi (tlosm) some time ago but refactored in the new directory structure needed by actual FS-UAE.
I have tried to compile the CAPS library using the same parameters I use for FS-UAE but while the binary is generated without errors, it does not work with FS-UAE build while Luigi's one integrates perfectly.

A special note for all PowerMac MDD users: if you enable NAP mode on your machine you can get a boost in performance without loosing the sync between audio and video during the inevitable slowdowns.
This can be seen if you have declared the option

uae_cpu_speed = max

Without NAP mode enabled you will loose the sync (for example the audio goes on smoothly but graphics is choppy) while with NAP mode enabled both sound and graphics will go together in the good and in the bad time.
You can see this difference running, for example, the wonderful AGA demo Nexus 7 where without NAP it became quickly out of sync while with NAP enabled the production reaches the end perfectly (with some slowdowns of course but without loose the AV sync).
The following is the configuration I use for this demo:

[config]
amiga_model = A1200
uae_cpu_speed = max
fast_memory = 2048
accuracy = -1
floppy_drive_volume = 0
video_sync = off
fullscreen = 1
fullscreen_mode = fullscreen
keep_aspect = 1
viewport = * * * * => 0 0 752 574
floppy_drive_0 = Nexus 7.adf

The striped bouncing ball after the Nexus 7 logo is where the sync is at risk but with NAP enabled all goes smoothly and running well.

[Lord]

Hi, is there a Gui?

[SnakeCoils]

Originally Posted by Lord

Hi, is there a Gui?

The GUI for FS-UAE exist and is called FS-UAE Launcher but unfortunately it can't be built for OSX PPC since it rely on QT5 libraries that are not available for this platform.
There's a in-game minimal GUI activated by F12 key but it is mainly an extension of configuration file (handle disk-swapping, for example) rather a GUI as we are familiar with.

[SnakeCoils]

A new experimental build of current FS-UAE source snapshot compiled natively on OSX 10.4.11 for PowerMacs is available in The Zone!
This time I have installed a "clean" MacPorts SDL2 library (2.0.3) from the TigerPorts site and the resulting FS-UAE binary is quite stable and usable.

For those who want to try a build on Tiger, some modifications are needed to the FS-UAE source, as follow

In "Makefile.in" find and delete these lines (all the references to HIDmanager, used in 10.5 but not in 10.4):

manymouse/macosx_hidmanager.c

@BUILTIN_MANYMOUSE_TRUE@

manymouse/macosx_hidmanager.$(OBJEXT) \

manymouse/$(DEPDIR)/macosx_hidmanager.Po \

@BUILTIN_MANYMOUSE_TRUE@ manymouse/macosx_hidmanager.c \

manymouse/macosx_hidmanager.$(OBJEXT): manymouse/$(am__dirstamp) \
manymouse/$(DEPDIR)/$(am__dirstamp)

@AMDEP_TRUE@@am__include@ @am__quote@manymouse/$(DEPDIR)/macosx_hidmanager.Po@am__quote@ # am--include-marker

-rm -f manymouse/$(DEPDIR)/macosx_hidmanager.Po

manymouse/macosx_hidmanager.c

@BUILTIN_MANYMOUSE_TRUE@ manymouse/macosx_hidmanager.$(OBJEXT) \


In Makefile.am delete the line:

manymouse/macosx_hidmanager.c \


In dist/macos edit the file "info.plist.in" and replace the string "10.5.0" with "10.4.0"


For all the other modifications please refer to my previous post in this old thread.

For a boost in performance install on your PowerMac the CHUD Tools and enable the NAP mode, then declare in the various "fs-uae" config file the option "uae_cpu_speed=max".


Enjoy! :-)

[hth313]

I managed to get a couple of games I tried running in it, very useful! Thanks a lot!

[hth313]

Actually, I had a few setbacks on this G5 Leopard machine lately, it seems nothing these days likes it, but your stuff worked!

[SnakeCoils]

I am happy to know that someone find useful this port, it was made mainly for a proof of concept :-) Many thanks to Frode in made its code so portable to produce a binary also on OSX 10.4, and also many thanks to Kencu from TigerPorts in made a version of SDL 2.0.3 so "clean" to produce almost no side effects in the app under Tiger that use it. Now if only the same thing could be done also for (SDL)MAME it would be a real perfect world... :-(

[Methanoid]

Originally Posted by SnakeCoils

I am happy to know that someone find useful this port, it was made mainly for a proof of concept :-) Many thanks to Frode in made its code so portable to produce a binary also on OSX 10.4, and also many thanks to Kencu from TigerPorts in made a version of SDL 2.0.3 so "clean" to produce almost no side effects in the app under Tiger that use it. Now if only the same thing could be done also for (SDL)MAME it would be a real perfect world... :-(

I think there should be PPC ports anyway.... 10.4 and 10.5 .. When I plug my Mini in I think its on 10.5.8 :-(

[SnakeCoils]

I fully agree to give to the good old PowerMacs the chance to roar again, for relatively basic emulation the computation power (from 1Ghz up) is enough to provide a nice experience, without too much slowdowns.
There is a philosophic question here because while we all agree about the absolute need to preserve the historical home computer, consoles and arcade machines, we also must face that more deeper is the emulation (going, for example, from scanline to pixel level) then more CPU power is required, and simply our beloved growing old computers can't match the minimum to made a no-compromise experience. FS-UAE is not immune to this: the Desert Dream demo (one of the most famous Amiga demos) can run correctly only with "accuracy = 1" and on my double G4@1,5 GHz is tremendously choppy while on my 2011 MacMini runs smooth as silk.
In short, the "vintage guests on vintage hosts" path is going to be harder and harder to be usable, the only solution could be to provide specific hacks to obtain the same results with less power (this is what Snes9x do compared to Higan, for example, both SuperNintendo emulators) but this is a very hard effort for a developer, not really justified for a little niche of users.
If you look at the changelog of ANY emulator in still active development you will often see the phrase "removed hack for this", "removed hack for that" and so on, usually together to a minimum system requirement increase.
This is not a vexation from the developer to final users, it is simple a step towards a more perfect (and also easier to maintain) emulation, with some necessary sacrifice to do.
It is fun for me to see my G4 with Tiger still running most of the Amiga programs and demos (and also CD32 games, I often play the Pinball Dreams/Fantasies/Illusion series without a glitch) but for a really no-compromise Amiga experience the intel Macs are mandatory).
However I hope to can mantain a Tiger port as long this will be possible, please note I have abandoned the native port of FS-UAE for Leopard PPC (and I have no idea how the 10.4 version runs well on 10.5 since I have no more other PowerMac to experiment with) so if someone here is interested in take over the 10.5 PPC port is more than welcome :-)

[shaf]

hmm i may need to setup another hdd for Tiger since i just updated to Leopard. Although i'm not a programmer more of a Hardware guy i might take over the the Leopard updates but can only test in a powerMac 7.3 dual 2.0 Ghz G5 processors with 2.25GB RAM, AGP FX5200 Video.

[SnakeCoils]

The Leopard PPC version of FS-UAE 2.9.8dev is available in The Zone! for download.
I've not yet done an accurate testing but on my G4 MDD seems to work quite well :-)

[SnakeCoils]

Hello Frode, I was compiling (just for fun) this branch on a PowerPC Mac using latest GCC 7.4 when I encountered this error:

src/drawing.cpp: In function 'void pfield_doline64_1(uae_u64*, int, int)':
src/drawing.cpp:2515:3: error: 'do_put_mem_quad' was not declared in this scope
   do_put_mem_quad(pixels + 0, b0);
   ^~~~~~~~~~~~~~~
src/drawing.cpp:2515:3: note: suggested alternative: 'do_put_mem_word'
   do_put_mem_quad(pixels + 0, b0);
   ^~~~~~~~~~~~~~~
   do_put_mem_word
make[3]: *** [src/libuae_a-drawing.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [bundle] Error 2

Is there a compile fix or I simply must give up and stopping to insist to build emulators on obsolete machines? :-)

[FrodeSolheim]

You must implement do_put_mem_quad for PPC,
in src/od-fs/machdep/ppc/maccess.h, try adding:

STATIC_INLINE void do_put_mem_quad (uae_u64 *a, uae_u64 v)
{
    *a = v;
}

[SnakeCoils]

Thank you very much, the error above is gone! However I found another break in compiling:

src/main.cpp: In function 'void fixup_cpu(uae_prefs*)':
src/main.cpp:338:94: error: 'MIN_JIT_CACHE' was not declared in this scope
  if (p->cachesize < 0 || p->cachesize > MAX_JIT_CACHE || (p->cachesize > 0 && p->cachesize < MIN_JIT_CACHE)) {
                                                                                              ^~~~~~~~~~~~~
src/main.cpp:338:94: note: suggested alternative: 'MAX_JIT_CACHE'
  if (p->cachesize < 0 || p->cachesize > MAX_JIT_CACHE || (p->cachesize > 0 && p->cachesize < MIN_JIT_CACHE)) {
                                                                                              ^~~~~~~~~~~~~
                                                                                              MAX_JIT_CACHE
make[3]: *** [src/libuae_a-main.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [bundle] Error 2

and of course I declared before compiling:

./configure --disable-jit

[eastone]

Originally Posted by SnakeCoils

The Leopard PPC version of FS-UAE 2.9.8dev is available in The Zone! for download.

Welcome back SnakeCoils and thank you for the new version
This 2.9.8 is a bit faster than 2.9.7 and of course very stable on my G5 2.3

[FrodeSolheim]

Originally Posted by SnakeCoils

Thank you very much, the error above is gone! However I found another break in compiling:

I have pushed a fix for compilation without JIT

[SnakeCoils]

Excellent! I've just tried a fresh compile with the latest 4210 branch but it crash at this point:

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./manymouse -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/opt/local/include/SDL2 -I/opt/local/include  -fno-strict-overflow -fno-strict-aliasing -Wmissing-declarations -Waddress -fvisibility=hidden -I/opt/local/include/mpeg2dec -fpermissive -O3 -maltivec -mabi=altivec -MT src/libuae_a-x86.o -MD -MP -MF src/.deps/libuae_a-x86.Tpo -c -o src/libuae_a-x86.o `test -f 'src/x86.cpp' || echo './'`src/x86.cpp
In file included from src/x86.cpp:56:0:
src/pcem/codegen.h:12:2: error: #error Dynamic recompiler not implemented on your platform
 #error Dynamic recompiler not implemented on your platform
  ^~~~~
src/pcem/codegen.h: In function 'void addbyte(uint8_t)':
src/pcem/codegen.h:317:26: error: 'BLOCK_MAX' was not declared in this scope
         if (block_pos >= BLOCK_MAX)
                          ^~~~~~~~~
src/pcem/codegen.h:317:26: note: suggested alternative: 'LONG_MAX'
         if (block_pos >= BLOCK_MAX)
                          ^~~~~~~~~
                          LONG_MAX
src/pcem/codegen.h: In function 'void addword(uint16_t)':
src/pcem/codegen.h:327:26: error: 'BLOCK_MAX' was not declared in this scope
         if (block_pos >= BLOCK_MAX)
                          ^~~~~~~~~
src/pcem/codegen.h:327:26: note: suggested alternative: 'LONG_MAX'
         if (block_pos >= BLOCK_MAX)
                          ^~~~~~~~~
                          LONG_MAX
src/pcem/codegen.h: In function 'void addlong(uint32_t)':
src/pcem/codegen.h:337:26: error: 'BLOCK_MAX' was not declared in this scope
         if (block_pos >= BLOCK_MAX)
                          ^~~~~~~~~
src/pcem/codegen.h:337:26: note: suggested alternative: 'LONG_MAX'
         if (block_pos >= BLOCK_MAX)
                          ^~~~~~~~~
                          LONG_MAX
src/pcem/codegen.h: In function 'void addquad(uint64_t)':
src/pcem/codegen.h:347:26: error: 'BLOCK_MAX' was not declared in this scope
         if (block_pos >= BLOCK_MAX)
                          ^~~~~~~~~
src/pcem/codegen.h:347:26: note: suggested alternative: 'LONG_MAX'
         if (block_pos >= BLOCK_MAX)
                          ^~~~~~~~~
                          LONG_MAX

Before reaching this point I've seen some warnings here and there but the compile went fine. The argument "./configure --disable-jit" was declared as usual.