Please, continue to post picture and so on.

Natami is cool.

Can you take the Temperature of it?
And tell us the passive cooler size?

On the 68030 we had c2p that reached copyspeed, but they required 1 blitter pass or scrambling of the chunky buffer. Datacache access stalled the chipmem writes, so it was very important to keep everything in registers. On the 060 the situation is different.
The fastest way to do c2p on Mc68060 is the rol merge:

  ror.l #4,d1
  move.l d0,d7
  eor.l d1,d7
  and.l #$0f0f0f0f,d7
  eor.l d7,d0
  eor.l d7,d1
  rol.l #4,d1
  

You can drop the last rol away. Then you need a new set of transpositions, and add a few extra rotations to the code, to unrotate registers back for writing to planes.

The 060 can execute 2 instructions per clock if they don't share registers. By pairing the merges we double the speed:

  ror.l #4,d1
  ror.l #4,d2
  move.l d0,d7
  move.l d3,d6
  eor.l d1,d7
  eor.l d2,d6
  and.l #$0f0f0f0f,d7
  and.l #$0f0f0f0f,d6
  eor.l d7,d0
  eor.l d6,d2
  eor.l d7,d1
  eor.l d6,d3
  (rol.l #4,d1)
  (rol.l #4,d2)
  

On an AGA amiga in lores a chipmemwrite takes around 26 cycles. (52 free instructions on a Mc68060 clocked at 50mhz will , (superscalar instructions)

  move.l d1,(a0)+ ;chipwrite
  ror.l #4,d1  ;free
  ror.l #4,d2  ;free
  move.l d0,d7  ;free
  ..
  move.l instack(sp),d4   ;free if in cache.
  

By doing the c2p in fastmem first, we only need 2/3 registers later when we merge the chipram copyloop into another method.

On 060 52 instructions are more than enough to convert c2p. On 030 it will be no point in doing this, because all the free instructions(13) are used in the c2p.

Almost all scenes have a strong tint. I bet they only use 6 bitplanes of the HAM8 and have the remaining two bitplanes constant (the two bitplanes that have the modify R, G, B, set commands).

That is probobly correct.
...

This demo is doing realtime perspective correction with the fpu (for every 16pixel), mipmap(variable texture size) to improve the cachehits. Fastmem2fastmem c2p to remove the chipmem bottleneck

Massive by Skarla:

EXTERNAL LINK 
In this posting I dissassembled some innerloops of doomclone games and optimized them by using self modified code: Since you a are a former Democoder you might find them interesting.

EXTERNAL LINK

I measured this with my NAe60R. I don't have the exact measurements, but it uses a quite small heatsink with no active cooling.

Ambient temperature  24C
   
50MHz idle  41C
50MHz load  46C
   
90MHz idle  47C
90MHz load  54C
   
100MHz idle  46C
100MHz load  55C

Yes, I personally wrote a c2p that used one blitter pass.

ror.l #4,d1   move.l d0,d7   eor.l d1,d7   and.l #$0f0f0f0f,d7   eor.l d7,d0   eor.l d7,d1   rol.l #4,d1

Ha, I learned the 3-eor-trick from the guy who invented it (don't remember the name, I met him on usenet). I think I came up with the blitter pass on my own, though.

By doing the c2p in fastmem first, we only need 2/3 registers later when we merge the chipram copyloop into another method.

Yes, I already imagined that this was the idea of doing c2p in fastmem. You could do the copying with just two address registers and copy to chipmem while doing more interesting stuff. With self-modified code you probably could make that one address register with a large immediate offset.

This demo is doing realtime perspective correction with the fpu (for every 16pixel), mipmap(variable texture size) to improve the cachehits. Fastmem2fastmem c2p to remove the chipmem bottleneck

Nice demo, awful soundtrack. Having an FPU of course is a great advantage. I had a 50 MHz 68882 but hardly anyone else did. I wonder how many 060 Amigas there are...

In this posting I dissassembled some innerloops of doomclone games and optimized them by using self modified code: Since you a are a former Democoder you might find them interesting.     EXTERNAL LINK

I will have a look at that when I have more time. BTW, I used self-modified code for my point-projection in a 3D engine. It was the only way to not move data between registers and RAM. I merely replaced some immediates with the values required for the next frame and flushed the instruction cache. With an FPU all of this could have happened in parallel to something more interesting... :)

Which one? The V-scroller is mostly done.

I had to stop doing anything on the 3D-core because of various job problems (got made redundant, got another job - it was awful, etc etc) and still trying to get back on my feet now.

Hardly matters, Thomas is still marching onward to getting the Natami working :)

Gunnar = ????

Aha. You can delete this reason then because it is not valid. Having an MMU does not imply that code pages are write-protected.

I found your remark about AB3D2 interesting. I always had a feeling that the game was published knowing that it was unplayable but trying to make some bugs before leaving the business. I was very disappointed at the time because I actually liked AB3D a lot and completed it. To me it had a very good atmosphere despite the fact that the copper chunky was horrible.

If I ever dig out my A1200, I might find that doom type tech demo by a Dutch coder that in my opinion was the best doom engine at the time. It was on Aminet, in case you are still interested in the subject. It had floor texturemapping and a very good frame rate.

Wow, the internet never forgets:

EXTERNAL LINK 
I found that engine very good at the time.

  I see there is DOpus 4 there on your desktop.
  What about Directory Opus Magellan then ?
  Running smoothly? Or some issues like in AmigaOS4.x ?

Good idea. I did not try it yet. But I see no reason why it shouldn't work - it is compatible with OS3.1 after all :)