AmiQuake - new 68k Quake Port

[NovaCoder]

AmiQuake is compiled using gcc version 3.45 and for 060 only, best version we've got I'm afraid

[wawrzon]

what environment you are working under? are you crosscompiling on x86? if so you might use gcc4.5.0 from bernd rosch. the result binary might be faster than what you get. vbcc shoul be naturally even better.

[Karlos]

I have to say, that's an impressive speed for 68K/AGA!

One thing I'd love to see is a quake port that uses Warp3D as the rasterizer. Not a GLQuake port on MiniGL (GLQuake was, by John Carmack's own admission a suboptimal hack), but the vanilla Quake with it's original 3D transformation pipeline with just the rendering stage delegated to warp3d. This should be able to bypass a number of inefficiencies both in the GLQuake code and in MiniGL.

[NovaCoder]

what environment you are working under? are you crosscompiling on x86? if so you might use gcc4.5.0 from bernd rosch. the result binary might be faster than what you get. vbcc shoul be naturally even better.

I use AmidevCPP, I could try gcc4.5.0 but the later 68k versions are rumored to be even slower than the older versions.  I've never really got anywhere with vbcc, I could give that another go I guess.

[NovaCoder]

I have to say, that's an impressive speed for 68K/AGA!

Cool thanks, I've just uploaded v1.07 to AmiNet and it's even quicker on my machine

I'll do a new video when I get the time....

[Karlos]

Cool thanks, I've just uploaded v1.07 to AmiNet and it's even quicker on my machine

I'll do a new video when I get the time....

You say it will work on RTG too, right?

[Karlos]

@NovaCoder

Again here : seven emulated 060 instructions on this game !

Slow down because the 68060.library is not fast you know...

Surely that depends on where they are. If they are in some inner loop, yes, if they are in some initialisation code or something called infrequently, does it matter so much?

@novacoder

Being 68060 only, is there any reason it wouldn't actually run on 68040 too? Are you doing any supervisor mode stuff or relying on any other 060-only features?

[NovaCoder]

Yep I normally add RTG support to my AGA ports because people ask for it, I don't actually have an RTG Amiga so it doesn't really make much difference to me.

I use the CyberGFX API for RTG because it's very fast, P96 should also support it via emulation but it probably won't be as quick as a real CyberGFX card.

[matthey]

@NovaCoder
GCC 3.4.0, last time I checked, was calling utility.library for integer math like 32x32=64 which is good. The library function call is a little slower than an inline but then utility.library can be patched with the fastest 68060 specific code like ThoR's Mu 68060.library does for 32x32=64. I believe GCC 3.4.0 was a special Amiga specific GeekGadgets version of GCC. Perhaps you can try GCC 3.4.0 with AmidevCPP to see if the utility.library is used?

I did some DMIPS test compiles that showed vbbc (vc -cpu=68060 -O2) at 55 DMIPS error free with 68060@60MHz and GCC 3.4.0 (gcc -fomit-frame-pointer -noixemul -m68060 -O2 -mregparm=4) at 56 DMIPS with register passed function variables that generated several bugs. Vbcc was using stack passed variables. The DMIPS code used no 64 bit integer math, which if trapped in GCC could make vbcc faster. The testing was with the latest version of vbcc and the latest beta version of vasm (has some nice peephole optimizations added as well as bug fixes). Vbcc is getting better but it's still not very GCC compatible, it has some bugs above -O1 (although -O1 has much better performance than GCC -O1) and it's slow to compile.

GCC 2.95.3 is still probably the best at code generation. It handles the trapped instructions with local replacement functions (no utility.library). I believe the newest 68k GLQuake is compiled with this as it is one of the best optimized 68k programs I've seen. It's very rare that I find a 68k program that I look through the disassembly and not grimace. Unfortunately, GCC 2.95.3 is not very compatible with newer versions of GCC.

@Karlos
68060 compiled code I've seen should run without problems on a 68040 although at a slower speed. Using the utility.library for integer 32x32=64 is nearly as fast for the 68040 but the missing FINT/FINTRZ in the 68040 for floating point is a performance killer. What were the Motorola Engineers thinking? Programs using floating point should provide separate 68040 and 68060 compiled versions because of this.

[Karlos]

@NovaCoder

@Karlos
68060 compiled code I've seen should run without problems on a 68040 although at a slower speed. Using the utility.library for integer 32x32=64 is nearly as fast for the 68040 but the missing FINT/FINTRZ in the 68040 for floating point is a performance killer. What were the Motorola Engineers thinking? Programs using floating point should provide separate 68040 and 68060 compiled versions because of this.

I'm curious to test it under petunia It only advertises 68020/68882, but implements most of the additional instructions, AFAIK.

[matthey]

I'm curious to test it under petunia It only advertises 68020/68882, but implements most of the additional instructions, AFAIK.

I would imagine it will run at very acceptable speed. The floating point may only be double precision instead of extended precision in some cases but that won't matter for games. The 68k used like Java/Android byte code is a good way to get improved code density out of the PPC . If we get the Hyperion folks to continue 68k support, we could mend the biggest split in the Amiga. Otherwise, Hyperion is going to wake up one day and find AROS has more users than AmigaOS 4.x.

[Karlos]

I would imagine it will run at very acceptable speed.

If my experiments with DoomAttack on my BlizzardPPC are any measure, perhaps. That ran 640x400 faster than my 040 does 320x200.

[youtube]AQ1t5q3xmYk[/youtube]

[matthey]

If my experiments with DoomAttack on my BlizzardPPC are any measure, perhaps. That ran 640x400 faster than my 040 does 320x200.

Yea, that looks like high end 040 or low end 060 speed. DoomAttack at 640x400 (looks much nicer than 320x200 by the way) has no perceivable slow down on my 060@75MHz while 640x480 has enough hesitation in heavy combat to making it difficult to aim.

[Cosmos]

Surely that depends on where they are. If they are in some inner loop, yes, if they are in some initialisation code or something called infrequently, does it matter so much?

Trapped instructions are slow all the time, everywhere and anywhere !

Watch by yourself !

Hopefully, OxyPatcher accelerate a lot, but still 5.6 time slower than a 32x32 routine untrapped...

Explanations :
Trapped mulu64 via the 68060.library: 1852
Real routine mulu64 untrapped : 6

Trapped mulu64 via the 68060.library and OxyPatcher running : 28
Real routine mulu64 untrapped with OxyPatcher running : 5


Ouch !

[NovaCoder]

As promised, here's a quick video of the latest build -> AmiQuake

[Seiya]

you have to change by hand any emulated instructions