AmiQuake 2 - new 68k Quake 2 Port

[matthey]

NovaCoder is on vacation for a few weeks so he might be slow to answer. It's not because he's ignoring anyone.

[matthey]

To be fair they were talking about 14MHz 68020s, not 80MHz 68060s. Even the high-end Amiga was shipping with a 25MHz 68040, which could probably run Quake 2 at around 2 FPS (has anyone tried with this release?).

There is a video on youtube of 68040@40MHz with Mediator+Voodoo 3 running Q2 with Warp3D at probably 10-15fps. I expect this could be 15-20fps with better optimization (the 68k Warp3D code is a disgrace in optimization and Q2 is probably compiled for the 68060 with plenty of room for assembler optimizations). I think 2-5 fps is probably about right on a stock 3640 with 68040@25MHz although it wouldn't run with only the 16MB of memory on the motherboard (another problem). The high end 68040 (with heavy optimizations) and most 68060 accelerators were capable (FPU and memory) but were unusual and often didn't have RTG let alone 3D capabilities. The 68k compilers never optimized as well for the 68040 and 68060 as they did for the 68020/68030. The 68040 and 68060 can do a lot in parallel but code optimization was never really emphasized by Motorola like Intel did for the x86 (or aggressive clock increases). The 68040 could outperform the 486 at a lower clock and the 68060 could outperform the Pentium at a lower clock. The 68060 is absolutely amazing in the hands of a capable assembler programmer. It can do 2 integer instructions (or 1 integer + 1 FPU instruction), 1 FPU instruction and 1 branch instruction in parallel while folding away predicted branches for no cost loops (the decrement and branch is free). The 68060 was probably the best all around processor of that time (and a few years after) but it was doomed from the start as the big users were already planning moves to the RISC promised land (slower for several years without thousands of dollars of memory). Motorola knew then that the PPC would dominate the future and x86.

P.S. Wolfenstein and Doom are another story and could have made money on the Amiga (would have sold a lot of accelerators for the 1200).

[matthey]

IIRC, at least on the 68060, the floating point unit is already faster for a lot of common arithmetic operations than fixed point would be, especially for multiplication which 3D transformation naturally uses a lot.

On paper, the 68060 integer MULS/MULU is 2 cycles while fp FMUL is 3 cycles. However, speed isn't just measured in the shortest timings. The integer MULS/MULU is pOEP only not allowing for parallel operations. The FMUL can operate in parallel with integer instructions (a characteristic of 68k coprocessors predating the 68060). A compiler with good instruction scheduling can usually do the most in parallel with mixed integer and fp. Sometimes no integer instructions during floating point instruction execution is possible though. Converting from fp to int and int to fp is 3 cycles. If the 3D engine is setup to use floating point then it's usually not worth trying to convert to fixed point but a properly designed fixed point 3D engine probably is faster even on the 68060. The lack of integer 32x32=64 bit makes fixed point more difficult and slower on the 68060 though.

P.S. I haven't seen a 68k compiler do proper instruction scheduling with FPU instructions. Frank Wille and I were talking about the possibility of adding to vbcc as well as improving the FPU support in general. I don't know if the poor code is the limiting factor or the cache sizes with complex 3D scenes. If the limitation is the code quality and not the caches, it may be possible to run Quake like engines at a lot better frame rate with an improved 68k compiler. Quake 3 would probably need GL support and a fast 68060 though .

[matthey]

Like a disassembler but the code it produces can usually be reassembled to an executable, this isn't always true for some disassemblers like Resource etc.

Reassemblers are disassemblers that specialize in generating assembler code that can be assembled back to original with good accuracy. Resource is one of the most accurate (68k/Amiga) but requires manual changes (using it's gui/editor) for best results. IRA is not as good of a reassembler (despite any documentation claims) in my opinion. It will automatically identify more than Resource but isn't as accurate. It is a better general purpose disassembler with many useful options. The best automatic/smart reassembler for the Amiga is the updated ADis I have worked on:

http://www.heywheel.com/matthey/Amiga/ADis.lha

Most ADis disassembled system friendly 68k Amiga programs can be assembled with vasm and work. It's still good to look for problem areas as it's very difficult to determine whether small amounts of data are code or data. ADis needs some more improvements too.