Original Amiga chipset
From Free net encyclopedia
Sendmoreinfo (Talk | contribs)
/* Technical Explanation */ correct wikilink
Next diff →
Current revision
The Original Chip Set (OCS) is a chipset used in the earliest Commodore Amiga computers. It was succeeded 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 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.
Agnus
The central aspect of the chipset's power is 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 lowres (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.
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.
Technical Explanation
- 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'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.
Copper
The copper—short for "co-processor"—is a programmable finite state machine. It is a relatively simple chip that executes a programmed instruction stream, closely linked to the video hardware.
This programmability allows for numerous display tricks.
- "Re-use" of sprites: The Amiga's hardware engine supports only 8 sprites, but with copper support, can present the illusion of many more. Each sprite is draw in a certain position, until the raster beam has passed it; the copper can then instantly change its location and appearance, moving it below the raster beam again. A single hardware sprite 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 in-chipset.
- Change display resolutions and color palettes on the fly: one of the Amiga's most unusual features — the computer can change resolution between scan lines, allowing for different horizontal resolutions to be displayed on the same screen. This is somewhat similar to the ability of Windows 95 and later machines to alt-tab between full-screen programs, but on the Amiga, users simply drag the front screen down to see the one behind it.... both are visible simultaneously.
As technically fascinating as this is, the actual practical uses are limited. Paint programs use the 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. It can be used as a convenient way to watch the status of a full-screen program while doing something else in the foreground. It serves as an excellent demonstration of the machine's graphic progress. Beyond that, it is largely a curiosity.
Late in the Amiga's evolution, an advanced copper technique was invented: Sliced HAM, or S-HAM. This consists on writing a very dense copper list, which switches the palette on every line of a HAM display, removing most of that mode's color limitations. This is a large jump in image quality, but it requires nearly all the resources of an OCS machine simply to display an image. The fact that it can be done at all is a testament to the amazing power and flexibility of the chipset.
Common functions of the copper are:
- Set-up of the hardware registers that require re-initialization 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 color 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.
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.
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 Amiga 1000 sold in the United States did not have the EHB mode [1] .
- 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:
- 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 the intricacies of the copper co-processor.
- It was possible to redefine the 32 hardware colours many times during the screen draw, effectively producing many more colours than would normally be possible.
- One could have had screen split from the center into two or more different screen modes with different palettes or colour depth.
- 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.
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.
Video output
The video output of Denise is 12-bit digital RGB. Conversion to analog RGB is performed by external DACs. 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.
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. 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. At 7 kHz the filter dampens the volume by at least 15 dB. The filter can only be applied globally to all 4 channels, as hardware channels do not have separate filters. The brightness of the Amiga's 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. Models before the 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 filter with -3 dB point at roughly 10 kHz.
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.
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. It 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.
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).
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 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
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.