Original Amiga chipset
From Wikipedia, the free encyclopedia
The Original Chip Set (OCS) was a chipset used in the earliest Commodore Amiga computers. It was succeeded by the slightly 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 |
[edit] Overview of chips
The chipset which gave the Amiga its unique graphics features consisted of three main custom chips, Agnus, Denise, and Paula. The OCS (and ECS) chipset was manufactured using NMOS technology by Commodore's chip manufacturing subsidiary, 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 and Fat Agnus could address 512 KiB of chip RAM. Later revisions of Fat Agnus could address 1 MiB 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 unique colors (1 to 5 bitplanes) from a 12 bit (4096 color) palette, was supported. A 6th bitplane was available for either the Halfbrite mode that added a copy of the first 32 colors but with half the intensity or Hold And Modify mode which allowed access to all 4096 colors at once. Denise supported eight sprites, smooth scrolling, and "dual playfield". Denise also handles mouse and digital joystick inputs.
- Paula – primarily a sound chip, with 4 independent hardware mixed 8-bit PCM sound channels with 65 volume levels and any sample rate from roughly 20 Hz to 29 kHz. Paula also handled interrupts and various I/O functions including floppy disk drive, serial port, and analog joystick.
[edit] Agnus
The Agnus chip is the central aspect of the chipset's power in that all operations are synchronised with the output of the video beam. This includes access to the built-in RAM, which is known as chip RAM because the chipset has 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 280 ns. This is equivalent to two low-res (140 ns) pixels or four hi-res (70 ns) pixels. Like Denise, these timings were designed for display on household TVs, and can be synchronised to an external clock source.
[edit] 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.
This allows the rapid copying of video memory, meaning that the CPU can be freed for other tasks. This was the beginning of modern-day graphics implementations, where dedicated GPUs (graphics processing units) operate independently of, but under instruction from, the CPU. The blitter therefore allowed a programmer to create bobs (blitter objects) that are controlled by subroutines under interrupt control. The main thread of the program is not used to perform the actual redrawing of the screen.
The blitter has never been improved to be able to rotate or zoom bobs, or to apply textures to polygons. When these graphics techniques became commonplace (such as with the release of the SNES and Voodoo/ATI Rage-class graphics accelerators), the Amiga chipset dated rapidly.
[edit] Technical Explanation
- Block copying mode takes zero to three data sources in memory (A, B and C), performs a rasterop on the sources, and then 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's line 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 or the CPU of a moderately fast Amiga. The line mode can also be used to rotate bobs: the image data of the bob is used as line pattern while the algorithm scans the bob position line by line.
[edit] Copper
The copper—short for "co-processor"—is a programmable finite state machine that executes a programmed instruction stream, synchronized with the video hardware.
This programmability allows more control over the hardware, allows for work to be offloaded to the copper that would otherwise consume CPU time, and also allows for several trademark video tricks
Common functions of the copper are:
- Set-up of the hardware registers each frame. (The video display must be re-initialised each frame).
- Changing a colour register (particularly the background) 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 blitter operations directly.
- Emulating a 12-bit true color mode by changing the background color register in sync with screen drawing. This requires no actual bitplane graphics to be displayed at all!
- Trigger CPU interrupts to synchronize CPU with hardware screen drawing.
Common video 'tricks' used by the Amiga include:
- "Re-use" of sprites: The Amiga's hardware supports only 8 sprites, but clever use of the copper can present the illusion of many more. After a sprite has been drawn, the copper can instantly change its location and appearance, moving it below the current raster beam. A single hardware sprite function can thus serve as several visible objects on screen. It requires CPU time to set up the copper lists, but actually moving the sprites is handled entirely by the chipset.
- Changing the video configuration on the fly: one of the Amiga's most unusual features, and a feature that is impossible with modern PC hardware — the computer can change video configuration, including resolution between scan lines, allowing for different horizontal resolutions and color depths to be displayed on the same monitor. The AmigaOS desktop allows two programs to operate at different resolutions, while both are visible on the screen simultaneously. A paint program might use this feature to allow users to draw directly on a (low-resolution) HAM screen, while offering a high-res, detailed toolbar at the top or bottom of the screen.
- Sliced HAM, or S-HAM. Invented in 1989 by Rhett Anderson[1], this consists of building a copper list that switches the palette between every line of the display, vastly improving the range of colours available onscreen. While all 4096 colours may be used by a HAM display, their use is limited.
[edit] Technical Explanation
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 which require video synchronization. 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 three 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.
[edit] 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, usually by the copper. This allows for very economical use of 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 Amiga 1000 sold in the United States did not have the EHB mode [2] .
- 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 140 ns pixels and "hires" with 70 ns 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 60 Hz NTSC Amiga or 256 for a 50 Hz 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:
- The number of bytes that should be skipped between scanlines was configurable. This allowed for "interleaved" bitmaps, which were simpler to blit to.
- 8 separate hardware sprites (used for the mouse pointer, for example) with 16 pixel width and arbitrary height with 3 colours (plus a fourth transparent "colour"). 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.
[edit] 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 hardware. 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.
[edit] Video output
The video output of Denise is 12-bit digital RGB. Conversion to analog RGB is performed by an external DAC ('Vidiot'). On the Amiga 2000, the digital RGB is available at a special video slot. Internally the display is limited to 6 bits per pixel (using planar representation) and 32 color registers for palette. This allows the Amiga to use the common colour lookup-table based color mode, ExtraHalfBrite color mode (often used by Amiga games) and Hold And Modify color mode (useful for displaying static images).
The chipset shares Chip RAM with the CPU. Accordingly, if the CPU attempts to access Chip RAM at any time, it may be blocked by the chipset. One consequence of this is that the CPU's performance reduces measurably if the custom chips are used heavily (such as in overscan mode). Some programs would disable the display to gain performance, such as during 3D raytracing calculations.
[edit] Paula
[edit] 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. With some special programming "tricks" it was possible to produce 14bit audio by combining two channels on different volume so you can in fact have "two" 14bit channels instead of four 8bit channels.
Audio hardware assisted instrument playback can go up to approximately 28867 Hz sampling rate. Each channel is a separate DAC with its own sample 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 Amiga contains an analog low-pass filter (reconstruction filter) which is external to Paula. The filter is a 12 dB/oct Butterworth low-pass filter at approximately 3.3 kHz. The filter can only be applied globally to all 4 channels, as hardware channels do not have separate filters. In models after the Amiga 1000, the brightness of the power LED is used to indicate the status of the filter. The filter is active when the LED is at normal brightness, and deactivated when dimmed (on early Amiga 500 models the LED went completely off). Models released before Amiga 1200 also have a static "tone knob" type lowpass filter that is enabled regardless of the optional "LED filter". This filter is a 6 dB/oct lowpass filter with cutoff frequency at 5 kHz (some circuit diagrams indicate cutoff frequency at 4.5 kHz, though).
[edit] Feature overview
- 4 channel hardware DMA driven stereo output with linear 8-bit PCM samples in two's complement format
- maximum sampling rate for instrument playback is approximately 28867 Hz
- each channel has a 6-bit volume register
- separate volume, period (frequency) for each of the four DMA channels
- sound dynamic range is 8 bits (= 48.165 dB), but volume adjustment can be used to set level without reducing the dynamic range
- can output frequencies up to 1.7 MHz but only with two sample instruments (not possible to have complicated tones for instruments in this case)
- possible to loosely emulate 14-bit sounds (= 84.288 dB) with hardware DMA by playing two channels with the other playing most significant 8 bits at maximum volume while the other plays the least significant 6 bits at minimum volume.
[edit] 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 of the A500 system clock, approximately 3.54 MHz for PAL and 3.57 MHz for NTSC) to wait before loading a new sample value into audio output, and hence this specifies the sampling rate for instrument playback. If the audxper register value is too low the audio hardware cannot keep up to date providing sample data by DMA, and will repeat the previous two samples in those circumstances, distorting the sound playback. The maximum distortionless DMA sampling rate is approximately 28867 Hz.
auxvol register contains the volume in range 0-64 (silence plus 64 volume levels). 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. Some players used copper to program the audio chip and generated sample data into the Copper instruction stream.
[edit] Audio state machines
Internally the audio hardware is implemented by four state machines each having eight 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).
[edit] 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 — one pass for decode, three passes for encode. Normally the entire track is read or written in one shot, rather than sector-by-sector.
In addition to the native 880 KiB 3.5-inch disk format, the controller can handle many foreign formats, such as:
- IBM PC
- Apple II
- Mac 800 kB (requires a Mac drive)
- AMAX Mac emulator (A special floppy of only 200 kB to exchange data between Amiga and Macintosh could be formatted by Amiga, and it could be read and written by floppy drivers of both systems)
- Commodore 1541 (requires 5.25 inch drive slowed to 280 rpm)
- Commodore 1581 formatted 3.5" floppy for C64 and C128
[edit] 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.
[edit] Trivia
The name Agnus is derived from 'Address GeNerator UnitS' since it houses all address registers and controls memory access of the custom chips.
Paula was named after the girlfriend of the chip designer.
[edit] See also
[edit] References
- Miner, Jay et al (1991). Amiga Hardware Reference Manual: Third Edition. Addison-Wesley Publishing Company, Inc. ISBN 0-201-56776-8.
