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

[tlosm]

ok snake tomorrow i will do and share it
but this time will share the full altivec

[SnakeCoils]

Originally Posted by tlosm

ok snake tomorrow i will do and share it
but this time will share the full altivec

Thank you so much :-)
In the meantime I have tried all the steps and build variants you and Frode have talked about but almost with the same result: the emulation is still slower (if compared to 2.5.20dev) and the 16 an 32 bitplane graphics suffer of wrong colors in the first eight palette positions. This color issue has been constantly there after the switch from SDL to SDL2 in FS-UAE development, maybe is related only to my ATI X800XT board while on your Nvidia 7800GTX things are handled better.

[tlosm]

snake i had that problem too.
now everything is right i had been updated many libs with lastest versions on macosx
dowloaded the sources , compiled and intalled. from cairo, to libpng and so and so.. not macports versions.only qemu use the library from macports because i dint had the time for upgrade.
after work i will make the app. like you suggested before.
in fpu after making all the fs and qemu altivec quakewos switch from 9.5fps to 11.9fps and if you consider on my 604e 200mhz i had 14.5 fps it is really good... the qemu is really low in performace in fpu.
the integer are really really fast!

Edit: i fixed my message wrote frorm ipad before ... some words was missing and make my message really not understandable

[tlosm]

Here is guys Full Altivec Optimized an proper build.
Thank you snake . Let me know ... remember to disable the scsi luns on cyberstorm bios

https://www.dropbox.com/s/dt6ucn80rg...tivec.zip?dl=0

[SnakeCoils]

@tlosm
I am sorry to say that on 68k side I noticed no differences between your FS-UAE build and mine, the severe speed hit is the same, the wrong colours on 16 and 32 bpp Uaegfx screenmodes (Workbench 3.9 with Boing Ball 2) are still here, seems not a Macports library related issue but more likely a different way the ATI and nVidia drivers handle that screenmode, or could be also an endian issue: I have seen many times this situation on some SDLmame drivers, for example in Cool Riders the backgorund graphics is correct while the sprite characters have the color messed, the same was for King of Fighters 2003 before the great AWJ (one of the last MAME developer who care about PPC thing) fixed the NeoGeo driver. Or could be an SDL2 library only issue, at present the last supported version was the 2.0.1 (that has to be built as Universal and only under 10.6) while tha latest (and intel-only) is the 2.0.3 and for sure we, on ppc machines, are missing some bugfixes.
About the speed I have to face the reality that an accurate emulation requires an adequate CPU power, the G4 is going to meet no more the minimum system requirements, that at this point becomes a G5 machine.
There's a thing I noticed in the latest builds (after adoption of WinUAEb25+ engine): the speed hit is MUCH MORE noticeable on emulated AGA machines instead of OCS/ECS ones because on ECS the demos and games runs more or less the same as before but on AGA the speed drop is about of 50%, gfx scrolling and music are affected in a sensible way.
For now I will come back to 2.5.20dev, the latest version which my G4 can still deal with... :-(
Just for completeness and if you wish to make some comparison tests I have uploaded my 2.5.22dev OSX build in the Zone, this time I have also made a bit of optimization too, with the following argumets just before the ./configure command:

CFLAGS="-maltivec -mabi=altivec" CPPFLAGS="-maltivec -mabi=altivec"

I found on the net this is the usual syntax to make generic Altivec optimized binaries, it can be pushed forward declaring other parameters (for example to build exclusively for 7400 or 7450 CPU family) but it is over my knowledge, the actual results are already quite good and the binary portable.
Anyway thank you very very much for your efforts, if FS-UAE is the best Amiga emulator around is also because of enthusiast users like you :-)

[FrodeSolheim]

Originally Posted by SnakeCoils

the wrong colours on 16 and 32 bpp Uaegfx screenmodes (Workbench 3.9 with Boing Ball 2) are still here, seems not a Macports library related issue but more likely a different way the ATI and nVidia drivers handle that screenmode, or could be also an endian issue

It could be a pixel conversion bug in FS-UAE. It does not sound likely that it has anything to do with SDL/SDL2, as the uaegfx pixel data is converted - if necessary - into the format expected by the FS-UAE OpenGL code (where a possible big-endian issue could reside). If you want this checked out, please post screenshots clearly showing the problem, together wit fs-uae.log.txt and information about the uaegfx screen mode used.

Originally Posted by SnakeCoils

There's a thing I noticed in the latest builds (after adoption of WinUAEb25+ engine): the speed hit is MUCH MORE noticeable on emulated AGA machines

You could of course, if you have tracked down the WinUAE merge commit which introduces the slowdown, try to revert the change (you could possibly maintain a FS-UAE version without that change, if the changes are modest).

Originally Posted by SnakeCoils

this time I have also made a bit of optimization too, with the following argumets just before the ./configure command:

CFLAGS="-maltivec -mabi=altivec" CPPFLAGS="-maltivec -mabi=altivec"

This is not a good idea, overriding CFLAGS like this will disable optimizations -O2) for C modules. You should rather do something like this (provided that -maltivec -mabi=altivec are good options to use ):

CFLAGS="-g -O2 -maltivec -mabi=altivec" CXXFLAGS="-g -O2 -maltivec -mabi=altivec"

[tlosm]

@Snake sad about your situation
with last build i did i have on ppc emulation a really increasing of performance
from 9.5 fps to 11.5 ... 16 fps in full screen mode.
In 68k i have faster scrolling and lines writing compared than before. Probably the Altivec of G5 take more advantage from this optimization
compared the g4

The only way for increasing 68k performance is with jit ... other ways are not possible... One day Frode can merge the Almos jit

@Frode i did usually this
Add -faltivec -maltivec where the -g -02 are declared.
About the color bug you it is make by sdl in certain situation ..
For me no problem i assume ... i dont know :P

it was solved on Euae by this :

     /* The MacOS X port of SDL lies about it's default pixel format
      * for high-colour display. It's always R5G5B5. */

Here a code example :

#ifdef WORDS_BIGENDIAN
    if (fmt->BitsPerPixel == 24) {
 if (fmt->Rmask == 0x00FF0000 && fmt->Gmask == 0x0000FF00 && fmt->Bmask == 0x000000FF)
     return RGBFB_R8G8B8;
 if (fmt->Rmask == 0x000000FF && fmt->Gmask == 0x0000FF00 && fmt->Bmask == 0x00FF0000)
     return RGBFB_B8G8R8;
    } else if (fmt->BitsPerPixel == 32) {
 if (fmt->Rmask == 0xFF000000 && fmt->Gmask == 0x00FF0000 && fmt->Bmask == 0x0000FF00)
     return RGBFB_R8G8B8A8;
 if (fmt->Rmask == 0x00FF0000 && fmt->Gmask == 0x0000FF00 && fmt->Bmask == 0x000000FF)
     return RGBFB_A8R8G8B8;
 if (fmt->Bmask == 0x00FF0000 && fmt->Gmask == 0x0000FF00 && fmt->Rmask == 0x000000FF)
     return RGBFB_A8B8G8R8;
 if (fmt->Bmask == 0xFF000000 && fmt->Gmask == 0x00FF0000 && fmt->Rmask == 0x0000FF00)
     return RGBFB_B8G8R8A8;
    } else if (fmt->BitsPerPixel == 16) {
 if (get_sdlgfx_type () == SDLGFX_DRIVER_QUARTZ) {
     /* The MacOS X port of SDL lies about it's default pixel format
      * for high-colour display. It's always R5G5B5. */
     return RGBFB_R5G5B5;
 } else {
     if (fmt->Rmask == 0xf800 && fmt->Gmask == 0x07e0 && fmt->Bmask == 0x001f)
  return RGBFB_R5G6B5;
     if (fmt->Rmask == 0x7C00 && fmt->Gmask == 0x03e0 && fmt->Bmask == 0x001f)
  return RGBFB_R5G5B5;
 }
    } else if (fmt->BitsPerPixel == 15) {
 if (fmt->Rmask == 0x7C00 && fmt->Gmask == 0x03e0 && fmt->Bmask == 0x001f)
     return RGBFB_R5G5B5;
    }
#else
    if (fmt->BitsPerPixel == 24) {
 if (fmt->Rmask == 0x00FF0000 && fmt->Gmask == 0x0000FF00 && fmt->Bmask == 0x000000FF)
     return RGBFB_B8G8R8;
 if (fmt->Rmask == 0x000000FF && fmt->Gmask == 0x0000FF00 && fmt->Bmask == 0x00FF0000)
     return RGBFB_R8G8B8;
    } else if (fmt->BitsPerPixel == 32) {
 if (fmt->Rmask == 0xFF000000 && fmt->Gmask == 0x00FF0000 && fmt->Bmask == 0x0000FF00)
     return RGBFB_A8B8G8R8;
 if (fmt->Rmask == 0x00FF0000 && fmt->Gmask == 0x0000FF00 && fmt->Bmask == 0x000000FF)
     return RGBFB_B8G8R8A8;
 if (fmt->Bmask == 0x00FF0000 && fmt->Gmask == 0x0000FF00 && fmt->Rmask == 0x000000FF)
     return RGBFB_R8G8B8A8;
 if (fmt->Bmask == 0xFF000000 && fmt->Gmask == 0x00FF0000 && fmt->Rmask == 0x0000FF00)
     return RGBFB_A8R8G8B8;
    } else if (fmt->BitsPerPixel == 16) {
 if (fmt->Rmask == 0xf800 && fmt->Gmask == 0x07e0 && fmt->Bmask == 0x001f)
     return RGBFB_R5G6B5PC;
 if (fmt->Rmask == 0x7C00 && fmt->Gmask == 0x03e0 && fmt->Bmask == 0x001f)
     return RGBFB_R5G5B5PC;
    } else if (fmt->BitsPerPixel == 15) {
 if (fmt->Rmask == 0x7C00 && fmt->Gmask == 0x03e0 && fmt->Bmask == 0x001f)
     return RGBFB_R5G5B5PC;
    }
#endif

    return RGBFB_NONE;
}
#endif

[tlosm]

About OS4 on fs uae.
I cant in X86 or in PPC version go in the earlyboot of Os4 kickstart. (pushing the two mouse buttons)
another thing the keyboard pushing button look like make an hard reset and not a softreset.
On my A4000 if i reset from keyboard the Os4 return on Os4 kickstart and not on 3.1 ks

About make AmigaOs 4 run On ppc look like the only way is install on X86 and transfer the Hf on PPC machine.
but i have to find the solution make os4 loading ... kickstart run but after black screen

Frode pls if you will have 10 min to fix the lsi53c895a.cpp for make it work on BigEndian you will make all of us happy because without this
fix will be impossible install Os4.1 classic ...on a PPC machine

Thanks

Edit: after some modding of KickLayout and installing on X86 and transfering on G5

[SnakeCoils]

Okay, I have found the cause of the wrong colours in 16bpp and 32 bpp uaegfx screenmodes: the Picasso96 blitter setting is to blame.
If I set the tooltype of "uaegfx" icon in Devs/Monitors to "NoBlitter=YES" magically all the colours (at the next reboot) are in their right place.
The same setting can be done through the MUI preferences "PVS" in the Tooltype section.
I don't know if the blitter above is the Amiga one or referred to the virtual gfx board but disabling it fixed the problem.
In the meantime I have recompiled (again...) various FS-UAE sources and I can confirm the line drawing speedup in the AIBB Line benchmark thanks to the Altivec optimization but the general speed drop after the 2.5.20dev is still too much remarkable for my machine, so I decided to keep two FS-UAE versions, the stable 2.4.1 (that I have recompiled with optimizations and including the endian fix Frode did make some time ago for sampled audio) and the 2.5.20dev.
I will use the first for demos and games while the latest for WB applications and RTG.
I'm going to upload those latest build to the Zone.

@tlosm
I fully agree with you, the JIT cores from E-UAE JIT could help a lot from now on...

[tlosm]

@snake probably is the picassoIV video driver who dont make the glitches. On Os4.1 no problems too.

@frode.
I cant set the floppy_drive_volume = 0 .. i dont understand why it dont turn off or lower the volume.

[SnakeCoils]

Originally Posted by tlosm

@snake probably is the picassoIV video driver who dont make the glitches. On Os4.1 no problems too.

Yes, I just installed the Picasso IV flashrom v7.4 in the Kickstart folder then reinstalled the latest Picasso96 (v2.1e) enabling the Picasso IV as RTG card and putting away the ueagfx device from Devs/Monitors to Storage/Monitors (only "PAL" and "PicassoIV" devices active).
As results now all RTG screenmodes are correct at any bit depth (8/15/16/24) and I had some fun in recreate the display resolutions database through the Picasso96 Prefs panel :-)
However it would be nice to have the standard "uaegfx" fixed so one do not need to emulate other hardware other than the already good uaegfx RTG implementation.

Edit: the colour issue on high and true colour screenmodes is related to uaegfx blitter, not the Picasso96 driver. With all other emulated GPU cards (and their P96 Monitor driver) the screens are OK

[SnakeCoils]

Originally Posted by FrodeSolheim

It could be a pixel conversion bug in FS-UAE. It does not sound likely that it has anything to do with SDL/SDL2, as the uaegfx pixel data is converted - if necessary - into the format expected by the FS-UAE OpenGL code (where a possible big-endian issue could reside). If you want this checked out, please post screenshots clearly showing the problem, together wit fs-uae.log.txt and information about the uaegfx screen mode used.

I have taken some screenshots to better show the issue, all the following comes from the same FS-UAE configuration (uaegfx only).
The debug and log files comes from the worst case, 32bpp with GPU blitter enabled.

[tlosm]

It build perfect here OsX PPC host ...but i have to notice about 20% of lower performance compared the dev 22 .
I will check if it is because fs-uae or qemu-uae plugin and report.
I have to notice the Blizzard Scsi on 1200 dont suffer of the problem of cyberstormppc ...but the A1200 emulation with blizzardppc continue be sloooooow

[SnakeCoils]

Build of .23dev is OK also on my G4 MDD, it is slower as previous .21 and .22dev and the uaegfx 16-24bpp issue is still here (but using Picasso IV emulation works perfectly instead).
If some merging is planned between E-UAE JIT and FS-UAE I would reccomend to experiment with the stable 2.4.1 because is IMHO the best compromise until now for PPC hosts between accuracy and required computing power.

[tlosm]

Dont worry about Snake The one know what is doing
he use the same machine that you have there :P
and sent to Almos something too
PS: probably Frode know him

PS : happy new year
do you see the credit of the video ?
[ Show youtube player ]

[SnakeCoils]

Happy new year to you too and all the FS-UAE community :-) Let's hope for better times everywhere.
I've seen the video, very nice. Impressive the gain of speed in ADoom under AmigaOS 4.1, very very promising...

P.S.: Thanks for the credits at the end ;-)

[tlosm]

@snakecoils
the one yesterday make me build EuaeJit 1.0 on LinuxPPC and worked .
He is merging :-P
I had been buy a mini g4 1.5ghz for test there the KVM because on G5 there are many many psicological problems ...
Hope soon something great will born with FS UAE

Almos today release on MacOsX , Mos and AmigaOS

[SnakeCoils]

Originally Posted by tlosm

I had been buy a mini g4 1.5ghz for test there the KVM because on G5 there are many many psicological problems ...

I would avoid any G4 PowerMac without a Level 3 cache because the performance can be very poor, expecially for intensive applications like emulators. A better choice would be a tower in the range of Quicksilver / MDD, possibly with a good CPU (with L3 cache) upgrade. I also have a MacMini G4 but after some tests I have relegated it to audio streamer, however if your purpose is only to compile that machine is adequate.

P.S. I have done a quick test of the new E-UAE JIT, the CPU part is awesome, the chipset part needs some more tuning to be perfect, but the improvements are there, it is almost ready to challenge FS-UAE :-)

[tlosm]

hi snake thanks to kvm emulation will not a great problem on mini g4
in any way i buy it for kvm tests plus for morphos .

Hello everyone, I have been trying to to figure out for months on how to compile the latest dev version of FS-UAE for PPC MACs. Thanks to everyone in this forum thread, there is now hope! :-)

I just joined EAB for the first time and I tried to access "The Zone" but it seems I don't have the right privileges? How do I gain access to the FS-UAE Devs PPC MAC Binaries in the "zone"?

Thanks for your help!