Initially, part 7 was about something different altogether, but I have decided to bump that up to part 8 instead. Because as I was working on part 7, it dawned on me that I still had some loose ends to tie up on the Amiga side of the story. In the old days, I would just combine two or more subjects into a single post, but I am trying to go for shorter, more structured blog posts now. This whole series of blogs has gotten way out of hand anyway. I never expected to have so many parts, but now that I do, I need to try and make things more organized.
The first thing that dawned on me is that I did not discuss all capabilities of the Amiga’s graphics yet. Mainly I skipped over the Amiga’s sprite capabilities altogether. I did not do this deliberately, it is just that the Amiga’s sprite capabilities are rather limited compared to the rest of the hardware, so they have limited use for graphical effects. The mouse cursor is a sprite (yes, hardware mouse cursor in 1985).
The Amiga has 8 sprites in total. The biggest limitation here is their width: they can only be 16 pixels wide. The height is ‘unlimited’, so a sprite can stretch across the entire screen height. You can use 3 colours and transparency in a sprite, which is another limitation. If you want more colours, you can overlay multiple sprites at the same position, but you’ll go through all 8 sprites quickly that way.
Like on many other systems, sprite multiplexing is possible, so as soon as a sprite has finished drawing, the same sprite can be re-used lower down the screen by modifying its position. Since the Amiga has a copper, it is very easy to perform such sprite multiplexing tricks. There is a web page dedicated to sprite tricks used in Amiga games, if you want to really get into the topic.
Rather than using sprite tricks, some games and demos would also simulate sprites by using the blitter instead. The blitter can quickly move memory around, and is also capable of simple logical equations, so you can simulate transparency. You would first backup the screen data for the rectangle where you were about to draw the sprite. Then you’d copy the sprite data to the screen. Afterwards, you would restore the original screen data again. Blitter ‘sprites’ implemented this way are known as ‘Blitter Objects’: bobs. With bobs, there are no hard limits to the size, the number of colours used, or the amount of bobs on screen simultaneously. The main limit was the bandwidth available to the blitter. One thing you’d lose with bobs compared to sprites is hardware collision detection though.
Another specific feature of the Amiga’s graphics hardware is the dual-playfield option. I find it rather difficult to explain this, since it is so alien to modern graphics solutions.
First of all, what is a ‘playfield’ anyway? Well, in short, it is more or less a screen buffer. A buffer that is not necessarily the same size as the screen, but one that contains the buffer for a level of a 2d game (hence the name ‘playfield’). I already covered the Amiga’s flexible use of screen buffers earlier. By having playfields that are wider and/or taller than the actual screen area, you can scroll through this playfield easily. Vertical scrolling can simply be done by changing the starting pointers for the bitplanes. Horizontal scrolling has some hardware-assistance: you can only address bitplanes on word-boundaries, which would mean 16-pixel steps. So the graphics hardware can perform horizontal scrolling by adding a delay from 0 to 15 pixels. This way you can get pixel-perfect scrolling in all directions, at no extra cost of the CPU or blitter.
A dual-playfield then is what the name implies: you use two playfields at the same time. The two playfields are overlaid on top of eachother (with transparency). The playfields do not have to be the same dimensions, and they can be scrolled individually. This can be used for overlays for example, such as a HUD in games. One limitation with dual-playfield is that you are still limited to using 6 bitplanes in total, and you have to divide them equally between the two playfields. When using an uneven number of bitplanes, the first playfield gets the extra bitplane.
I have already covered the sound capabilities of the Amiga in my earlier blog about chiptunes. If you are familiar with the MOD music format from tracker software, that is pretty much what the Amiga’s sound capabilities are like: the Paula sound chip has 4 channels of 8-bit sample playback, with two channels on the left and two channels on the right for stereo output. It is very simple, yet very effective. The Amiga has been hugely influential in the world of computer music. Many other platforms have adopted MOD music, even if it meant that the CPU had to mix the channels in software, and sample playback had to be faked with some special trick, because the system had no regular DAC (such as the PC speaker, the C64’s SID, or the Atari ST). Especially on the PC, nearly all demos from the early 90s made use of MOD music. Quite a few games also adopted the standard. There were also a few very popular tracker programs on PC, such as Scream Tracker from Future Crew, and FastTracker from Triton. They took the module music from Amiga, and extended it to have more channels, more effects, 16-bit samples and such, as PC hardware became more powerful.
So far I have only covered the classic Amiga hardware. Generally known as the Original Chip Set (OCS). Closely related is the Enhanced Chip Set (ECS), which is found in the A500+, A600 and A3000 machines. The main differences are that ECS now supports up to 2 MB of chip ram (as opposed to 512 KB or 1 MB for the earlier chips), and there is a new super hi-res mode of 1280×512 available (interlaced), albeit with only 4 colours. Other than that, the capabilities and performance are exactly the same.
When Commodore introduced the Amiga 4000 in 1992, they introduced the Advanced Graphics Architecture (AGA). This chipset was also used in the more affordable Amiga 1200, and the CD32 game console. As the name already implies, the updated chipset concentrated on graphics only. The sound capabilities were still unchanged.
AGA mainly added two extra bitplanes, for an 8-bit 256 colour mode, and a HAM8 mode with a maximum of 262144 colours (18-bit), rather than the 4096 colours (12-bit) of the original. The chipset was also upgraded from 16-bit to 32-bit memory fetches, to provide for the extra bandwidth required for the new modes. Other than that, the copper and blitter remained unchanged.
The A1200 and A4000 also used more advanced CPUs than the original 68000 at 7 MHz. The A1200 used a 68EC020 at 14 MHz, and the A4000 was available with either a 68EC030 or a 68040 at 25 MHz.
All in all, the AGA update was too little, too late. Since the Amiga’s hardware was still planar and 2d-oriented, it was not very suitable for the new trend in gaming: 3d first-person-shooters, such as Wolfenstein 3d. The Amiga was good at flatshaded polygons with its blitter-fill, but for texture-mapped graphics, you wanted chunky pixels instead of bitplanes. The PC with its VGA card was more suited to the task.
On the Amiga, people started to render entirely with the CPU into a chunky buffer, then perform an additional pass over the display buffer to convert it to planar format (known as chunky2planar or c2p). This was quite CPU-intensive however (or actually chipram-intensive). Even with the fastest accelerators (68060 at 50+ MHz), you generally couldn’t get more than 25 fps, since the c2p conversion already took up about an entire frame of time. It also meant that the Amiga was no longer ‘special’: it basically rendered all graphics entirely with the CPU, much like you’d do on PCs with VGA. And by this time PCs had faster CPUs, faster memory, and faster data buses. For this reason, my interest in Amiga is mainly focused on OCS/ECS. Most accelerated AGA stuff is not very different from what I did on 486 with VGA: quite straightforward chunky software rendering.
That’s not to say I don’t like AGA/accelerated Amiga demos though. Some of my favourite demos and intros are accelerated AGA. Loonies’ Impossible for example:
If you are interested in programming AGA, it is a bit difficult to find good documentation on the new hardware. Commodore was already in the process of falling apart when the AGA machines were launched, and as far as I know, they have never published an official updated version of the Amiga Hardware Reference Manual with the new AGA information (I have been told that Commodore did not want programmers to access the hardware directly, but go through the OS and its libraries instead). The best AGA reference appears to be the AGAGuide on Aminet, which can be seen as an addendum to the regular Hardware Reference Manual. Kalms has written a very fast and popular set of c2p routines, which can be found here. He has also written a nice tutorial on optimizing c2p conversions (essentially a giant transpose operation, performed in several steps).
Well, there we have it, I think the Amiga is covered now.