What is the real power of Akiko chip in cd32 ?

[matthey]

@Cammy
Your downloaded archive contained corrupt files. Lha reported...

*** Error on file 'Midi_Instruments'  : I/O Error

I re-downloaded the archive but had the same error. It might be worth checking your archive.

DoomAttack with the timedemo (no sound) works but gave an error and no fps...

Error: timed 2134 gametics in 2420 realtics

ADoom with the timedemo (and sound) works and gives me an error but shows the fps...

Error: timed 2134 gametics in 1869 realtics ( 40.0 fps)

The closest "competitor" on the Doom benchmark list happens to be an Amiga with PPC604E-150 at 2x the clock speed and 4x the CPU cache as my lowly 68060 . The Natami 060 and fpga processors could be up to 2x as fast as me too.

[matthey]

The issue is 95% of Amiga games had sloppy n00b coding.

I wouldn't say 95%. There were some very good Amiga programmers too.

Both A1200 and CD32 should have had a single SIMM slot to add fast ram AND Akiko.

The CD32 should have had 1 SIMM slot, IDE and PCMCIA. I would have traded those for Akiko any day. Better yet would have been Akiko plus SIMM, IDE and PCMCIA. Surely that would have only cost a couple of dollars.

It seems to run really slow on my 1200 and I'd expect better from an 060.

The 060 speed is reasonable for a port written in C. Yea, the 060 was better than the Pentium at integer but the game was optimized for the x86. I'm sure a little 060 assembler could speed things up. ADoom is very playable upscaled to 640x400 (~11 fps by timedemo) on my Amiga which looks MUCH nicer so what is the point? The actual game plays much faster than the timedemo for some reason. I would say I'm getting >20 fps at 640x400 judging by how Quake feels at 20 fps on my Amiga.

anyway, how do you start the timedemo...

To run the test yourself, use this command line: DoomAttack -forcedemo -timedemo demo3

[matthey]

2134 gametics in 15115 realtics

That should be 5.4 to 5.5 fps based on Cammy's numbers assuming a linear result. I bet the game is playable though where 5.5 fps would not be. The actual game seems like it has twice the frame rate of the timedemo.

[matthey]

@DonutKing
Thanks. That sounds reasonable.

seriously, should it not be faster on an 060?

Are you saying you have a 68060 and you're only getting 5 fps? I'm getting 40fps with ADoom using 68060@75MHz. ADoom was fastest on my system using...

adoom -forcedemo -timedemo demo3 -cpu 68060

@commodorejohn
There are CPU optimized versions of part of the code but that probably just means that it was compiled for the 68060 which doesn't mean much. Assembler for the 060 by someone who knows what they are doing will usually result in a 50% speed increase from 060 compiled code I've seen. The c2p routines are probably assembler but I'm using a gfx board which skips this.

[matthey]

yes. it runs that slow. I have a Bliz1260 50mhz  with 64MB ram.

There's something wrong with your setup. In the Doom benchmark page, there is an Amiga 1200 with 060@50MHz using AGA getting 24.6 fps and even a 1200 with 040@40MHz using AGA getting 13.4 fps. You should be at least 20fps. Here is my setup...

All 060 caches turned on and MAPROM off (for BlizKick) in accelerator menu (ESC)
AmigaOS 3.9 BB4
"BlizKick myROM QUIET" line in S:Startup-Sequence using my custom made 3.9 ROM
ThoR's MuLibs installed (http://aminet.net/util/libs/MMULib.lha)
"MuFastZero MOVESSP ON" line added to S:Startup-Sequence for above
CopyMem installed (http://aminet.net/util/boot/CopyMem.lha)

The most likely problems would be incorrectly installed 68040 and 68060 libraries and not turning on the caches. The 68040.library in Libs: should be tiny. Mine is 748 bytes. If yours is over 1k then that is your problem. Open a shell and type "CPU" . You should see "System: 68060 68882 (INST: Cache Burst) (DATA: Cache CopyBack)". If these are fine, then try removing programs from your WBStartup, S:User-Startup and S:Startup-Sequence that might be causing a slow down.

Edit: I installed the 060 executable for Doom Attack and it made a large difference. I now get 1945 realtics (38.4 fps) instead of 2420 realtics (30.9 fps). ADoom is still faster though. The Doom Attack manual does mention removing divsu.l and divsl.l instructions because he thought they didn't exist on the 68060 but they do (the 68060 manual is not clear in some places) and his compiler did not support the 060 at all. The executables probably do contain some assembler which does provide a speed increase. There is probably room for improvement and the source is on Aminet. Here is Doom Attack with CPU specific executables...

http://aminet.net/game/shoot/DoomAttack.lha

[matthey]

For 603/604 PPC systems, you see a bigger improvement because they are able to render the frame significantly faster than the 040/060 can and the whole argument about time spent rendering versus time spent C2P/copying becomes relevant again.

I agree with your point about c2p becoming a smaller percentage of CPU usage as the CPU becomes faster. I'm not so sure that the 603/604 PPC on the Phase5 boards were significantly faster than the 68060. I obtained the same results of 40 fps in the timedemo test with 68060 at 1/2 the clock speed as an Amiga with 604e. The 68060 can compete with and sometimes win in a competition with a RISC processor at 2x the speed. The 2x faster clock speed, 4x greater CPU cache and faster memory access of the PPC looks better on paper and advertisements than real life results show. It was a while before the low end PPC macs even outperformed the 68040@40MHz. The code and compilers continued to improve for the PPC as that was the focus of marketing and development while the 68060 was abandoned before it's limits were explored on any desktop platform. On the Amiga, the bottlenecks in WarpUp and the poor PPC optimization in AmigaOS 4.x certainly remove any significant speed advantage of the PPC beyond clocking it up. Do you want to buy this CPU with a 2GHz CPU or this one with a 3GHz CPU? The vast majority of people will think the 3GHz sounds faster so it should play games faster and it doesn't even cost 50% more.

[matthey]

Out of curiosity, how is it at 640x400 RTG with 68060 (I can't test as I only have 040, but it's cripplingly slow for me at that resolution)?

ADoom at 640x400 RTG (Mediator with Voodoo 4 and no gfx bus overclocking) is ~11 fps using the timedemo test on my 68060@75MHz. The actual game play feels a little faster than Quake at 20 fps (HW 3D) on the same setup. It takes VERY heavy combat situations to perceive any slow down at all. There is no slow down just walking around, turning and shooting a barrel like in your video, or was that my slow 1.86 GHz Windows machine pausing just playing the low resolution video :/. That would be a good show for a 68040 though. I'm surprised Doom Attack worked at 640x400 as the docs say it doesn't support increasing the horizontal resolution.

[matthey]

Mediator1200 or Mediator4000?

Mediator 3000T/4000T (works through Zorro II/III slots but only 6-8 MB/s as I recall)

It wasn't an 040, it was the 040 executable running under OS4's emulation on a 603e. The device recording the footage was a bit slow too. My old mouse was acting up, has a tendency to move in jumps (you can see that when opening the preferences application and it overshoots). The performance of the game itself was pretty consistent.

The PPC emulation in AmigaOS 4.x is fast at least. Maybe AmigaOS 4.x should just use emulated 68k code as applets like Android OS uses java . The faster 604 CyberStorm PPCs should be close to emulating the 68k at 68060 speed with 3x the clock speed, 4x the cache, over 2x the memory bandwidth and much more memory needed. That's progress though :/.

[matthey]

Which is fair enough. Other than a few esoteric fractal generators, did anything use extended precision?

Yes. All fp values are extended to extended precision in registers and all calculations use extended precision on the 68k FPU unless specified to use less precision. More precision means less chance of rounding and cumulative errors and there is no speed difference so it's generally best to keep the extra precision and round the value to the needed precision before storing or outputting. Even the 68060 which traps extended precision immediate floats still does full extended precision fpu calculations and register updates. Very few programs rely on the extra precision of the floating point.

I have heard that the CD32 patched graphics.library/WriteChunkyPixels() to use the Akiko so it might have transparently sped up more programs than Wing Commander while not making them incompatible to non CD32 Amigas. The docs for this function mention installing and using HW chunky to planar although it's a bit cryptic.

[matthey]

I was under the impression that commodore only documented using Akiko by calling WriteChunkyPixels.

Didn't the CD32 version of WingCommander need patching to run on regular Amiga's though? It could have easily been other incompatibilities than using the Akiko directly. I wouldn't be too surprised to see a game use undocumented programming to give a speed increase. A more impressive game was a competitive advantage as long as it worked on the majority of hardware, in many game developers minds.