In a new series of articles, we discover how the hardware of our heart machine (the Amiga. "Obviously") could have evolved in a perfectly coherent and natural way (i.e. without resorting to components and solutions alien to the ecosystem), starting with audio:

English: https://www.appuntidigitali.it/22424/missed-opportunities-to-improve-the-amiga-chipset-1-audio/

Italian: https://www.appuntidigitali.it/22323/le-occasioni-mancate-per-migliorare-il-chipset-dellamiga-1-laudio/

@cdimauro
That's pretty much how I feel about a DSP. It's putting the carriage before the horse when chipset enhancements needed to be priority number one and done first. With chipset enhancements like planned for AA+, the minimum spec would have gone from 68EC020+AGA@14MHz to 68EC030+AA+@28MHz and the DSP would not be so important. In any case, more memory and memory bandwidth were higher priorities than a DSP and necessary to take advantage of a DSP. For high end systems where there is adequate memory bandwidth and the chipset and CPU are maxed out, the DSP can offload the CPU. Chipset upgrades were the cheapest way to boost Amiga features and value but where CBM failed the most. Chipset upgrades could also reduce the CPU load and memory used which is a trick consoles used but the Amiga lacked many of these tricks like sprite flipping and scaling, tile map support, chunky modes (saves duplicate planar bitmap and c2p), longer audio DMA support and more audio channels (reduces need for mixing channels). A DSP offloads the CPU but uses more memory. The 68k CPUs could have been doing more to reduce memory used by improving code density and improving code sharing (PC relative support). After the lackluster 68020 upgrade, memory consumption often increased with the removal of instructions and features that saved memory. Jay Miner did an amazing job with the 68k Amiga design of leveraging the advantages of integration and reducing the system footprint of a dynamic expandable system only for it to languish with minimal upgrades. Even embedded systems with a GUI rarely reach the footprint of the 68k Amiga and when they do it is not standard hardware with already compiled software available.

Two things on this subject matter:

1. My opinion.
2. Nobody else's.



Seriously though, if we are talking about the audio system, then I want to get something straight: Modern ultra-linear, low noise 24-bit 96kHz audio is perfect for performance capture, production and reproduction. People then look at Paula in *completely* the wrong light, primarily because they are thinking of the single use case of playing back some high quality audio media and are disappointed with the results.

Paula was not designed for audio stream playback, but it can at least do it. It can even do it well, as the Hertz Overload demo shows.

Paula was designed to be musically useful. This is why:

1. It has hardware channels
2. There are more than two of them
3. Each with independent volume control
4. Each with fine control over period sufficient for microtonal precision over many octaves.
5. DMA driven with looping.

These are the quintessential playback features of a hardware sampler / wavetable synth, not a boring AF hifi DAC. I didn't even mention the interchannel modulation capabilities.

With that said, the lost opportunities are as follows:

1. More channels for AGA
2. Consistent approach to reconstruction filter. Every model seems to do this differently.
3. Per channel pan or independent left/right volume
4. A programmable, low-pass resonant filter per channel (analogue) instead of the all channel on/off fixed lowpass (LED)

If just (4) alone had been a feature originally, the Amiga would have given the Emulator a run for it's money, a sampler that cost around $8000 USD at launch a few years earlier and was already considered cheap then!

_________________
Doing stupid things for fun...

@Thread

Arnie on the Vampire V4 provides a nice audio upgrade path and sounds awesome!

_________________
Sent from my Quantum Computer.

@DiscreetFX

Does it though? Or is it all clean and characterless? A lot of what made Paula sound the way she does is down to to the nonlinear behaviour of the DAC, the varying period per channel and associated aliasing, characteristics of the current to voltage conversion and the reconstruction filter.

I don't know if Arnie is just a register compatible implementation that does it all digitally into a linear DAC, but I can't see an FPGA implementation having any of the analogue side behaviours. A "programmed like Paula but sounds like any modern soundcard" isn't an exciting prospect to me. Id much rather have it the other way around: a MIDI sampler with all the special characteristics of Paula's unique sound.

_________________
Doing stupid things for fun...

@matthey

Quote:

matthey wrote: @cdimauro That's pretty much how I feel about a DSP. It's putting the carriage before the horse when chipset enhancements needed to be priority number one and done first.

Indeed. This should be a common understanding for people which know and, especially, have programmed our beloved machines.
Quote:

With chipset enhancements like planned for AA+, the minimum spec would have gone from 68EC020+AGA@14MHz to 68EC030+AA+@28MHz and the DSP would not be so important.

Well, even a 68000@14Mhz could have done A LOT things while keeping the platform very low cost and super competitive even with the consoles of the time (around the '90).

That's another expect (very important! Since the low-end / cheap market was the most important one for the company) which I'll explore on another article of this mini-series.
Quote:

In any case, more memory and memory bandwidth were higher priorities than a DSP and necessary to take advantage of a DSP. For high end systems where there is adequate memory bandwidth and the chipset and CPU are maxed out, the DSP can offload the CPU.

Even the high-end models could have had the chance to offer much more, before considering the DSP. I'll talk about this as well.
Quote:

Chipset upgrades were the cheapest way to boost Amiga features and value but where CBM failed the most. Chipset upgrades could also reduce the CPU load and memory used which is a trick consoles used but the Amiga lacked many of these tricks like sprite flipping and scaling, tile map support, chunky modes (saves duplicate planar bitmap and c2p), longer audio DMA support and more audio channels (reduces need for mixing channels).

Exactly.
Quote:

A DSP offloads the CPU but uses more memory.

And costs much more. And it's completely alien -> needs proper programming.
Quote:

The 68k CPUs could have been doing more to reduce memory used by improving code density and improving code sharing (PC relative support). After the lackluster 68020 upgrade, memory consumption often increased with the removal of instructions and features that saved memory.

Unfortunately Motorola is another company which wasn't able to properly evolve its beautiful architecture, as we know.
Quote:

Jay Miner did an amazing job with the 68k Amiga design of leveraging the advantages of integration and reducing the system footprint of a dynamic expandable system only for it to languish with minimal upgrades. Even embedded systems with a GUI rarely reach the footprint of the 68k Amiga and when they do it is not standard hardware with already compiled software available.

Imagine what could have been possible having a chipset with packed/chunky graphics since the beginning...

@Karlos

Quote:

Karlos wrote: Two things on this subject matter: 1. My opinion. 2. Nobody else's.

ROFL Np: that's a topic were discussions and personal ideas are the only things which matters (e.g.: definitions aren't important).
Quote:

Seriously though, if we are talking about the audio system, then I want to get something straight: Modern ultra-linear, low noise 24-bit 96kHz audio is perfect for performance capture, production and reproduction. People then look at Paula in *completely* the wrong light, primarily because they are thinking of the single use case of playing back some high quality audio media and are disappointed with the results. Paula was not designed for audio stream playback, but it can at least do it. It can even do it well, as the Hertz Overload demo shows. Paula was designed to be musically useful. This is why: 1. It has hardware channels 2. There are more than two of them 3. Each with independent volume control 4. Each with fine control over period sufficient for microtonal precision over many octaves. 5. DMA driven with looping. These are the quintessential playback features of a hardware sampler / wavetable synth, not a boring AF hifi DAC. I didn't even mention the interchannel modulation capabilities.

That's something that you've already stated on EAB (AFAIR), and I fully agree.
Quote:

With that said, the lost opportunities are as follows: 1. More channels for AGA

I prefer to have had something more already with the ECS, like shown in the article.
Quote:

2. Consistent approach to reconstruction filter. Every model seems to do this differently.

Like C64's SID (different sounds on different chip revisions).
Quote:

3. Per channel pan or independent left/right volume

That's something which I've already suggested on another article about the chipset evolution. Super-easy to get (just use the high byte of the volume registers, exactly like the actual low byte. But for controlling the volume on the opposite volume level).
Quote:

4. A programmable, low-pass resonant filter per channel (analogue) instead of the all channel on/off fixed lowpass (LED)

That should be simple as well. AFAIR there's one bit left on the volume register, which might be used for this purpose.
Quote:

If just (4) alone had been a feature originally, the Amiga would have given the Emulator a run for it's money, a sampler that cost around $8000 USD at launch a few years earlier and was already considered cheap then!

@DiscreetFX

Quote:

DiscreetFX wrote: @Thread Arnie on the Vampire V4 provides a nice audio upgrade path and sounds awesome!

I haven't checked the new registers for that, but probably it's quite different from my proposal (which can be easily expanded, as I'll show on other articles).

@cdimauro

Quote:

(the Amiga. "Obviously") could have evolved in a perfectly coherent and natural way (i.e. without resorting to components and solutions alien to the ecosystem),

I don't see how the addition of the DSP would have been alien. The whole Amiga hardware philosophy was to use co-processors instead of the CPU.

According to the document you linked, the DSP was in the order of 10x the speed of 68040 for some tasks, and that's what they were looking at it for.

The 040 can mix something like 32 audio channels, You'd conceivably be getting >300 channels on the DSP and still have the CPU pretty much completely free to do other work. But that's just audio, you'd be able to use it for many other things.

_________________
Whyzzat?

It didn’t take long for DSP cards to show up, though, did it?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: It didn’t take long for DSP cards to show up, though, did it?

Those DSP card for Amigas sold as crazy, even A1X1K and A1X5K have built in DSPs and we know how useful they are.

Last edited by OneTimer1 on 21-Jul-2024 at 08:31 PM.
Last edited by OneTimer1 on 21-Jul-2024 at 08:30 PM.
Last edited by OneTimer1 on 21-Jul-2024 at 08:28 PM.

@minator

Quote:

minator wrote: @cdimauro Quote: (the Amiga. "Obviously") could have evolved in a perfectly coherent and natural way (i.e. without resorting to components and solutions alien to the ecosystem), I don't see how the addition of the DSP would have been alien. The whole Amiga hardware philosophy was to use co-processors instead of the CPU.

Exactly, and we already had coprocessors with a precise design for performing various tasks.

The proposed DSP is completely different -> alien to the existing ecosystem.
Quote:

According to the document you linked, the DSP was in the order of 10x the speed of 68040 for some tasks, and that's what they were looking at it for.

For what? Which problems were needed to solve with this DSP?

BTW, we're only talking about the high-end machines.
Quote:

The 040 can mix something like 32 audio channels, You'd conceivably be getting >300 channels on the DSP and still have the CPU pretty much completely free to do other work.

Again, for doing what?

The Amiga definitely needed more channels, but there was no need for an alien DSP for having them.

The article talks about 12 channels, but that's considering only the existing chipset (OCS and ECS) as they were. It's possible to do much more with further extensions and in a completely "native" way.
Quote:

But that's just audio, you'd be able to use it for many other things.

Sure, and for doing what?

The Amiga market was primarily about cheap multimedia home computers. Do you think that we need to have this market addressed (e.g.: enhanced / expanded) or to pursue a different one (which one)?


@kolla

Quote:

kolla wrote: It didn’t take long for DSP cards to show up, though, did it?

Found on all "personal" computers? When it happened?


@OneTimer1

Quote:

OneTimer1 wrote: @kolla Quote: kolla wrote: It didn’t take long for DSP cards to show up, though, did it? Those DSP card for Amigas sold as crazy,

To professionals?
Quote:

even A1X1K and A1X5K have built in DSPs and we know how useful they are.

Context was around 1990-1992...

@cdimauro

Quote:

cdimauro wrote: Quote: even A1X1K and A1X5K have built in DSPs and we know how useful they are. Context was around 1990-1992...

[quote]

Ah this was the time when the Atari Falcon swept away the x86 PCs with its built in DSP.

DSPs were popular as a semi-multipurpose (with library of codecs) CPU booster/offloader up until about 1995. Digital signal processing needs continued to increase while semi-multipurpose DSPs declined though. So what happened?

1. Transistors became cheaper allowing DSPs to be integrated and embedded in hardware for specific tasks. These are still around but usually not visible.

2. Transistors became cheaper allowing CPUs to have full pipelining and caches. DSPs lost the large advantage in performance they had because of pipelining which was usually possible due to no data caches for streaming data. They only had a modest advantage because of specialized instructions but they were difficult to program and usually at a disadvantage for non-streaming data that could be cached.

3. Transistors became cheaper allowing FPUs to become more powerful, pipelined and parallel. Some digital signal processing is easier or better quality using floating point.

4. Transistors became cheaper allowing CPU SIMD units to process similar DSP workloads of usually streaming data with more parallelism than a DSP. The performance scales better with SMP cores that came later, but the cost is high so SIMD units were used more for high end CPUs.

5. Transistors became cheaper so lower end CPUs added DSP ISA extensions and MAC units.

CBM was already using SIMD technology with the PA-RISC Hombre chipset. The 68060 very much narrowed any advantage of a DSP chip without using SIMD. The integer performance is very good including reg-mem ops, powerful addressing modes, shifts, multiply and low overhead loops that no doubt outperformed some DSPs. Relatively slow bitfield instructions, removing integer 32x32=64 and the minimalist FPU were weaker points for digital signal processing though. ColdFire received DSP like features including MAC unit(s) and instructions like SATS (saturate signed) and BITREV (bit reverse). Also, Motorola had a 68356 SoC chip with 68000 core and 56002 DSP core.

@cdimauro

Atari Falcon's audio DSP focus was a sales flop i.e. 13,000 to 14,000 units sold. The music composition market niche is very small.


AT&T's DSP3210 datasheet and marketing materials
https://github.com/Wrangler491/AA3000-DSP/blob/main/AT%26T%20DSP3210%20DSP%20The%20Multimedia%20Solution.pdf

AT&T's official product positioning for DSP3210
http://bitsavers.trailing-edge.com/components/att/1993_ATT_Microelectronic_Products_Selection_Guide.pdf

From page 19 of 140, AT&T marketed multiple DSP3210 as a "3D graphics workstation co-processor" array.

From page 20 of 140, "DSP32C, 32-bit CMOS DSP (3-D Graphics Floating-Point Accelerator with Graphics Application Library)".

AA3000+ only has a single DSP3210.

Faster 68K CPUs such as 68LC040 speed up many use cases. Mass-producing 68040 socket-based Amiga prepares 68060's entry.

Last edited by Hammer on 22-Jul-2024 at 03:51 AM.
Last edited by Hammer on 22-Jul-2024 at 03:48 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@OneTimer1

Quote:

OneTimer1 wrote: @cdimauro Quote: cdimauro wrote: [quote]Context was around 1990-1992... Ah this was the time when the Atari Falcon swept away the x86 PCs with its built in DSP.

Yes, it was so successful. We all recall it.


@Hammer

Quote:

Hammer wrote: @cdimauro Atari Falcon's audio DSP focus was a sales flop i.e. 13,000 to 14,000 units sold. The music composition market niche is very small.

Indeed. Atari's primary market was similar to the Amiga's one and it didn't require a DSP.

Yes, it was good to have for music (and Atari gained market there), but not for the primary market.
Quote:

AT&T's DSP3210 datasheet and marketing materials https://github.com/Wrangler491/AA3000-DSP/blob/main/AT%26T%20DSP3210%20DSP%20The%20Multimedia%20Solution.pdf AT&T's official product positioning for DSP3210 http://bitsavers.trailing-edge.com/components/att/1993_ATT_Microelectronic_Products_Selection_Guide.pdf

I know how it worked and I've also reported links to Commodore's documentation about such DSP.
Quote:

From page 19 of 140, AT&T marketed multiple DSP3210 as a "3D graphics workstation co-processor" array.

Pay attention to the "array" word: it's not there because of a typo.
Quote:

From page 20 of 140, "DSP32C, 32-bit CMOS DSP (3-D Graphics Floating-Point Accelerator with Graphics Application Library)".

Same as above: I know it and Commodore's documentation reported several parts about the AT&T libraries.

The point is: it was not needed for the Amiga market.
Quote:

AA3000+ only has a single DSP3210.

And it was not needed: my article is there to prove it.
Quote:

Faster 68K CPUs such as 68LC040 speed up many use cases. Mass-producing 68040 socket-based Amiga prepares 68060's entry.

Only for the high-end.

Amiga's primary market was very different. And, what's worse, the Amiga chipset could have been extended / evolved WITHOUT requiring an alien and very expensive (compared to the chipset cost) component like such DSP.

Again, the article explains everything in detail (and more to come on the next articles).


@matthey: I substantially agree.

@cdimauro

Quote:

@cdimauro Only for the high-end.

It's too bad $108 68EC040-25 wasn't useable for the Amiga.

Apple's 68LC040-25 Macs reached $1000 USD range in 1993 which is not high end.

Commodore's A3640 cost is about $400 which includes the full 68040-25.

Due to weak partitioned design, end users couldn't assemble CD32's $399 and A3640 $400.

3rd party Amiga accelerator vendors don't have Commodore's economics of scale.

Quote:

@cdimauro Amiga's primary market was very different. And, what's worse, the Amiga chipset could have been extended / evolved WITHOUT requiring an alien and very expensive (compared to the chipset cost) component like such DSP.

Ex-Amiga team 3DO's geometry math co-processor was CPU PIO driven i.e. CPU writes values into the geometry math co-processor's registers and the CPU polls the geometry math co-processor's completion state. This should sound similar to CPU writes into Akiko registers.

This is a quick hack to obtain higher math power.

Amiga Blitter and DSP3210 have setup costs.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@minator
Quote:

that's just audio, you'd be able to use it for many other things.

One such example here.
https://www.youtube.com/watch?v=q3ClsZtDDCY

Anyone interested in DSP could just get a Delfina card or whatnot…

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

minator Quote:

The 040 can mix something like 32 audio channels, You'd conceivably be getting >300 channels on the DSP and still have the CPU pretty much completely free to do other work. But that's just audio, you'd be able to use it for many other things.

CBM list for "AT&T application libraries" follows.

o PCM in/out audio 8, 16 bit
o ADCDM in/out audio 8, 16 bit
o V.32 modem
o AT command set
o V.42 bis
o MMP.X
o 2D and 3D graphics
o MPEG-1 audio encode/decode
o JPEG encode/decode
o speech synthesis
o speech recognition

Part of the value was in the provided libraries since compiling code for a DSP is challenging.

http://ftp.vim.org/pub/ftp/ftp/infomac/info/hdwr/av-dsp-faq-101.txt Quote:

BTW, the 'C' compiler is a complete piece of shit. It produces some of the worst code I have ever seen (trying to do a matrix multiply in 3210 'C' ran 5 times slower than the host 68k on a Quadra 700 - rewriting the same in assembler ran 7-8 times *faster*). If you do any serious 3210 programming, you will need to learn 3210 assembler.

The CPU is offloaded for the "applications" above but most of the time there is no performance increase. The Amiga already has a chipset for 2D and the blitter can also perform simple processing like decompression which it does for floppy decompression and it could have been improved to do more including DSP like workloads. Many Amiga users use software CPU blitting instead of the hardware blitter when it is faster even though the blitter can still offload the CPU. Similarly, the DSP needs to be significantly higher performance than the CPU at an application or it is not worthwhile.

Rob Quote:

One such example here. https://www.youtube.com/watch?v=q3ClsZtDDCY

Mandelbrot performance may not be the best digital signal processing example for either a DSP or the 68060. The 68060 is missing many 6888x instructions that are valuable for Mandelbrot, it is performing the calculations with extended precision fp instead of single precision fp, it has reasonably good performance from a compile even with the missing instructions and it should have been clocked at 100-150MHz instead of 50MHz with the 8-stage pipeline it has. A naive compile with GCC will likely use trapped instructions even when the target is only a 68060 although this is not true for VBCC which may give higher performance (I did not test VBCC vs GCC with Mandelbrot after working on the VBCC FPU support code). One of the comments from the video follows.

https://www.youtube.com/watch?v=q3ClsZtDDCY Quote:

@kopernikus1955 3 years ago The demo is not compiled correctly in regard to the FPU. With the correct compiler options, the 68060-FPU is just as fast as the DSP.

There is a good chance the comment is correct. The 68060 FPU is minimalist so not the best for DSP workloads and the missing 6888x instructions are used for Mandelbrot more than most FPU code (Mandelbrot code is one of the 6888x strengths although it is outperformed by the 68060 when the trapped instructions are avoided). The DSP code is likely hand optimized which could be done for the 68060 considering compilers usually have weak support for the 68060. The DSP local memory may be very high performance SRAM but copying main memory to the local memory is not free and a large store buffer is needed to keep the results written back to main memory from slowing the DSP. The 68060 has high performance SRAM caches that are transparently used and greatly reduce one of the most common stalls which is waiting on memory. An AT&T DSP 3210@1GHz would be a waste for an Amiga and unimpressive. A 68060@1GHz would transform the Amiga. A 68060@1GHz with semi-modern caches and improvements would blow minds and revive the Amiga. The Mandelbrot shown in the video should allow real time scrolling and zooming at a higher resolution.

Edit: It looks like Wrangler Amiga is using VBCC to compile the Madelbrot program but did he compiler for the 68060? Another video shows him compiling for a 68020+68881.

Getting the most out of DSPs
https://youtu.be/8vBsG4V_oCc?t=1050

It is easy to change the makefile for a 68060 which could make a big difference as compiling for a 68881 will likely give many trapped instructions. Wrangler Amiga goes on to talk about waiting for DSP instruction results where the pipeline does not stall to wait for the result like most modern CPUs. Use the result too soon and it may have the previous result or trash in the register. The solution is manually inserting NOP instructions. One screen of DSP assembly code shows ~23% of instructions are NOPs. Memorize those instruction latencies or your assembly programs are going to be buggy. At least the code is easier to read than PPC assembly code.

Last edited by matthey on 24-Jul-2024 at 02:41 AM.