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

[SnakeCoils]

Originally Posted by FrodeSolheim

But the OpenAL-related crash was real of course -Note that the MAX_BUFFERS change mentioned in my last post is included in 2.5.18dev.

Yes, I have tried your suggestion in rebuild the past 2.5.17dev with buffers reduced to 48 and I can confirm that didn't crashed as before but the performance issue was still there. So it seems that both issues (crash and slowdown) have been fixed, one was internal to FS-UAE source and related to OpenAL buffers and the other external and entirely related to SDL2 binary.

I could not be more happy to see FS-UAE running again in its full glory! :-)

[SnakeCoils]

Lately had enough spare time to do some tests with FS-UAE and I found that my previous SDL2 framework build was broken, there's nothing wrong with SDL 2.0.1 version, it works OK but it must be a Universal binary version, the PPC-only build has troubles and therefore will not be more used for FS-UAE compile from now on.
Additionally I have finally doing an installation of Workbench 3.1 from scratch both on FS-UAE and E-UAE JIT and I have done some comparisons between them launching benchmark and demos and things and evaluating.
The first important thing I have discovered is that FPU emulation on FS-UAE is broken in PPC build while it is OK on Intel build: when running AIBB version 6.5 if any FPU test is launched the emulated Amiga don't crash but the screen show garbage and the emulator becomes unstable.
This happens either with CP or 040 option active while if integer math routines are used all is working as expected: this issue is present configuring the virtual Amiga with FPU, no matter if the choosen co-processor is 68882 or 68040.
Under E-UAE JIT all the FPU tests were working well and quite fast: the red hystogram bar was always on the emulated Amiga, very very nice :-)

@tlosm: Could you please look if AIBB's FPU tests fails also on G5 machines?

[tlosm]

Snake i had been tested here everything is all right
note my configuration is Amiga4000/040 rtg
cpu option is set and no problems.
Note i have Amiga OS 3.9

In the 99% of the test aibb report the cpu is more faster than a 040@25mhz

[SnakeCoils]

Just to be sure we are talking about the same issue, do you have tested AIBB with the same settings marked in the red oval on the attached snapshot? Please do not be scared by the shown values: the snapshot was taken from my other computer, a MacPro 2009 running at 3.46 GHz :-)

[SnakeCoils]

Originally Posted by tlosm

Snake i had been tested here everything is all right
note my configuration is Amiga4000/040 rtg
cpu option is set and no problems.
Note i have Amiga OS 3.9

In the 99% of the test aibb report the cpu is more faster than a 040@25mhz

I have just made a fresh install of OS 3.9 including Boing Bag 1 & 2 on a FS-UAE configured as a standard A4000/040 and then installed the very latest unofficial Picasso96 version 2.1d. The Workbench screen has then been configured in uagfx:800x600 with 8 bit colour depth.
Things seems to be a bit better than before, the screen goes back to normal after the floating point test finished but the results are meaningless with values out of this world: it is like the FPU is ignored at all jumping straight to the end of test.
I need to try other programs that does an heavy use of floating point calculations, I remember VistaPro had also an FP version, I will dig in my disk stuff to see if I found it.

My PPC Machine: PowerMac G4 MDD 2x1.5Ghz / 2 Gb CL2 RAM / ATI Radeon X800XT / OSX 10.5.8 / MacPorts 2.3.1 installed

[FrodeSolheim]

SnakeCoils it is quite possible there's some assumptions about little-endian-ness in the FPU emulation. A little while ago, I switched over to WinUAE's FPU code (because of FPU changes in WinUAE, and I didn't want to risk errors by maintaining the older non-WinUAE FPU code without time to test thoroughly, etc).

I'm not saying there definitively is a big-endian incompatibility in the FPU code (I haven't checked), but I wouldn't be surprised if there were, because the WinUAE-specific FPU code is of course free to assume x86/x86-64...

[SnakeCoils]

Originally Posted by FrodeSolheim

A little while ago, I switched over to WinUAE's FPU code (because of FPU changes in WinUAE, and I didn't want to risk errors by maintaining the older non-WinUAE FPU code without time to test thoroughly, etc).

I have just verified some of the past FS-UAE releases: the change must be happened between the 2.5.1 and 2.5.11 version because until 2.5.1 the AIBB's floating point tests works well while in the 2.5.11 and following the issue comes out. The stable release 2.4.1 works well too.

[FrodeSolheim]

Sounds about right, I briefly checked the git logs and it looks like the floating point commits are included in 2.5.6dev, this is probably the first version with issues on PPC.

(On a side note, this is *probably not* something I'll fix myself, since I don't test/develop for PPC at all. Accepting good patches is of course fine).

[SnakeCoils]

Originally Posted by FrodeSolheim

(On a side note, this is *probably not* something I'll fix myself, since I don't test/develop for PPC at all. Accepting good patches is of course fine).

Maybe I am writing an heresy here but... could the various 680x0 engines used in MAME, maybe the most tested, debugged and stable in the world, be integrated in FS-UAE? They are from long time big-endian compliant and I know the MAME devs are doing their best to not break anything to preserve the PPC compatibility in the various release.
I think Mr. Wilen is more inclined to keep its engines since he had done an hard work to iron out every possible bug, implementing every unofficial opcode to have a perfect compatibility with all the nasty coded Amiga programs so it is possible that this migration will never officially occour on the WinUAE side...
At this point only the brave OSX PPC developers still around can help here, with a bit of luck the modifications to the FPU code would not be so deep but only a coder can tell it for sure.

[Toni Wilen]

MAME has incompatible license.

[tlosm]

yes with 040 sc math selected not crash , just the result exit in numbers and not in graphic mode (?) but i see one big difference compared with your screenshot i have the MMU on.

[themamboman]

Just to be clear, this emulation is for PPC Mac's and it includes recent QEMU PowerPC emulation (not native host PPC instruction handling)?

[FrodeSolheim]

@SnakeCoils it is not as much heresy as it is just a bad idea! Disregarding the license issue, this would just introduce dozen new big problems while trying to fix what is really just a tiny issue. -As in relatively easy to fix. The problem is simply that I do not do PPC (as in I don't develop/test for it). I normally write code that works on both big- and little-endian architectures, but I still just test on x86/x86-64.

So as I said, it's not really difficult to fix at all, but someone knowledgeable has to spend some time with it (and test it) on PPC. -And I simply have a long todo list already.

(Note: even if no-one steps up to take a look at it, that does not mean I will not review the FPU code at some point in the future. Also, if/when I add support for the softfloat library, the FPU emulation might start work fine again - in softfloat mode - albeit with a speed penalty).

Originally Posted by themamboman

Just to be clear, this emulation is for PPC Mac's and it includes recent QEMU PowerPC emulation (not native host PPC instruction handling)?

This is about running FS-UAE on PPC Mac's. There's no native PPC instruction handling.

[SnakeCoils]

@Frode The current FPU issue is not really a big problem, the most part of Amiga programs runs happily without having it 100% functional: I simply found it and reported looking also to suggest, as non-developer, some possible solutions, nothing more. I don't know much about licensing and code transplant, I'm sorry if sometimes my thoughts sounds a bit silly :-)
I agree that your agenda is busy enough and this is the reason some other PPC developer should come to give an hand in debugging this issue without distracting you from the main goal.
My purpose in this forum is to keep alive the attention about the status of OSX PPC porting of this wonderful emulator, apart that I have no coding skill to understand what happens in the source, I can't be helpful here...
I want to remark that I and the other (few) Mac user here all we are very grateful to you to still support this little community that becomes smaller and smaller on every day goes by.

@tlosm Attached you will find a snapshot from the latest FS-UAE running on my G4, this is what happens when math coprocessor routines are activated on floating point tests. About the MMU status I don't know why it is reported as OFF, the emulated environment should be now the same of your: OS 3.9, picasso96 RTG, default A4000/040 in FS-UAE configuration file...

[tlosm]

Use PVS of picasso to forge the MMU on .
About the screen shoot now it is exactly mine only cpu and fpu clock was reported as 205mhz, but we know are not real , no crash in any case from my side :P
about the fpu for check the performance use quake68k it is working on euae because almos fixit on fsuae it is crashing.

about macos ppc developer i think only tobias can help about merge the qemu ppc core and almos jit core in fsuae or you have to contact the guy who mede the diff patch for qemu 2.1 on mac ports.
probably in that patch you will find the solution for have qemu core running on fsuae ppc.

i can help asking in the macpowerpc community for help... will ask the sheepshaver 2014 too

[FrodeSolheim]

Originally Posted by SnakeCoils

My purpose in this forum is to keep alive the attention about the status of OSX PPC porting of this wonderful emulator, apart that I have no coding skill to understand what happens in the source, I can't be helpful here...

Tell you what, if you can deal with testing (perhaps even - if necessary - compile / find small floating foint test programs for AmigaOS) then I can at least fix the obvious endian issues (perhaps that is even sufficient). I hope you can compile from git... (https://github.com/FrodeSolheim/fs-uae, requires git, autoconf, automake).

Originally Posted by tlosm

i think only tobias can help about merge the qemu ppc core

Uhm, I'm not aware of any merging being necessary. The qemu-uae plugin / PPC support might work out of the box (needs to be compiled of course). As far as I know, no-one has tested whether it works or not. Of course, it will probably be unbearably slow, that's another matter

[tlosm]

hi frode,
i don't know probably on low end G4 will be pretty slow but if the Qemu core will work in another core and it is a qemu-user core i think will be pretty acceptable.
On my Quad G5 for example i have on qemu-system-i386 really good performance with Aros i can play fast sdl games and run there the psx emulation too . Plus i can boot pretty good the X 10.2 jaguar on ppc emulation side.
Im pretty sure on dual core PowerMacs G4-G5 the Fs uae emulation ppc will be really usable and enjoyable .

On my quad for example i have better performances compared with i5 2011 Mac mini ... but we know if not fsuae ppc all can be only suppositions

[SnakeCoils]

Of course I can compile from GIT archive, just done few minutes ago... :-)

[tlosm]

@Snake
probably only Tony can reply , when i start compiling Qemu on G5 i have to foce the configure with --cpu=PPC probably there are some include who are differ in qemu optimized for different host machine.
Im thinking when Tony was made the merge of the qemu core just take the part of source for x86 and not for PPC this why you are unable to compile the source with PPC emulation of fsuae

[SnakeCoils]

I also think that a well working qemu ppc engine integration (for PPC hosts) in FS-UAE will be successful done in the future but I also believe things must be build step by step consolidating the foundations as first. In the Amiga history the PPC accelerators are arrived as latest, so also in the emulation on Win/FS-UAE. The first Amiga CPU was a simple 68000, then 68020/030 and FPUs and the latest were 68060 and PPC603/604 and you can see that this has been also the evolution for this emulator.
At present I am not too much worried about being unable to compile FS-UAE with PPC engine active, the really important thing, a little miracle, is that I can compile and use it (with some easy tweaks) on my G4 :-)
I personally prefer Frode would focus his attention on the 68k/FPU thing first and then, later, when the big-endian issues will be resolved, to look also at PPC engine integration. I prefer to have a 68k-only emulator I can compile instead of something that is "almost there" but that does nothing useful because the binary can't be build.