As we all know, the Amiga was a marvellous machine that, upon its introduction, brought about a real revolution in all fields: from the fabulous chipset that gave us graphics and sound never seen before in the consumer field, to the extremely fast multitasking OS with a practical and simple graphical interface that relieved us from typing abstruse commands.
Unfortunately, Commodore did not know how to capitalise on the incredible technological advantage it had in its hands, and preferred to play it cool by procrastinating its development and evolution for several years, lulled by the enormous distance that the competition of the time was in.
1985 to 1990: ECS arrives
But while the introduction of the 2.0. version of the OS brought a lot of novelty, modernising several aspects and laying the foundations for future advancements, the hardware, on the other hand, basically remained in the doldrums, as the ECS chipset (released at the same time as the new OS) was only a dusting-off of the original (OCS), with the addition of a few modifications that did not contribute to the new visual, sound, and computational requirements of the time.
The chief engineer of the group that made it, Dave Haynie, blamed it bluntly on the corporate managers of the time, basically washing his hands of it. His phrase ‘Read my lips – no new chips‘ attributed to them and also found in some interviews is famous. For example here:
Actually, with the ECS came new versions of Agnus and Denise (two of the three Amiga chips), which introduced the following innovations:
- possibility of freely reprogramming the resolution of the video signal (similar to what very old chips such as the Motorola 6845 integrated in the MDA and CGA graphics cards of PCs already allowed in 1980);
- Introduction of ‘super high resolution‘ (1280×200 for NTSC machines and 1280×256 for PAL machines);
- greater granularity in the ability to position sprites horizontally. The horizontal position of the sprites can thus be selected at 1/2 pixel (as opposed to low resolution), allowing for finer movement;
- possibility of switching from NTSC to PAL signal, or vice versa;
- sprites displayed at the edges of the screen;
- various useful features for genlocks;
- Blitter capable of handling areas up to 32768 x 32768 pixels (instead of the 1024 x 1024 of OCS);
- up to 2MB of Chip memory (the only one accessible for custom chips), compared to 512kB for OCS.
Actually, there are other rather obscure functionalities (the functioning of which is not documented) that were introduced with the ECS (and which can also be found in the later AGA), namely the so-called Ultra-Highres registers (UHRES), which would seem to control a display and a sprite that are part of an additional video circuitry based on VRAM memory.
As we can see, then, we are in the presence of new chips that have introduced several new functionalities, whatever Commodore’s chief engineer might say. The problem is that a good part of these innovations were of little use for typical user use: applications and, above all, games.
Yes, the possibility of having 1 or 2MB of Chip memory is certainly handy for being able to use more assets in games or for graphics or audio programs. Of much rarer use are, on the other hand, the sprites that can be displayed at the edges, or the possibility of managing areas larger than 1024×1024 with the Blitter.
In fact, Amiga games remained essentially the same, as nothing had changed in terms of graphics (still 32/64 colours maximum selectable from a palette of 4096. And Dual Playfield mode limited to 8 + 7 colours maximum) and sound (4 channels of 8-bit PCM audio).
These paltry improvements did not justify the creation of ad hoc games. Of course, with at least 1MB of Chip RAM some more interested things could be realised, but in any case a fleet of machines big enough to think about an investment in this sense was needed, which at the time did not arrive (first came the Amiga 3000 with the ECS and only two years later the Amiga 500 Plus and Amiga 600: another unsuccessful choice of the Commodore management!).
What could have been done: 256 colours!
If the Commodore managers had their serious faults, it cannot be said that the engineers were exempt either, considering that they too showed a clear lack of vision as to which features would have been better introduced with the ECS despite the limitation of not producing chips that were too different (bigger = more expensive to produce) from the original ones (it is in this sense that the statement ‘no new chips‘ should be read).
Let’s start with the certainly most coveted one: the infamous 256 colours. As we know, the OCS was limited to displaying a maximum of 32 colours selectable from a palette of 4096, going up to 64 with the special EHB (Extra-Half Brite) mode that added another 32 taking them from the previous 32, but halving their brightness (so a colour was present with two different brightnesses: full and halved).
It is precisely by exploiting the principle of the EHB that 128 colours (32 colours in 4 different brightnesses: normal, 3/4, half, 1/4) or 256 colours (32 colours with 8 brightnesses) could have been obtained. This is nothing new or complicated, as demonstrated in 1987 (i.e. a good three years before the ECS) by the Acorn Archimedes (which only had 16 colours selectable from 4096, but with 16 different brightnesses) and even earlier by the Commodore 16 and Plus/4 from the same company.
The implementation would have been quite simple precisely because the ECS already showed how it could be done, with the addition of two new pointers to the bitplanes that would be added to the six already present. If the ECS added the two useless UHRES pointers (see above), I don’t see why it wouldn’t have been possible to add two more to the bitplanes to get the enormously more useful 256 colours!
Dual Playfield mode like AGA
Similarly, the addition of the aforementioned two new pointers to the bitplanes could also have improved the famous Dual Playfield mode that was used in so many successful video games, which allowed two completely independent scrollable screens to be displayed.
The limitation of the OCS, due to the only six bitplanes available, was that the two screens could have a maximum of 8 and 7 colours respectively (7 because one of the 8 combinations was used to ‘pierce’ the screen and display the graphics of the other) .
But with eight bitplanes at your disposal, the music changes dramatically and you can have two screens with 16 + 7 colours (using seven bitplanes) or 16 + 15 (using all eight bitplanes): exactly what the later AGA chipset allowed!
Needless to say, much better games could have been realised by exploiting them wisely, even with all the limitations of the chipset (which does not have the same memory bandwidth available as the AGA for reading screen and/or sprite data).
Panning on all audio channels
The Paula chip, in charge of audio and some other functions (disk, mouse, serial, interrupts, etc.), never saw any improvement throughout the Amiga’s lifetime. No chipset subsequent to the original one, in fact, ever modified it. Sadly.
We know that it provides four DMA channels that play 8-bit (PCM) sound samples, each with an independent volume control (65 levels: 64 + maximum volume). The audio section is one of the features that made the Amiga famous and gave us thousands of soundtracks in games, demos, or even just the famous ‘MODs‘.
The unique feature of these channels is that they are paired in the two stereo channels whose sounds then reach our ears: two are reproduced in the left channel and the other two in the right channel (technically this distribution is called panning).
In this way, it is possible to achieve a certain surround effect that produces a greater form of ‘immersion’ in the environment (imagine a sound ‘moving’ from the right to the left ear, for example).
Unfortunately, this channel arrangement makes it more complicated to simulate sounds within a room, if a sound has to be heard with different volume coming from the left and right channel.
To simulate such an effect on the Amiga, two channels must be used to reproduce the same sound on the left and right (but with different volume, depending on how the sound is to be perceived). So two sounds take up all four audio channels available with Paula, leaving no other channels to reproduce other sounds.
A trivial modification to Paula would have made it possible, instead, to specify the volume level separately for the left and right channels, giving as many as four different sounds the possibility of being reproduced with panning and, thus, being able to reproduce a more immersive ambient sound.
Currently, each audio channel of Paula has an associated 16-bit register in which the volume level can be specified in the lowest 7 bits. All other 9 bits are unused. In order to introduce panning in the four channels, it would therefore have been sufficient to duplicate the 8 low bits of this register in the other 8 high bits, so that the volume could be set separately for the left and right channel. All in an absolutely backward compatible manner.
You can easily imagine how a very simple change like this would have contributed to much better sound in games (where, by the way, programmers were forced to set different channels every time a sound had to be ‘moved’ from the left to the right channel, for example). But it was not only games that would benefit, of course.
Better access to CPU chip memory
A real scourge for processors other than the 68000 (and 68010) is the fact that accesses to the Chip memory are tightly regulated by the Agnus chip, which requires waiting for four clock cycles (equal to two access ‘slots‘).
This was cleverly designed by the designer of the chipset, Jay Miner, because he realised that when it had to access the memory, the 68000 always did so using four clock cycles.
Which was marvellously good for this microprocessor, but absolutely bad for all the others that came later (from the 68020 onwards, to be clear) if they were able to access the memory in two clock cycles.
This major limitation resulted in significantly lower efficiency (halved) in the event that the processor had to take on some of the work, instead of delegating everything to the Blitter. This limited its utilisation, as it could not optimally make use of all possible memory accesses.
Again, no chipset ever modified this behaviour, which would have allowed performance gains on more advanced systems (including the Amiga 1200): the ECS would have been a good opportunity to remove this constraint, considering that it was first used by the aforementioned Amiga 3000, which made use of a 68030.
BOBs’ mask caching
Finally, another change that would have made a significant improvement in games would have been to introduce a small cache for the mask used in BOBs (the graphic objects ‘drawn’ using the Blitter). Here is some useful information for understanding the issue without, however, getting too lost in the details.
As we know, the Amiga uses planar graphics to store the data of graphic objects. Depending on the colour depth used (2, 4, 8, …, 64 colours), the graphics are stored in bitplanes (1, 2, 3, …, 6).
The Blitter is able to draw moving objects by taking the data one bitplane at a time and ‘embedding’ it in the appropriate bitplane of the screen that will be displayed. So if the screen has 32 colours, it will have to repeat this operation five times: once for each bitplane to be updated.
In order to “embed” the BOB graphics into the screen graphics, the Blitter must make use of an additional bitplane, whose individual bit values decide which graphics to draw in a specific pixel: when the bit is 0, the screen graphics will remain unchanged for that pixel, while the BOB graphics will be copied if that bit should be 1, instead.
Basically, the Blitter reads the data from the screen graphics, the data from the BOB, the mask, and then combines them together using the latter to decide how to do it. This is repeated, each time, for all the bitplanes on the screen.
The mask is always the same and is reloaded each time the operation for a specific bitplane is to start. So if the screen is 32 colours, the mask data will be loaded five times, even though they are exactly the same each time, with a considerable waste of resources (bandwidth to memory).
A modification that would have eliminated this waste would have consisted of a modification to the Blitter, integrating a small amount of cache memory in which to store the mask data on the first operation, and then taking it from the cache for all subsequent operations.
A rather simple mechanism, as can be imagined, but which unfortunately requires some cost for this additional memory. It must be said, however, that not a great deal of it is needed either. In fact, BOBs were generally small in size. So a cache of only 64×64 pixels/bits (equal to 512 bytes) would have been more than sufficient to satisfy the vast majority of cases.
This is the most substantial and expensive modification (in terms of silicon/area on the chip), so one could argue that it would not fall under ‘no new chips‘. So not feasible, by definition.
Except that for the Amiga 3000, a special chip was made, called Amber, which took care of the deinterlacing (scan doubling) of the graphics so that they could be displayed on multisync monitors at higher frequencies than the original video signal, with greater image stability. But that’s not all: this chip used as much as 384kB of memory to perform this operation!
I don’t see, therefore, why this small cache could not have been implemented, which, moreover, would have been far more useful.
Conclusions
I don’t think there is any doubt that Commodore, and specifically the Amiga project, was sunk by the inability of a management team that was absolutely not up to the task of understanding the potential and being able to manage the treasure that had ended up in their hands.
Personally, however, I believe that the technical team also bore a great deal of responsibility, as they were unable to adequately develop a project that had ample room for improvement.
Commodore’s managers basked in having found the new golden goose (after the Commodore 64), but so did the engineers: both lived ‘on borrowed time’, doing very little to strengthen the Amiga project and make it even more solid and competitive.
In particular, the engineers lacked the vision of what the platform really needed, from the point of view of the most important features to implement in order to meet the developers’ needs (especially for games, which were the main reason why so many Amigas were sold).
The changes suggested above are the stuff of simple implementation, which could have fallen under the managerial dictate of ‘no new chips‘, and which any Amiga developer who has worked in the field I’m sure could easily confirm.
“The Amiga, Born a Champion“
“We made Amiga, They f@cked it up“
