Original Amiga chipset
|
|
The Commodore Amiga Original Chip Set (OCS) is a chipset used in the earliest Amiga computers, from the 1985 Amiga 1000 onwards. It was succeded by the modestly improved Enhanced Chip Set (ECS) and greatly improved Advanced Graphics Architecture (AGA).
The original chipset appeared in the Amiga 1000, Amiga 2000 and Amiga 500.
| Contents |
Overview of chips
The chipset which gave the Amiga its unique graphics features consisted of three main custom chips, Agnus, Denise, and Paula. The NMOS chips were manufactured by Commodore's own fab, MOS Technology. All three were originally packaged in 48-pin DIPs; later versions of Agnus, known as Fat Agnus, were packaged in an 84-pin PLCC.
- Agnus – the central chip in the design. It controlled all access to CHIP RAM from both CPU and other chips, using a complicated priority system. It also included the blitter and the copper. The original Agnus could address 512KB of CHIP RAM. A later revision of the chip, Fat Agnus, could address 1MB of CHIP RAM.
- Denise – the main video processor. Without using overscan, the display was 320 (lowres) or 640 (hires) pixels wide by 200 (NTSC) or 256 (PAL) tall. It also supported interlacing which doubled the vertical resolution. Anything between 2 and 32 colours (1 to 5 bitplanes) was supported. A 6th bitplane was available for either the Halfbright mode that added a copy of the first 32 colours but with half the intensity or Hold And Modify mode which allowed access to all 4096 colours at once. Denise also supported eight sprites, quarter-pixel smooth scrolling and "dual playfield".
- Paula – primarily the sound chip; 4 independent hardware mixed 8-bit PCM sound channels with 65 volume levels and any sample rate from roughly 20Hz to 29kHz. Paula also handled interrupts and various I/O functions including mouse, floppy disk drive, and serial port.
Agnus
The central aspect of the chipset's power is that all operations are synchronised with the output of video beam. This includes access to the built-in RAM, which is known as "CHIP RAM" because only the chipset has direct access to it. The CPU and other members of the chipset have to arbitrate for access with Agnus. From the perspective of system architecture, this is known as Direct Memory Access (DMA), and Agnus is the DMA Controller (DMAC) in that respect.
Agnus has a complex priority-based memory access policy. Bitplane data fetches are more important than blitter transfers, for example. As the original 68000 in Amigas can only access memory on every second clock cycle, Agnus operates a system where the time-critical custom chips access get the "odd" cycle and the CPU gets the "even" cycle, thus the CPU does not get locked out of memory access and does not appear to slow down. However, non-time-critical custom chip access, such as blitter transfers, can use up any unused odd or even cycles and, if the "BLITHOG" (blitter hog) flag is set, Agnus will lock out the even cycles from the CPU in deference to the blitter.
Agnus's timings were measured in "colour clocks" of 280ns. This is equivalent to two lowres (140ns) pixels or four hires (70ns) pixels. Like Denise, these timings were designed for display on household TVs, and can be synchronised to an external clock source.
Blitter
The blitter—"blit" is shorthand for "block image transfer" (or bit blit). The Blitter is a highly parallel memory transfer and logic operation unit. It has three modes of operation: copying blocks of memory, filling blocks (e.g. polygon filling) and line drawing.
Block copying mode takes zero to three data sources in memory (A, B and C), and writes to a destination area (D). Any of these areas can overlap. All blocks are on 16-bit (two byte) boundaries. The blitter either runs from the start of the block to the end, known as "ascending" mode, or in reverse, "descending" mode. Blocks are "rectangular"; they have a "width" in 16-bit words (not pixels), a height measured in "lines", and a "stride" distance to move from the end of one line to the next. This allows the blitter to operate on any conceivable video resolution. The copy automatically performs a per-pixel logical operation. These operations are described generically using minterms. This is most commonly used to do direct copies (D = A), or apply a pixel mask around blitted objects (D = A AND C). The copy can also barrel shift each line by 0 to 15 pixels. This allows the blitter to draw at pixel offsets that are not exactly multiples of 16.
The line mode draws single-pixel thick lines using the Bresenham line drawing algorithm. It can also apply a 16-bit repeating pattern to the line. The filling mode is used to fill per-line horizontal spans. On each span, it reads each pixel in turn from left to right. Whenever it reads a set pixel, it toggles filling mode on or off. When filling mode is on, it sets every pixel until filling mode is turned off or the line ends. Together, these modes allow the blitter to draw individual flat-shaded polygons, albeit very slowly in comparison to modern 3D graphics chipsets.
Copper
The copper—short for "co-processor"—is a programmable finite state machine. When it is turned on, it has three states; either reading an instruction, executing it, or waiting for a specific video beam position. The copper runs a program called the copper list in parallel with the main CPU. The copper runs in sync with the video beam, and it can be used to perform various operations in sync to the video beam. Most commonly it is used to control video output, but it can write to any of the chipset registers and thus can be used to set audio registers or interrupt the CPU.
The copper list has 3 kinds of instructions, each one being a pair of two bytes, four bytes in total:
- The MOVE instruction writes a 16-bit value into one of the chipset's hardware registers.
- The WAIT instruction halts copper execution until a given beam position is reached, thus making possible to synchronize other instructions with respect to screen drawing. It can also wait for a blitter operation to finish.
- The SKIP instruction will skip the following copper instruction if a given beam position has already been reached. This can be used to create copper list loops.
The length of the copper list program is limited by execution time. The copper restarts executing the copper list at the start of each new video frame. There is no explicit "end" instruction, instead the WAIT instruction is used to wait for a location which is never reached.
Common functions of the copper are:
- Set-up of the hardware registers that require re-initialisation on each frame.
- Split the screen in multiple regions, each having separate overall position, palette and in some cases different graphics resolution. Most notably the AmigaOS uses this extensively for its screen-dragging capabilities.
- Showing only part of the screen in vertical direction.
- Changing a colour register once per scanline, creating the "raster bars" effect seen commonly in Amiga games.
- Changing other hardware registers once per scanline, for example the bitplane pointers. This can be exploited to give a number of pleasing graphical effects, usually seen in demos rather than games.
Less common functions of the copper are:
- Driving hardware sprites with MOVE and WAIT instructions. This includes re-using sprites more than once on the same scanline, by repositioning them in mid-scan after they have already been drawn.
- Driving blitter operations directly.
- Emulating a 12-bit true color mode by changing the background colour register in sync with screen drawing. This requires no actual bitplane graphics to be displayed at all!
- Trigger CPU interrupts to synchronize CPU on hw screen drawing.
Denise
Denise controls the video timings, but can also synchronise to an external video signal. Denise is programmed to fetch planar video data from 1 to 5 bitplanes and translate that into a colour lookup. The number of bitplanes is arbitrary, thus if 32 colours are not needed, 2, 4, 8 or 16 can be used instead. The number of bitplanes (and resolution) can be changed on the fly by the copper. This allows for very economical use of CHIP RAM. There is also a sixth bitplane, which can be used in special modes:
- Extra-HalfBrite (EHB) – if a pixel is set on the sixth bitplane, the brightness of the regular 32 colour pixel is halved. Early versions of the version of the A1000 sold in the United States did not have the EHB mode [1] (http://www.old-computers.com/museum/computer.asp?st=1&c=28) .
- Hold and Modify (HAM) – each 6-bit pixel is interpreted as 2 control bits and 4 data bits. The 4 possible permutations of control bits are "set", "modify red", "modify green" and "modify blue". With "set", the 4 data bits act like a regular 16-colour display look up. With one of the "modify"s, the red, green or blue component of the previous pixel is modified to the data value, and the other two components are retained from the previous pixel. This allows all 4096 colours on screen at once.
- Dual playfield – instead of acting as a single screen, two "playfields" of 8 colours each (3 bitplanes each) are drawn on top of each other. They are independently scrollable and the background colour of the top playfield "shines through" to the underlying playfield.
There are two horizontal graphics resolutions, "lowres" with 140ns pixels and "hires" with 70ns pixels. This makes the display 320 or 640 pixels wide without using overscan. Denise supports very wide overscan; there is no need for a border around the graphics as other computers suffered from. Vertical resolution, without overscan, is 200 pixels for an 60Hz NTSC Amiga or 256 for a 50Hz PAL Amiga. This can be doubled using an interlaced display.
Denise can also lay sprites on top of the graphics, and detect collisions between sprites and the background, or between sprites.
Other features of Denise:
- framebuffers operated in planar bitfield modes.
- framebuffers were often linear, but not limited to that.
- hardware graphics potential is very hard to explain briefly since it is pretty complicated due to copper co-processor.
- It was possible to use redefine the 32 hardware colours many times during the screen draw, effectively getting many more colours.
- One could have had screen split from center to two or more different screen modes with different palettes/depth).
- 8 separate hardware sprites (used for mouse pointer for example) with 16 pixel width and arbitrary height with 3 colours (plus a fourth transparent "color"). Two sprites could be attached to make a single 15-color sprite.
- The sprite hardware was designed to allow the sprites to be re-used on different lines, allowing many more sprites on screen as long as no more than 8 appear on each scan line.
- Although not an officially supported feature, the copper could be used to change sprite registers in the middle of a line to allow more sprites per line, a trick which was used by some games such as Battle Squadron.
- It is possible to simulate having arbitrary-width sprites by placing 16 pixel wide sprites next to each other, up to a maximum of 128 pixels wide for 3-color sprites, and 64 pixels for 15-color sprites, by laying each sprite adjacent to each other. The wider the "meta-sprite," however, the fewer other sprites could be displayed on a single scanline.
External video timing
Under normal circumstances, the Amiga generates its own video timings, but the chipset also supports synchronising itself to an external signal from the RGB monitor connector so as to achieve genlocking with external video. There is also an 1 bit output on this connector that indicates whether the Amiga is outputting background colour or not, permitting easy overlaying of Amiga video onto external video. This made the Amiga particularly attractive as a character generator for titling videos and broadcast work, as it avoided the use and expense of AB roll and chromakey units that would be required without the genlock support. The support of overscan, interlacing and genlocking capabilities, and the fact that the display timing was very close to broadcast standards (NTSC or PAL), made the Amiga the first ideal computer for video purposes, and indeed, it was used in many studios for digitizing video data (sometimes called frame-grabbing), subtitling and interactive video news.
Paula
Audio Features in General
Paula the sound chip has 4 DMA driven 8-bit PCM sample channels. Two DMA channels are mixed into the left audio output, and the other two are mixed into the right output. Hardware mixing means multiplying each channel by its volume register value and adding the two PCM channels together. The only supported hardware sample format is linear 8-bit two's complement.
Audio hardware assisted instrument playback can go up to approximately 28867 Hz sampling rate. Audio hardware functionality is closely related to video hardware timing, and as a result it is possible to double the maximum sampling rate on ECS/AGA machines by choosing a suitable video mode. CPU driven audio output is also possible, and it is not limited to sampling rate 28867 Hz or any video mode timing, but it consumes CPU time proportionally to the sampling rate.
Additionally the hardware allows the other channel in a channel pair to modulate the other channel's period or amplitude. It is rarely used on Amiga, but could be used to achieve tremolo and vibrato like effects.
The hardware has an analog low-pass filter whose exact characteristics are unknown. At 7kHz the filter dampens the volume by at least 15 dB. The filter can be enabled for all channels, or disabled for all channels. Hardware channels do not have separate filters.
Paula features as Bullets
- 4 channel hardware DMA driven stereo output with linear 8-bit PCM samples in two's complement format
- maximum sampling rate for instrument playabck is approximately 28867 Hz
- each channel has a 6-bit volume register
- separate volume, period (frequency) for each of the 4 DMA channels
- sound dynamics of 8-bits == 48.165 dB
- can output frequencies up to 1.7MHz but only with 2 sample instruments (not possible to have tones for instruments in this case)
- possible to emulate 14-bit sounds with hardware DMA by playing 2 channels with the other playing most significant 8 bits at maximum volume while the other plays the least significant 6 bits at minimum volume.
Hardware registers
Each channel has a set of hardware registers. The registers are audxlch, audxlen, audxper, audxvol and audxdat, where x is the channel number from 0 to 3. In addition there is adkcon register which controls period and amplitude modulation of channels.
audxlch is the pointer into beginning of sample data in memory from which the DMA will start playback. Playback has length of 2*audxlen samples.
audxper specifies the amount of sound chip cycles (operating at half the A500 CPU frequency depending on NTSC and PAL) to wait before loading a new sample value into audio output, and hence this specifies the sampling rate for instrument playback. It the audxper register value is too low the audio hardware can't keep up to date providing sample data by DMA, and as a result the maximum DMA sampling rate is approximately 28867 Hz.
auxvol register contains the volume in range 0-64. The volume value is a multiplier for PCM samples.
audxdat register is a write-only register for doing sample playback with the CPU. CPU can write sample data into the register directly. Theoretically this allows very high sampling rates, but it consumes CPU time directly proportional to the sampling rate.
Audio State Machines
Internally the audio hardware is implemented by 4 state machines each having 8 different states. The state machines operate on half the A500 CPU frequency. Amiga Hardware Reference Manual contains the state machine description in detail. The state machine allows two methods for instrument playback regardless if DMA is used or not. Interrupt driven playback is CPU time efficient but non-trivial. CPU polling driven playback is simple but consumes more CPU time. In demos and games both methods are commonly used. For example, the original Protracker replay routine waits DMA (state machine transitions) with a CPU poll loop, but many demos use an optimized interrupt driven player system (such as The Player 6.0).
Floppy disk controller
The floppy controller is unusually flexible. It can read and write raw MFM or GCR data in any format via DMA or programmed I/O. It also provides a number of convenient features, such as sync-on-word (in MFM coding, $4489 is usually used as the sync word). MFM encoding/decoding is usually done with the blitter. Normally the entire track is read or written in one shot, rather than sector-by-sector.
In addition to the native 880K 3.5-inch disk format, the controller can handle many foreign formats, such as:
- IBM PC
- Apple II
- Mac 800K (requires a Mac drive)
- Commodore 1541 (requires slowing drive to 280RPM)
Serial port
The serial port is rudimentary: programmed I/O only and lacking a FIFO buffer. It does have one positive attribute, which is that virtually any bit rate can be selected, including all the standard rates, MIDI rate, as well as extremely high custom rates.
References
- Miner, Jay et al (1991). Amiga Hardware Reference Manual: Third Edition. Addison-Wesley Publishing Company, Inc. ISBN 0-201-56776-8.
External links
- US Patent #4,777,621 Video game and personal computer (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=4777621.WKU.&OS=PN/4777621&RS=PN/4777621)fr:Original Amiga chipset