What is the real power of Akiko chip in cd32 ?

[Piru]

Would it help a stock 1200 have 256 color games ported from pc with no slowdowns?

Unlikely, even doom required too much ram.

Not to mention the 020 starving due to no fastmem. Stock A1200 crawls, no akiko can change that.

[Piru]

Here are the results I got:

A1200 030/50Mhz 32Mb (Optimised 020 C2P) - 8481 realtics (8.8 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised Akiko C2P) - 12872 realtics (5.8 fps)

So there you go, Akiko DOES work.

It makes a small difference, but nothing spectacular.

Also, when the actual game gets more complicated the amount of time spent on c2p conversion lets smaller and smaller, and so does the performance boost given by Akiko.

In short: Having akiko on existing A1200 systems would give no benefit whatsoever, except maybe in case of an 030 accelerator. If your system doesn't have an accelerator it is really too slow to run the game anyway. If your system does have an 040/060 accelerator it's as fast to use optimized c2p (they reach copyspeed) anyway.

[Piru]

I can't test as I only have 040, but it's cripplingly slow for me at that resolution

Data cache size? Or is it rendering to framebuffer directly (in which case the writes would be going to cache inhibited memory anyway...)? If I remember correctly there was some specific resolutions that were optimal for the specific cache configurations, while other resolutions were way worse.

Speaking of emulation: MorphOS JIT was significantly faster than the parent 68k from very early on. Even the slowest 603 can easily beat 060@50 in pretty much everything.

[Piru]

Not sure with DoomAttack, to be honest. I doubt it's rendering to the framebuffer directly, given the way Doom renders the scene columns at at a time. You'd at least want to use a buffer that could hold say four 8-bit pixel columns so that you could then transfer them as 32-bit words over the bus. That would be 800 bytes for a 200 pixel display. Or 1600, if you wanted to have a nice 16 column, cache-aligned wide buffer

Ah the cache size vs resolutions were discussed in the PPC ADoom port readme:
http://www.aminet.net/game/shoot/ADoomPPC.readme

Dunno where that overflow comes from though and how you'd go on calculating fast/slow resolutions for various 68k.

[Piru]

How is 6888x extended precision floating point performance, for example? IIRC, the PPC only supports 64-bit IEEE 754, so any accurate emulation is probably going to end up hampered trying to find interesting ways of handling the extra precision. Or, is it (as I suspect) the case that only extended precision read/write are really emulated and any extended precision operations are all carried out at 64-bit instead?

You're right, for performance reasons all FPU calculations are performed by using the native FPU datatypes. This means that the FPU does give slightly different results under emulation. It's fast though.