WinUAE PPC thread

[JimDrew]

Originally Posted by themamboman

What was the version of mac OS supported by Fusion-PPC?

I don't recall... we tested whatever was running on the PowerMacs during the same time period.

[B14ck W01f]

I like what Toni initially said about PPC emulation, and I thought I'd share this with you.

PPC "Amigas" should have never existed. Amiga is dead and it should rest in peace (and kept as a nice hobby system like any other 80-90s computer) but no, it is kept in life support instead when its soul has been long gone/brain has been totally damaged and mutated (you can make your choice between brain/soul)

I share Toni's view, but how and why PPC emulation made its way into WinUAE (other than everybody wanted it) still amazes me.

[FOL]

Originally Posted by B14ck W01f

I like what Toni initially said about PPC emulation, and I thought I'd share this with you.



I share Toni's view, but how and why PPC emulation made its way into WinUAE (other than everybody wanted it) still amazes me.

Why?

So you would never buy an X360, PS3 or Wii? all the same thing with a mashed up version of linux as the OS.

[Toni Wilen]

I think this thread is again in danger of getting off topic. This is not topic about "why PPC/why not". Not in support.WinUAE!

[FOL]

Originally Posted by Toni Wilen

I think this thread is again in danger of getting off topic. This is not topic about "why PPC/why not". Not in support.WinUAE!

Sorry, noted.

[AMIGASYSTEM]

Originally Posted by B14ck W01f

WinUAE has a problem with my hardfile, which I already mentioned in that thread. I'm still waiting for a response.

- KS ROM v3.1 (A1200) rev 40.68 with Beta 14 does not see HardFile

- KS ROM v3.1 (A4000) rev 40.68 OK
- KS ROM v3.1 (A4000T) rev 40.70 OK

[Mequa]

Originally Posted by Toni Wilen

QEMU currently runs in separate thread even when m68k is stopped = io serialiation probably is big bottleneck when non-m68k OS is actually running.

I was wondering: why not include an option to force m68k and PPC emulation to always run on the same thread (not just when running non-m68k OS) to avoid such bottlenecking?
Using separate threads has both pros and cons, so in short, why not make multi-threaded emulation optional when emulating both m68k and PPC?

[Toni Wilen]

Originally Posted by AMIGASYSTEM

- KS ROM v3.1 (A1200) rev 40.68 with Beta 14 does not see HardFile

- KS ROM v3.1 (A4000) rev 40.68 OK
- KS ROM v3.1 (A4000T) rev 40.70 OK

A600/A1200 vs A4000 IDE hardware is different. KS ROM _must_ match hardware!

Originally Posted by Mequa

I was wondering: why not include an option to force m68k and PPC emulation to always run on the same thread

"Problem" is QEMU. Single JIT execution call should not take more than about 1/4 or so of single frame time or Amiga-side timing will get badly messed up. I don't know how (at least not yet) to guarantee QEMU JIT call returning quickly enough.

It is easy with non-JIT emulation, just emulate 10 or so instructions and then do Amiga side emulation and then 10 instructions again and so on..

[Toni Wilen]

Status report:

Inter-thread messaging bottle-neck is now mostly gone.
cybppc.device (CSPPC built-in SCSI) works under OS4
Media Toolbox works.
Installing works.
Installing still takes forever (about 1 hour). See below. (But as I mentioned previously, boot image fade is now really fast)

Need to be fixed before public version:

All timers seem to run really fast (20x+), key repeat is instant, floppy clicks really fast. Probably (and hopefully) explains remaining performance problems. (It is possible huge number of timer interrupts takes most of remaining CPU time..)

QEMU seems to have multiple timer emulation modes but they are all quite difficult to understand..

"Unfortunately" PPC CPU has built-in counter + interrupt when it underflows, count rate is bus clock / 4, apparently this counter is used for OS4 timer.device. Possibly detection of bus clock is also wrong.

[MickJT]

Thanks for the status update Toni.

[amigafreak68k]

+1

[Nickman1200]

Originally Posted by Toni Wilen

Status report:

Inter-thread messaging bottle-neck is now mostly gone.
cybppc.device (CSPPC built-in SCSI) works under OS4
Media Toolbox works.
Installing works.
Installing still takes forever (about 1 hour). See below. (But as I mentioned previously, boot image fade is now really fast)

Need to be fixed before public version:

All timers seem to run really fast (20x+), key repeat is instant, floppy clicks really fast. Probably (and hopefully) explains remaining performance problems. (It is possible huge number of timer interrupts takes most of remaining CPU time..)

QEMU seems to have multiple timer emulation modes but they are all quite difficult to understand..

"Unfortunately" PPC CPU has built-in counter + interrupt when it underflows, count rate is bus clock / 4, apparently this counter is used for OS4 timer.device. Possibly detection of bus clock is also wrong.

Thanks for the nice update. Will donate right now to get you through to the finish line

[Toni Wilen]

About "UAE" devices and directory filesystem running under OS4:

Even if OS4 supports them (it should, at least in theory) but there are two technical problems:

m68k to host switching is done using m68k TRAP instructions, when UAE m68k emulator notices trap instruction executed by UAE boot rom, it calls host side code and trap instruction is not emulated. This can't work if m68k is not UAE m68k, PPC emulated m68k just executes trap instruction and bad things happen. Traps needs to be replaced with IO accesses to some reserved space (like UAE boot ROM). Quite easy update.

Much more complex problem: host side code takes parameters from UAE m68k emulator's registers which won't work when UAE m68k is idle and "m68k" is PPC emulated.. Each trap call needs to save parameters to memory and return code also needs to be memory based, not D0 register. This requires lots of really boring updates..

Only after everything else works. Maybe.

[amigafreak68k]

It's very cool that you think about it!

[B14ck W01f]

Originally Posted by Toni Wilen

"Unfortunately" PPC CPU has built-in counter + interrupt when it underflows, count rate is bus clock / 4, apparently this counter is used for OS4 timer.device. Possibly detection of bus clock is also wrong.

We have complete faith in you, Toni

[zipper]

Originally Posted by JimDrew

I don't recall... we tested whatever was running on the PowerMacs during the same time period.

MacOS 8.6 to 9.1; 9.04 found the best by many users.

[FrodeSolheim]

Originally Posted by Toni Wilen

All timers seem to run really fast (20x+), key repeat is instant, floppy clicks really fast. Probably (and hopefully) explains remaining performance problems.

Timing issues seem to be largely resolved with a partial rewrite of the "qemu-uae CPU" (https://github.com/FrodeSolheim/qemu-uae) At least the AmigaOS 4.1 keyboard rate is sane in FS-UAE with the latest updates -More testing is needed to confirm, but it looks much better now

[amigafreak68k]

I think, I didn't must tell you both how strong some people wait for the first test versions...

[Toni Wilen]

I confirm, timing is now correct and speed has increased noticeably. Previous OS4 boot time has been halved.

Boot image is now slower and stays visible longer but I guess it is timer timed, not CPU timed and works as designed.

TODO before public release: RTG mode switching hangs very regularly, some PPC/M68K locking related bug to debug.. EDIT: bug found, public release should not be too far anymore..

[spotUP]

Cool! Appreciate it!