For some time now there has been insistent circulation in the forums dedicated to the platform of the heart (the Amiga, “obviously”. At least for me and several others lucky enough to have had the privilege of being able to enjoy it) the idea that in its evolution a DSP could (and should!) have been introduced to make up for some chronic shortcomings due to the few updates that have been made to its chipset.
Not a peregrine idea, as it was corroborated by some research & development work that was done by Commodore’s own engineers (not the original team that, unfortunately, had left a few years after the introduction of the first Amiga), who had experimented with AT&T’s DSP3210 that had been integrated in some Amiga 3000+ prototypes.
Why a DSP?
The reasons for adopting a DSP like that are scattered in various statements and/or interviews by some of the Commodore staff members who were involved in the development of the hardware.
In particular by Dave Haynie, on the Amiga 3000+ page:
There was an audio CODEC here, designed to allow 16-bit, 2-channel recording and playback
[…]
In addition, there was a separate mono CODEC with hardware phase correction, which supported modem protocols up to V32.
[…]
we wanted it for a general purpose signal computing engine […] The DSP3210 could do some floating point operations (single precision only) ten times faster than the 68040
[…]
two audio CODECs. One was for modem projects, a lower bitrate mono CODEC with phase correction, and the other was a 16-bit, CD-quality audio CODEC, for high quality audio I/O
[…]
the DSP would have been able to give us at least eight channels of playback at full CD quality
and another interview:
This would have delivered 16-bit audio I/O, software modem, number crunching 5x-10x faster than a 68040, etc.
One more interview, but from Mike Sinz:
the DSP was powerful enough to do a full V.32bis/V.42bis FAX/Data modem *IN SOFTWARE*
[…]
It would also so really good speach and sound and math (talk about fast rendering times!)
And finally an interview with Lew Eggebrecht:
The current capability is four channels of 8-bit samples at 27 KHz and we forsee that most systems in the future will have CD capability. Most of the sound and music will come from this so it was not as important to put that technology in. Our long term strategy is to put the DSP in every system, obviously. That will be sound in and sound out and you can do pretty much whatever you like
Here it should be pointed out immediately that the interview is from 1993, thus after the marketing of the Amiga 4000 and 1200, and refers to the future Amiga models that will have to deal with the technology gap that has gripped the platform for quite some time.
Other material can be found in an introductory document about the DSP and the Amiga 3000+:
DSPs are good for performing a large number of repetitive mathematical operations combined with extreme memory bandwidth requirements.
DSPs are capable of real-time signal processing of real-world data (e.g. audio samples).
and in another concerning the implementation of the system:
Audio rate sampling should certainly support the CD frequency, 44.1kHz, directly, and should also consider AAA system 16-bit HiFi sampling rates
[…]
For modem applications […] Telephone interfaces should consider the V22 and V32 standards for modem and the V27 and V29 standards for Fax
In summary, the DSP would be used for:
- acquisition of CD-quality stereo audio (16-bit, and at least 44.1Khz);
- up to 8 audio channels with the same quality;
- telecommunications modems;
- signal processing and massive calculation (compared to the top of the range at the time: the 68040).
It should also be noted that DSPs should have been adopted by the top-of-the-range machines and not the low-end ones, as stated by Mike Sinz:
The A3000+ was a AA (oops, AGA) based machine with the same box/formfactor of the A3000 but also included an AT&T DSP32 (very cool)
The A1000+ was a super-low-cost 2-slot AGA-based Amiga. Goal was to have this thing list at $999 including hard drive, 2 or 4 megs of RAM depending on RAM prices, keyboard, etc.
On the other hand, and as Lew Eggebrecht pointed out, the general adoption of DSPs (thus for all systems) would only have to take place with the machines that would follow the AGA ones, and in the long run. In fact, at the time, CDs had only just begun to take hold in computers):
The current capability is four channels of 8-bit samples at 27 KHz and we forsee that most systems in the future will have CD capability. Most of the sound and music will come from this so it was not as important to put that technology in. Our long term strategy is to put the DSP in every system, obviously. That will be sound in and sound out and you can do pretty much whatever you like.
Was this the way forward?
One might ask at this point whether this made sense, and therefore whether this should have been the way to go.
Having a little monster to grind out numbers might have been interesting for a high-end machine, especially one as multimedia-oriented as the Amiga always was, but… why even think of supporting a modem? It is true that telecommunication between devices connected via the telephone was booming, but it was mostly the stuff of enthusiasts.
Different story for polyphony. In fact, one of the Amiga’s biggest problems was that the audio compartment remained absolutely crystallised throughout its existence, despite the fact that it started with a frightening technological advantage when the first model was introduced.
The competition certainly didn’t stand idly by and presented innovations that surpassed (sometimes by a lot!) the four 28Khz 8-bit stereo PCM channels of the Amiga 1000 (which, as already mentioned, remained exactly the same for all models).
The first was Apple with its IIGS, which with its 32 voices (16 in stereo) was the first, very strong, signal in this sense. The second was Acorn, which made 8 stereo channels available with the Archimedes. But PCs also opened the dances with the very famous (but very expensive) Roland MT-32, which went up to 32 voices. This is to name the most famous examples, but they were not the only ones.
In 1991, a good six years after the arrival of the Amiga 1000, the solution that Commodore’s engineers were experimenting with on a model that was anything but cheap was a DSP: a component alien to the ecosystem, incompatible with the existing software, and that would have required special programming (with the convoluted assembly language that a DSP can have).
Definitely not the way to go. Not least because the target market for these machines continued to be completely ignored: that of the much cheaper and more affordable home computers, with a particular predilection for gaming.
What is astounding, however, is that one could easily have found the solution “at home” (even that of sampling audio from external sources. Another point of those mentioned above as reasons for adopting the DSP) if one had shown a much deeper knowledge (and competence) of how the machine works.
How custom chips work
One could well say, in fact, that it was right under one’s nose (literally!), but only by looking at a particular diagram: that of DMA slots allocation (showing how memory accesses, usually called slots, are reserved and, in general, function). Which looks like this:
Just to give a quick introduction, what is shown is what happens when a single line is to be displayed on the screen, which is made up of 227.5 memory accesses (of which only 226 are actually available), where one access requires two clock cycles (an access is called a “colour clock“, simplified to CC, in amighist jargon) and allows one word (16 bits = 2 bytes) to be read or written at a time.
All these accesses are divided into groups: starting with the memory “refresh” circuitry (to which the first 4 slots are assigned), then the disk (3 slots), the audio (4 slots), the sprites (16 slots. A sprite requires two) and finally the circuitry that actually deals with displaying the screen graphics (160 slots). Copper, Blitter and processor can use the remaining slots, in this order of priority (the first being the most important).
When one of these devices needs to access the memory, it makes use of one of the slots assigned to it, and can then proceed directly to read or write (I am deliberately simplifying, avoiding talking about conflicts between sprites and video controller), without asking anyone for an account (those slots are its own and no one can take them away from it).
The masterful functioning of the custom chips in the Amiga platform is due to its main designer (Jay Miner), who modelled the slots system in perfect symbiosis with the functioning of Motorola’s 68000 processor.
In fact, the latter is unaffected by the memory accesses of these devices (apart from contending with Copper and Blitter, eventually), since such accesses normally occur when it is engaged in internal calculations and, therefore, never accesses memory. So it is as if it always sees memory free. Brilliant, no?
This idyll is only interrupted when the video controller has to display graphics with more colours (again, I am simplifying, avoiding mentioning the Dual-Playfield mode). So with low-resolution graphics (320×200 or 320×256. Here I ignore interlaced mode, which does not affect this discussion anyway) with 32 or more colours, or high resolution (640×200 or 640×256) with 8 or 16 colours.
After this information, and going over the above diagram in detail, it is now easy to understand how this works. Normally (screens without too many colours), all devices use the odd-numbered slots to access memory, thus leaving the even-numbered ones all free for CPU & co.
The memory refresh circuitry uses slots $-1 (because it starts at the end of the previous video line), $1, $3, $5, disk $7, $9, $B (numbering is hexadecimal), audio $D, $F, $11, $13, sprites $15, $17 (both for the first sprite), $19, $1B (for the second), …, and so on, up to $31, $33 (for the eighth).
The video controller scheme is somewhat more complex, since the use of slots depends firstly on the horizontal resolution, and secondly on whether or not hardware scroll is used (which we ignore for the moment). The use of the slots for graphics follows, in any case, what has already been said: first the odd-numbered slots are used, and then, if necessary, the even-numbered ones, as can be verified by a part of the above diagram:
As can be seen, the slots allocated for bitplanes in low resolution are $4F, $4B, $4D, $49, $4E, $4A: the first four (up to 16 colours) are odd, while the last two (32 and 64/4096 colours) are even. Similar for high resolution, which instead uses $4B, $49, $4A, $48: the first two (up to 4 colours) are odd and the last two (8 and 16 colours) are even. And so on.
Let’s go beyond four audio channels!
At this point, the solution to the problem arises, to say the least, by checking the remaining free slots in the audio section:
We have seen that the audio channels have slots $D, $F, $11, $13 (all odd, in fact) reserved exclusively for them. Simply move everything back one slot, and take advantage of the four free even-numbered slots: $C, $E, $10, $12, which could well be used for four more channels. The game is done!
Note that this idea does not require any additional memory or memory bandwidth: one simply (!) exploits the resources already available and which would otherwise be unused or used by Copper, Blitter or CPU.
Obviously, this falls exclusively on the level of memory and accesses with the DMA to retrieve samples data, but more is still needed. For example, new registers to program these channels.
If we wanted to go for savings at all costs, we could similarly use the horrible patch that was introduced in the AGA chipset, which provides a 256-colour palette, but still using the existing 32 registers in OCS and ECS to load the values, using a register specifying which of the 8 banks of 32 colours we want to access. With audio, exactly the same thing could be done, with a register in which it would be possible to choose which bank of the 4 channels to select.
This mechanism would also serve to be able to select the bank of audio channels with regard to certain special registers (also used for other components): DMACON/R, INTENA/R, INTREQ/R, and ADKCON/R. Then these registers would also be duplicated internally (but only for the bits used by the audio) for each bank of 4 channels.
A much more elegant solution would be to have a dedicated and directly accessible block of registers without such a mechanism, but at this point it would be necessary to extend the area to address the registers of the custom chips quite a bit (OCS, ECS, and AGA only have 256 registers mapped from address $DFF000), and to reorganise the registers better (I won’t add the details because I don’t want to make the article too long).
Which, in any case, would have been feasible long ago thanks to improvements in manufacturing processes (which allowed more transistors to be packed in the same area).
What matters, in any case, is that the solution found does not require a DSP completely alien to the Amiga platform, but integrates perfectly with the existing one, as its natural extension, and requires very little effort to support it.
But we can go further…
And it is so natural that it would be possible to extend the mechanism by adding four more audio channels, exploiting exactly the same principle, drawing from the four (even) free slots preceding those just selected:
So $4, $6, $8, $A will be the slots to be used for up to 12 audio channels in total. Obviously, exactly the same considerations as above apply to their registers and settings.
These are the slots in the middle of the disk DMA area and, to some extent, that of the memory refresh circuitry, but this is completely irrelevant to the question, as these devices only use the odd-numbered slots assigned to them and do not require any expansion.
Since, as they say, appetite comes with eating, using the same logic one can close the circle and also implement the first point that was listed among the possibilities offered by the introduction of the DSP: the acquisition of (external) audio.
In this case, it is sufficient to use the last two even-numbered slots left free:
Hence $0 and $2, which also fall in the area of memory refresh circuitry, but which at the time were the exclusive preserve of Copper, Blitter and Processor.
Obviously in this case, being devoted to sample acquisition only (to be written to memory), the audio registers will not be needed to control volume and other properties: it will suffice to set the memory location from which to write the data, and how large that area is (in terms of number of words = 16 bits = byte pairs).
The implementation cost
So far it all sounds very nice: no less than 12 audio channels available (you can already imagine the polyphonic richness that would come out of this) and a couple more for capturing stereo samples. A daydream for many amigans who has been forced to fall back on software like OctaMED to try and listen to more than the standard 4 voices.
Of course, there is always a price to pay, because supporting multiple channels requires quite a few transistors for the purpose. The chip that handles the audio is Denise, but it also integrates support for other devices, I/O, and system stuff (interrupts).
So it’s not clear how much of its area would be dedicated and only to the required modifications. Roughly one could think of “tripling” it, but three chips would be far too many (although perfectly in line with the technological advances that manufacturing processes have made since 1985).
On the other hand, always multiplying/duplicating the number of chips is a process that, needless to say, does not scale at all if we were to consider adding more channels (which is also feasible, but will be the subject of another article).
The solution, in this case, is to implement just two DACs with higher resolution (16 bits, for example), using circuitry that takes care of “grouping” (“summing”) the data (at 8 + 6 bits: 14 bits. 8 bits for samples and 6 for volume) of each audio channel. Obviously, the two DACs will take care of the left and right output channels respectively.
This should make it possible to scale up quite easily as the number of available audio channels grows. Above all, such a solution should be far cheaper than adding an alien element like the DSP that has been proposed to make up for these deficiencies.
Which can also do other things, it is true, but how useful this will be to the Amiga ecosystem is largely debatable. Let’s start with CD quality support, for example. The modifications suggested in this article increase polyphony (even beyond what would have been proposed with the DSP), but it remains limited to 8 bits and cannot reach the 44.1Khz of CDs (the Amiga’s limit via DMA is about 28Khz).
Which, however, is not much missed, if we consider the time period in question: 1991-92. On the other hand, Lew Eggebrecht himself had already reiterated it in the interview he gave in ’93 (so 1-2 years later), that only in the future the systems would have CD capabilities, and this would be added via the DSP in a long term strategy (so not in the short term: there would still be a wait).
Which is absolutely fine, if we also consider that increasing the frequency and, above all, the samples width (from 8 to 16 bits) would have entailed a proportional consumption of memory and the corresponding bandwidth, which were not available in large quantities.
Finally, also from an economical point of view, the DSP solution appears to be overkill, to say the least, since Eggebrecht again claims that such a chip would have cost little (but only according to him. See below):
We can’t make that decision right now – it’s something we’ll have to look at but in that time frame, even in the low end, every machine is likely to have a DSP. It’s a cost thing – although the AT&T chip itself is only $20 to $30 or so. AT&T has a number of lower cost options, as well, that are designed more specifically to go on the motherboard.
On the contrary: very overpriced, if we think that the production cost of the whole AGA chipset (at least the three main chips, but probably other secondary ones were included) cost Commodore only $12 (in fact, the Amiga 1200 was very profitable, as reported by the top managers of the time).
So increasing the polyphony to 8 voices (by hypothetically adding an additional sound chip) or to 12 (by adding two) would have cost, very crudely, about $4 and $8 more, respectively.
So far less than the cost of the DSP (in ’93!), and with the huge advantages of being developed entirely in-house (instead of tying hands and feet to an external manufacturer) as well as perfectly integrated into the platform (it would have been a natural extension of it!).
Conclusions
I think it is quite evident how the Amiga’s audio subsystem could have evolved if there had been a better knowledge of the functioning of the platform on the part of Commodore’s technical staff, accompanied by a clearer and, above all, pragmatic vision (thus taking into account the market in which they operated and the annexed needs of those who worked on it) on how to make everything evolve in a natural and coherent manner.
Very easy solutions to problems do not require much effort, and are often within reach of anyone (no stroke of genius required, as they say). This is demonstrated, for example, by the way the packed/chunky to planar conversion circuitry was introduced in Akiko (and which we have already discussed in an article last year – In Italian).
The Amiga, in short, would have deserved a very different treatment, and not only from the continuously vituperated (managerial) top management. The faults, in my opinion, should be attributed to everyone (therefore also to the engineers), because shortcomings, inefficiencies and incompetence can be found in every sector.
Since little has been said about this in the purely technical sphere, this is the first in a small series of articles that will deal specifically with some of these issues. The next one will shed light on the graphical compartment and what could have been done by remaining inextricably linked to the characteristics of this marvellous system, improving and enhancing the peculiarities that have been appreciated by users and, in particular, by the programmers who have pleasantly programmed its hardware.
