So far, so good.
But where is the equivalent of faster/smarter graphics algorithms, faster/smarter blits, accellerated 3d operations for sound?

I think the ideas from the AA3000+ would be worth picking up: Add a DSP of some kind with a layered ABI/API
- sound effects (echo, volume, surround, phasing, pitch change)
- playing/mixing samples of several different types
- decompression of sound formats
- synthesizing sounds (obviously a rather big range of possibilities)

This is obviously not an overnight job, but neither is adding 3d, and anything worth doing ...

Perhaps a simple solution would be to add typical DSP instructions to the soft-CPU itself which would mean that the DSP stuff would come at little cost. I think ARMv5 did something similar and added some DSP instructions to the ARM core. I was told, though, that those instructions were not very powerful.

Are there any good ones? If so, I'm all for it.

However, making the CPU do the job sounds like a sub-optimal idea when FPGAs are all about parallellism and you can have a specialized core for it.

That is certainly true. Theoretically one unit of a CPU can work independently of others but this requires a lot of effort in the instruction fetch/decode stages of the CPU. An example of this would be the IU and FPU in the PowerPC which have their respective register sets and work like two dedicated and separated CPUs (there aren't even instructions for moving values from FPU to IU registers and back) except for the single instruction stream.

I would love to see a DSP-like unit - or dedicated core - in the NatAmi.

Cheers

Another matter is that if all the 8 channels are exposed to regular programs then there should be another 2 hidden channels that only the DSP can access (and that should be the only hw it can access anyway).

Like being independent of the screen position.

Seems this has been around the block a few times, but I'll add in my distilled point anyway:
I believe that when you get up and running you will come to the conclusion that you need virtual and "unlimited" soundchannels. Anything that is multitasking should not be told "hw channel X is locked - go away" - it should simply stutter and fall over when you try to feed it too many channels.

This is more or less what you have already done with the blitter: You can keep feeding blits without knowing or caring what or who it does right now. (Thought I still think it is a bad idea not to use memory structures to operate it, but that is an implementation detail in many ways.) I'm not sure it would work to "layer"(mix) samples by writing registers multiple times since the mechanics for stopping samples clashes with that.

CLICK HERE 

Here is discussed DSP like instruction additions for the N68k:

CLICK HERE 

Possible DSP additions included:

abs (integer absolute value)
Doesn't save much with branch predication but is commonly used in DSP like algorithms. It might be used more if choosing integer OpenGL-ES.

asli, asri, lsli, lsri, rori, roli (immediate shifts >8)
The flexibility makes compiler writing (and optimizations) much easier. The assembler can optimize immediate <8 in a data register to the shorter existing versions that would act like quick shifts (without the q). Commonly used and improves code density.

bitcnt, popcnt or bfco (count one bits)
Not common but slow in software.

min or max (find min or max of 2 numbers)
Would have some general purpose applications as well as a few DSP like algorithms. Probably would not save a branch with branch predication as discussed.

multiply+add
Very common use but code fusion may be as fast. More options like shifts could give more advantage than just better code density although ease of use starts to suffer IMHO.

better saturation instructions
The ColdFire SATS instruction doesn't improve the 68k's weak handling of integer saturation math very much. This is useful for DSP algorithms as well as OpenGL-ES using fixed point integers. Perhaps creating sticky overflow and/or carry flags with the unused bits in the CC would be useful for at least detecting these conditions after multiple math operations. An unused bit in the CC could be written to enable the sticky bits for nearly 100% compatibility. The additional sticky CC flags would have to be manually tested and cleared of course. Using OpenGL with floating point (and making fp faster) would be the best choice. How about a 2nd fp unit ;) ?

    - Audio Output Connector: CLICK HERE   
    - Natami Sound: CLICK HERE   
    - Back to the Sound: CLICK HERE   
    - Audio DSP for the Natami: CLICK HERE   
    - Audio Test: CLICK HERE 
that should work now.

I have never actually coded for a DSP but I seem to remember that (some? many? most?) DSPs use a fixed point format different from the normal binary representation. I believe there were some notable differences from "normal" integer fixed point arithmetics. Would that have a big impact on the 68k implementation? Or are the resulting problems really just saturation and shift problems?

IIRC on ARM the Neon extension is far more powerful for DSP applications than the (earlier) standard ARM with the added DSP instructions. Has a vector extension been considered for the soft-CPU?

After that, it would be, also in my personal opinion, really good to add SIMD capabilities to the Natami in some technology which is cheap to implement in FPGA.

Cheers