Adding small, but important, features to the chipset to improve sound and graphics are only part of the possible improvements that would have allowed the Amiga platform to evolve much better, also making life much easier for programmers and artists.
So far, however, these modifications are based exclusively on the original chipset (the OCS), digging into its inner workings and trying to make the most of some rather obscure and little known aspects of it (being exquisitely technical details).
Although very useful (and they would certainly have made a difference, had they been made available at the right time!), this would not have been sufficient to face the much more demanding challenges of the long term, with the competition that has meanwhile certainly not been idle.
Increasing frequencies
The obvious answer to this is to increase frequencies. On the other hand, improvements in manufacturing processes have, over the years, made it possible not only to increase the number of transistors with the same area, but have also given the go-ahead for increasing the clock of electronic components (or reducing power consumption with the same frequencies).
This topic was discussed in a recent article, which dealt with several purely technical aspects and, above all, with the compatibility problems that arise in such cases, illustrating how to deal with them in such a way as to fully preserve the execution of existing code.
The advantages of a system (chipset first and foremost, but also the processor) running at 14Mhz (instead of the canonical 7Mhz) are those that certainly have the greatest impact (just think of the Blitter, which is 2.5 to 3 times faster: for this alone, it should have been taken into consideration!), even if these modifications are extremely conservative (it was “only” a question of running everything at double the frequency).
So nothing was proposed in terms of additional functionality, so as to go beyond what was already offered by the original chipsets (OCS and ECS). On the other hand, the theme was also that of “no new chips” (SIGH!), and if those of the ECS, even with all the modifications made with respect to OCS, are not considered new chips by Commodore engineers, in the same, identical way, chips implementing “only” 14Mhz operation cannot be considered as such. A question of consistency.
Having higher frequencies at our disposal is a great opportunity to go beyond that, and further expand on what has already been said in the previous two articles in this series.
Increase slots for (almost) all devices
First of all, however, it is only right to show again the slot allocation diagram of the Amiga’s DMA slots:
because it represents the heart of the operation of the three custom chips of this wonderful platform, and it is also the one we must necessarily refer to when we speak of increasing its operating frequency.
The aforementioned article on the 14Mhz system showed how the logic of the video controller would work in this mode and, therefore, how the various slots dedicated to it would “change positions” (as well as functioning) in order to be able to operate correctly (basically with the same logic).
The position has changed because, just to brush up on that idea, in order to display the same graphics in a line on the screen, but with the 14Mhz clock, the number of clock cycles available has been doubled: while with the 7Mhz clock the graphics started from slot $38 (hexadecimal), now it starts from $70; and so on ($39 becomes $72, $3A is $74, etc. etc.) for all the other slots allocated for screen graphics.
The slots were left exactly the same (therefore also in the same position) for the other devices (memory refresh circuitry, disk, audio and sprites) because, and as already written, the purpose of that article was to show how it would be possible to increase the clock of the entire system in a backwards compatible manner, but without introducing any additional functionality (which is, instead, the purpose of this series).
The same mechanism, however, can very well be applied to all devices. So the memory refresh slots would become $-2 (the first, which was previously $-1, always starts at the end of the previous video line), $2, $6, $A, while the disk slots would be $E, $12, $16, followed by audio with $1A, $1E, $22, $26, and finally the sprites ranging from $2A, $2E up to $62, $66: all with positions “doubled’ compared to the one they had when operating at 7Mhz.
This means that the new slots that immediately follow them would remain free. Just to be clear, all the original slots now have a doubled position within a video line (and, therefore, by mere mathematical definition that position will always be an even number). So all those that follow them have an odd position, and are available for other uses.
Adding more audio channels…
We can now use some of these free slots to add other audio channels, for example, as was illustrated in the first article in this series. We have seen that the Amiga reserves four for this purpose ($D, $F, $11, $13):
which with the doubled clock have “moved” into slots $1A, $1E, $22, $26.
Having clocked at double the frequency also means that slots have been added exactly after each of the original ones. So the new slots that have been “created” are $1B, $1F, $23, $27, and these are exactly the ones that can be used to add four more channels.
Obviously having the ability to access Chip memory (the only one the custom chips can read from or write to) is only one of the requirements to be able to get channels, but then you also need the dedicated registers and logic to implement them.
All this has already been covered extensively in the first article, so it is sufficient to refer to it for all the relevant details. Moreover, the mechanism is absolutely scalable and completely transparent for developers.
The article also showed how to exploit the free even slots to add channels, up to a maximum of 12 + 2 (two for sampling sounds from outside), which in reality are 14 (it is not compulsory to reserve two channels just for sampling: on paper, you can decide to exploit them as you wish).
It is clear that if one did not limit oneself to just the four new audio slots that were created by doubling the frequency and applied the same principle to the slots of the other 10 new audio channels, one could, on balance, have as many as 28 audio channels at one’s disposal.
Finally, taking advantage of the three new slots ($F, $13, $17) created in the disk DMA section and the last new slot ($B) in the memory refresh section:
four more audio channels could be added, bringing the total to 32 channels (stereo and independent).
I would say there is nothing more to add…
… and more sprites!
Similarly, the sprite area has twice as many new slots available:
which would allow, as a consequence, to double their number, going from 8 to 16 in 4 colours, or from 4 to 8 in 16 colours (I am simplifying in order not to lengthen the discourse too much).
The previous article dedicated to graphics showed, however, how it would have been possible to double their number already with the 7Mhz system, making use of the relative free slots (the even ones) adjacent to those normally used and implemented by the original chipset.
As a result, the doubling of frequency could allow a total of as many as 32 4-colour sprites, or 16 16-colour sprites: a dream for game programmers, but also for gamers who would have been able to count on far more visually satisfying games (and many arcade conversions would have been up to the standard of the originals).
Let’s free the Copper from its chains
There is another element that would immediately benefit from the increased frequencies, and that is Copper: the coprocessor dedicated to controlling and modifying the behaviour of custom chips by synchronising with the video signal.
Having many more free slots available (with the same horizontal video resolution) would, in fact, have allowed it to set more registers in the same video line to be displayed, allowing more colours to be changed, for example, or more sprites to be multiplexed.
In reality, Copper was limited to using only the odd-numbered slots, leaving the even-numbered ones to the other devices in order to avoid interference (but, above all, to simplify its implementation to the bare minimum):
The Copper is a two-cycle processor that requests the bus only during odd-numbered memory cycles. This prevents collision with audio, disk, refresh, sprites, and most low resolution display DMA access, all of which use only the even-numbered memory cycles. The Copper, therefore, needs priority over only the 680×0 and the blitter (the DMA channel that handles animation, line drawing, and polygon filling).
The problem is that this limits its use even when it could have been used in the even slots that were free. It would have been better to leave it to the programmers, in short, how and when to use it, allowing full flexibility and the possibility to exploit it to the full.
For this reason, and in accordance with what was written in the previous article, enabling the new Copper operation for the MOVE instruction that can set several registers at a time should at the same time unlock it to use all available free slots (leaving priority to other devices when they need to access memory. Except for Blitter and CPU which would always remain with a lower priority than its own).
In this way, Copper would gain more value and functionality, allowing for more operations per video line and thus more special effects. This, combined with a restructuring of its three instructions (which will be proposed in another article) and a change on some of its internal mechanisms (shown in the next article), would eventually lead to its full potential.
Even higher frequencies (?)
The trick is clear by now, I think: doubling the operating frequencies makes it possible to double the number of slots available in the video line to be displayed (and all devices with allocated areas), thus making it possible to double the number of audio channels and sprites.
All this while being able to count on a Blitter that is well over twice as fast (for the same resolution and number of colours displayed), and graphics that require half as many clock cycles to display (or the new slots could be used to increase the number of colours to display).
It all sounds nice and easy, since doubling the frequency (from 14 to 28Mhz) of chipset operation yet again would result in 64 audio channels and 64 sprites (and further benefits in the other areas, as already described).
However, there are actually a couple of very important considerations to be made. The first is that the original Amiga chipset does not actually run at 7Mhz, but at least at 14Mhz internally (perhaps even at 28Mhz with the ECS Denise chip supporting the super high resolution 1280 horizontal pixels).
In fact 7Mhz is the memory access frequency, where each access requires two clock cycles (so in reality the memory would be at 3.5Mhz, where each access requires only one clock cycle), which is quite a different thing.
This means that passing the system clock (which is also used by the CPU, which normally runs synchronously with the custom chips. Although it doesn’t always have to be this way) from 7 to 14Mhz would actually require the three custom chips to work at 28 or even 56Mhz (for the version that supports super-high definition), which could lead to power consumption problems and related higher temperatures, perhaps forcing them to resort to some fans for cooling.
I don’t think there could have been any particular problems supporting such frequencies, given the huge advances in manufacturing processes since the first Amiga was introduced, but it is good to make clear all the aspects (including the negatives) involved in working at much higher frequencies.
For this reason a further doubling of the frequencies, bringing them to 28Mhz, could be a headache also going ahead in time (for example in 1992: year of commercialization of the Amiga 1200 and 4000, based on the new AGA chipset), considering that the chipset should work at 56Mhz (there should be no problems) or even at 112Mhz for the super high resolution version (and here there could be surely some, considering that we speak of extremely high frequencies for the epoch).
The second consideration concerns memories: going from 7 to 14Mhz is equivalent to having to use 140ns DRAMs (as opposed to 280ns for the 7Mhz ones of the original chipset), which were absolutely affordable even in the early 1990s (the ECS chipset was released in 1990, with the Amiga 3000, which among other things used faster memories).
Whereas going to 28Mhz would have required 70ns DRAMs. Certainly available in 1992 (the year of the AGA chipset), but not cheap.
This meant that in the future there would have been a bifurcation of the chipset, with a “basic” version (running at lower frequencies) for cheaper systems, and an advanced version (with higher frequencies) for more expensive ones. This is no big deal, considering that the AAA (the chipset being worked on after the AGA) already included two versions.
A final consideration to be made concerns future clock increases. Doubling the frequencies each time, in fact, is absolutely unsustainable, especially since DRAM memories have had a huge setback in this respect, forcing CPU manufacturers to decouple their respective operating frequencies (and, therefore, the bus/interface connecting them).
It would have made more sense, therefore, to try to exploit as much as possible. For example, if quadrupling the frequency with respect to the original chipset was not possible or not convenient, one could have opted for only tripling it (thus from 7 to 21Mhz). And so on for the other increases (after 28Mhz there could have been 35Mhz, 42Mhz, etc.).
The use of such “strange” clocks is not a taboo, but it certainly complicates things and poses limits which are also quite heavy because, to give one example, it does not allow high resolution or super high resolution graphics to be displayed with the same colours displayed by low resolution ones.
To be clearer, and taking a triple clock (21Mhz), for example, displaying 256-colour screens is easily possible in low (320 horizontal pixels) and high (640 pixels) resolution, but not in super high (1280) resolution because there are not enough slots available to read graphics with all those colours.
In addition, the operating logic of the video circuitry would have to be changed slightly, so as to eliminate the extreme rigidity and perfect synchronisation between the logic that takes care of reading data from the memory and that which then takes care of displaying them, thus switching to an “on-demand” system (the logic for reading data must begin “just before” the display logic is about to finish displaying those already loaded).
Nothing transcendental, but even this must be taken into account, especially in view of the realisation of cheaper Amiga computers that must make use of less fast memories (better a triple clock than just a double one, because a quadruple one would be too expensive). Which are also the ones that made the fortune of this platform, and therefore should have been the focus of the company’s engineers.
Conclusions
As I stated at the beginning, the trivial solution to improve the performance of a system is to increase its operating frequencies. It is trivial because I think it is rather obvious and anyone can think of “increasing the numbers” to “get more”.
The peculiarities of a system as complex as the Amiga, however, allow one to reap other benefits by reading between the folds of the operating specifications of its custom chips and seizing the opportunities hidden therein, as demonstrated here.
Much could have been done, then, and much more by making appropriate use of another factor, which will be discussed in the next article.
