The Fred Fish Collection 1.5/ffcollection-1-5-1992-11.iso/ff_disks/700-799/ff732.lha/pstools/Graphics.txt

Text File | 1992-09-26 | 33KB | 723 lines

V0.15


            GRAPHICS OVERVIEW

Scanner - Device for inputting images from photographs newspapers ect.

Character scanner - Device for reading text and converting it to
askii without having to retype it.

Digitizer - Device which takes video and turns it into computer
compatable data ie framegrabber, note some devices can input there
data straight into Art Department Professional.

RGB Spliter - Device which takes the output from a colour camera
and splits it into red green blue signals for input to a digitiser.
If you with to obtain colour from a black and white camera red green
and blue filers are used to split the image instead.

Genlock - Everyone knows that a genlock overlays computer graphics
onto an external video source, but how does it actually work?
Well, believe it or not, the actual process of overlaying or keying
as it should be called is actually a very minor function of the genlock.
   Genlocks carry out three basic functions, they code, genlock and key
video siganls. Coding is a process whereby the RGB output from
the amiga is converted into either PAL composite or Super VHS format,
depending on your individual requirements. If all you want to do is to
record the output from the amiga onto videotape, then a coder is all that
you will need. However for true desktop video, the genlock's second
and third functions come into their own.
   Genlocking itself is not the process which allows a computer's graphics
to be superimposed onto video. Infact, genlocking is the process where two
separate video signals are synchronised internally at sync pulse level,
bringing them in time with each other. Without this all important process,
it would be impossible to combine the two signals. Keying is a process
whereby the video image completely replaces certain parts of the computer
image.
The genlock doesn't look for a certain colour when keying the signal,
you could have two identical blacks in the signal with only one being
keyed, for example. Instead, keying works at colour register level.
Most genlocks allow only colour register zero to be used as the key
colour, but more professional units allow you to change this.

Multisync - Televisions and normal monitors operate on a fixed frequency.
The frequency is described in two components: the verticla frequency,
which is the number of frames displayed per second, and the horizontal
frequency, which is the number of horizontal lines displayed per
second.
   Standard PAL televisions have a vertical frequency of 50hz and a
horizontal frequency of around 15.6khz. The amiga output is identical
to this, to allow the amiga to display all video modes on the same monitor
unlike the atari st. With these fixed values, the number of lines that
can be displayed in one frame is limited to around 300.
   A multisync monitor can accept a wide range of vertical and horizontal
frequencies, typically 50 hz to 70 hz vertical and 15.5khz to 35khz
horizontal frequency, we can get all 512 lines of our hi-res display
in one frame, resulting in no flicker. De-interlacer cards work by
providing an output at these frequencies that the multisync can display.

Resolution - This is the smallest detail which can be seen. On IBM's
the graphics cards are options, they are CGA low definition, EGA medium
definition, VGA high definition, and supervga. The amiga has many
resolution modes

AMIGA:-

320 * 200 pixels with 32/64 colours (lo-res) (or 4096 colours in HAM)
320 * 400 pixels with 32/64 coloures (med-res)
640 * 200 pixels with 16 colours (hi-res)
640 * 400 pixels with 16 colours
720 * 480 overscan
640 * 256 pixels with 16 colours (hi-res)
640 * 512 pixels with 16 colours (hi-resint)
1280 * 256 pixels with 4 colours (super hi-res)
1280 * 512 pixels with 4 colours (supr hi-resint)
640 * 480 pixels with 4 colours (productivity)
640 * 960 pixels with 4 colours (product-interlaced)
1008 * 800 pixels with 4 grayscales (A2024_10hz)
1008 * 800 pixels with 4 grayscales (A2024_15hz)
???? * ???? pixels with 16700000colours (24bit)

IBM:-

Hercules            black and white
MDA monocrome display adapter
CGA colour graphics adapter
EGA enhanced graphics adapter   640 * 350 16 colours
VGA very good adapter        640 * 480    16 colours
ProVGA                800 * 600    16 colours
SVGA super very good        1024 * 768    256 colours

UNIX 1280 * 1024 65536 colours

   Persistance - Is the amount of time it takes for an image to disappear.
Again there are three levels short medium and long.

   PAL - Again three types, this time its the colour decoding system.
Pal (phase alternate line), is used in northern europe and australia.
NTSC in America and Japan and SECAM in southern europe and Russia.
MAC is a new system which may one day replace the rest.

   Phosper - This is one dot on the screen (screen resolution). A pixel
is the smallest spot which the system can display (graphics resolution).

   WIMP - Menu driven displays: these consist of menus which may be
31 across 63 down and have 31 subitems, they can be manually programmed
or semiautomatically with powerwindows. Gadgets are part of this system,
there are three types; boolian, which are like on/off switches,
proportional which are sliders or knobs like volume controls, and
string which require the user to enter text or figures.
See a programming manual for more information. Graphics can be imported
into menus and gadgets.

   IFF (interchange file format) Locked to 75 dpi The idea is for any file
from any program to be loaded into any other. There are standards for text,
sound and graphics, the graphics can be low medium or high resolution
to accomodate the three types of monitor. Each iff file consists of
a header which retains all the information that informs the program of
data found in its file as well as type of data. It will also have chunks.
Chunks are blocks of data that contain groups of data. For example, an
iff file containing music data has a chunk outlining the parameters of
each musical voice's sound capabilities. A graphic iff file has a colour
chunk in which it stores all the colour data needed for the graphic.
Chunks provide the developer with a system of data building blocks.

   EPS Encapsulated postscript file. This is a picture file in text
used to transport graphics from one platform to another, object or raster.

   PICT AppleMac B & W picture file vector type (object).

   PICT2 AppleMac colour picture file vector type

PIC File Format:
The PIC format will support bits per pixels of 1, 4 and 8.

MAC file Format:
The MAC format supports only 1 bit per pixel, at a resolution of 72 dpi.
MAC files come from the Macintosh program MacPaint.
Mac pictures are very specific. They must have a width of 576 and a height
of 720, and are black and white. Mac pictures should have a white background.
Since Macintoshes were originally only black and white there is a large
selection of clipart that is saved in the MAC file format.

   CGM Computer graphic metafile vector graphic type

   GEM vector graphic type

   IMG bitmap image type Digital Research Image File
The IMG format will support bits per pixels of 1, 4 and 8.
IMG files were designed to work with the GEM environment. The files were
originally the result of GEM Paint. Since the application Ventura Publisher
worked in the GEM environment, it too supported the IMG file format.
In order to maintain compatibility, various other desktop publishing
applications have added support for the importing and exporting of this format.
There are 2 types of IMG files: "Old-style" and "New-style".

   SCITEX Separate CMYK components file

   WMF MSDOS Windows metafile vector graphic tupe

BMP File Format:

The BMP format will support bits per pixels of 1, 4, 8 and 24.
The BMP files come in 2 different formats. These formats will be referred to
as Windows and OS2, these files tend to be very large.
OS2 BMPs were the first of the two different formats designed. The pictures
that are saved using this format may be used with the OS2's Presentation
Manager. An enhanced BMP file format was released with Microsoft Windows.
This is the reason for the reference to Windows and OS2 BMP formats.
BMP files can be used as "wallpaper" for the background when running in Windows. See your Windows documentation on how to use a BMP file as wallpaper.
Within the Windows BMP format, two different types of encoding can be used.
These are RGB and RLE. The OS2 format only supports one type of encoding, RGB.
Files that use the RGB encoding scheme have no compression done. The data that
makes up the picture is simply saved to a file. This makes for some very large
BMP files.
The RLE (run length encoding) scheme does some compression of the data that
makes up the picture. The RLE encoding is further broken down into 2
different formats; RLE4 and RLE8. RLE4 is the RLE compression routine used for
picture data of 16 or less colors. RLE8 is the compression routine that is
use for pictures of 17 to 256 colors.



   JPEG Joint Photographic Experts Group compression standard, compresses
graphics upto 90 percent reduction but looses data on the first compression

   RENDITION Format created by Numerical Designs. A 24bit 3D rendering
language.

   SUNRASTER 1 8 24 and 32 bit writen by Sun Microsystems.


   TIFF Tag Interchange File Format 24bit, 256 colour, grey scale
The TIFF format will support bits per pixels of 1, 4, 8 and 24.
The TIFF format was designed to become the standard format.
In order to become the standard, the format was designed to handle just
about any possibility. The result of this design was maximum flexibility in
how a picture is saved. This results in an infinite number of possibilities
of how a picture is saved. The best that an application can do is to
support as many TIFFs as possible, but there will always be the an obscure
TIFF that will cause a problem for some applications.
The TIFF format differentiates between types of pictures. These categories
are: black and white, greyscaled and colored.
The TIFF format can use one of six encoding routines. These encoding
routines are: No-compression, Pack bits, LZW, Huffman, CITT 3 and CITT 4.

   GIF Compuserve colour map bitmap graphic
The GIF format will support bits per pixels of 1, 4 and 8.
GIF files were designed to create the smallest possible picture files for
uploading and downloading from BBSs. There are 2 GIF file versions; 87a
and 89a. Version 87a was the first of the two versions to appear. Version
89a added new features to the 87a format. Both of these versions may use
an encoding method referred to as interlacing.
Interlacing is when a picture is saved by using four passes instead of just
one. On each pass certain lines of the picture are saved to the file.
If the program decoding a GIF file displays the picture as it is decoded,
the user will be able to see the four passes of the decoding cycle.
This will allow the user to get a good idea of what the picture will look
like before even half of the picture is decoded. Some communication programs
allow the user to download GIF files and view them as they are downloaded.
If the picture is interlaced, the user will be able to decide if the picture
is one they like before half of the download is complete. If the user does
not like the picture, the download can be aborted. This results in the
saving of time and money for the person downloading the picture.
NOTE: Some GIF files contain more than one picture.

   TARGA by True Vision Tarag 16 format contain 5bit per primary colour,
and in Targa 32 contain 8 bit per primary colour. Files may be compressed.

  PCX Bitmap graphic 256 colours PC Paintbrush (very large files)
The PCX format will support bits per pixels of 1, 4 and 8. PCX files were
originally created for use with the Zsoft Paintbrush program. With no
standard to the industry the format became the standard by default.
This format is supported by more applications than any other format.
There are 4 PCX file versions:
Version 0 - Black and white pictures.
Version 2 - 16 or less colors with palette information.
Version 3 - 16 or less colors without palette information.
Version 5 - 256 or less colors.

   Coreldraw vector graphic

   Expertdraw vector graphic

   Prodraw vector graphic There can be more than one picture in a file

   TNY Atari bitmap file

WPG File Format:
The WPG format will support bits per pixels of 1 through 8.
The WPG format is the format used by Word Perfect. It showed up with the
release of Word Perfect 5.0. With the release of version 5.1 the format
was changed. A WPG file may contain a picture made up of vector data or
raster data.

   Degras Atari bitmap file

   Neocrome Atari bitmap file

   X11 Defied by X windowing system 1bit ( window dump & bitmap) 4 8 16
24 or 32 bits (window/z pixmap only).

Note it is normal for hi definition multi colour file to be huge
50 mbyts is not uncommon. These files are transported by removable
hard drives, multi media drives, and streamer tapes. Also by
network/modem transfers.

   Bitplanes
A screens depth means how many bits are used for every pixel. The more
bits the more combinations/colours.
depth   number of colours     colour register number
1             2                     0 - 1
2             4                     0 - 3
3             8                     0 - 7
4         16                     0 - 15
5            32                     0 - 31 (only low res)
A low resolution screen may even have a depth of 6 if using some
special display modes (ham / extra halfbright.
Each colour may be picked out of a 4096 colour palette.
8             256

24 bit - 24 bits for each pixel allows for 16,777,216 colours to be
displayed. So why stop at 24 bits: well if you were to take a camera and
point it at the countryside, to represent that you wouldn't need 24
bits of colour. There are probably only about 300,000 colours there, so
you could easily do it in 18 bits. If on the other hand, you do a close-up of
a human face, you've got many, many subtle gradations, all shades of the
same basic colour. If you want to represent all the different shades of
a single colour you'll need eight bits, 256 different shades. Now,
because each colour on a computer screen is made up of three primary
colours - red, green, blue - to make sure you have those 256 shades of
each possible colour you need three times eight bits, which gives you 24
bits.
   So in effect, if you have 24-bit colour you are scientifically
assured of being able to represent every colour or shade of colour
the human eye can perceive.

   Bitmap (or raster)
At some time and in some place, our graphic must be entered into memory.
The bit-map controls both when and where this will occur. Then this info
is divided among different bit-planes. The mumber of bit-planes sets
how many colours are located in the viewport and displayed by the bit-
map. The more bit-planes there are, the more colours. The actual number
of colours is calculated below:
   number_of_colours=2^number_of_bitplanes
The calculation is based on the way the planes are graphically layered on
top of each other in the display (in memory they are actually stored one
after another).
   Each pixel is represented by one bit in every bit-plane. The combination
of all set and unset bits of a pixel in all the bit-planes determines the
number of the colour register. The pixel is then displayed in that colour.

   Vectored (Compugraphic) Images (or object)
A vectored image is one which is built up of data, ie instead of 1st
pixel equals colour 234, first line of image is one cm in; one cm down;
start of bezier curve one radian. In other words its mathematical, the
advantage being that no matter how large or small you want the image
it can be redrawn perfectly with no jaggies. Prodraw can produce CG images.

   Rastport
Almost all the graphic output is processed through the rastport structure
because it contains the actual colour of the pixels, the drawing mode
ect.

   Viewport
This is where you determine the size of the creativity area, the display
mode and the available colours. All of this data is sent to the viewport.
This data is later used to create the copper list that the special copper
coprocessor will use to construct your screen. A viewport is in other words
an area of the screen one view port must be under another (2d plane on screen)
and leave a space of at least one scan line.

   Dual Playfield
By using the dual playfield mode, it is possible to display two bitmaps,
with up to three bit-planes each, in a single viewport, these are displayed
on top of each other.

   Interlace - This is used in video, an interlaced scan on your monitor
or TV is composed of 312 1/2 lines which start at the top left hand corner
and finish at the bottom dead center. The electron beam then goes to the
top dead center and fills in the spaces inbetween. one period of 312 1/2
lines is a field which happed 25 times a second (in europe 30 in USA)
and the second (making it 625 lines (525 in USA) both together are known
as a frame. The reason it does this is because the early crt's in the
1940 1950's had poor persistance and the picture faded if they didnt.
The info which separates the fields is called the equalisation pulse,
which is in the video sync pulse chain. Am still trying to find out
why they save it in interlace form. All you really nead to know is that
interlace increases the screens definition in the vertical direction but
on a normal monitor appears to flicker. You nead iether a high persistance
monitor or a flicker corrector. Note the amiga's different resolution modes
only operate in the horizontal direction, so a low-res normal picture has
half the detail as a hi-res interlace picture (both planes).

   Ham - (hold and modify)  this format allowes 4096 colours as in photon
paint.Hold and modify pixels take their colour from the pixel directly
to the left. To determine the new colour, two of the colour components
are used (hold) and a third colour component is modified (modify).

   Extra halfbright -
The Amiga display hardware automatically enters Extra-Half-Brite mode
whenever you select a 6 plane display (which must be low res due to the
hardware) and have NOT selected either Hold and Modify or Dual Playfield
mode.

The graphics kernel software further enforces the rule that you must set
the EXTRA_HALFBRITE flag in the ViewModes for the ViewPort (Screen in
Intution lingo) or it will automatically trim your screen down to 5 planes.
This is done both for backward compatability and to insure support in
future Amiga architectures.

Consider the playfield data bits for a given pixel.  The bits from the
first five planes form a color register selector for that pixel, allowing
you to choose among the 32 color registers in the Amiga.  The bit from the
sixth plane is interpreted as follows:

  0 -- Use the color in the selected color register just as specified.

  1 -- Take the color in the selected color register, shift each of its R,
G, and B components right one bit, and use the new color value thus formed.

The net result is as if you had 64 color registers where the colors in the
top 32 were "half-intensity" counterparts of the colors in the bottom 32!

Of course, that means there is a dependency between the choice of colors in
the 32 real registers and the resulting colors in the 32 psuedo-registers.
Nevertheless, I assert we have as much right to claim 64 colors on screen
as IBM has to claim 16 colors from a monitor that is physically capable of
producing only 8 colors at 2 intensities!  At least we can select our 32
colors out of a pallatte of 4096!

Note also that, since fractional color components have no meaning in the
hardware, there are several distinct real colors that produce the same
extra color.  For instance (in hex):

  888 --> 444,    988 --> 444,   898 --> 444,   999 --> 444,  etc.

Despite all this quibbling, with a little thought it's easy to see how you
can choose a set of 32 real colors to make sure all 64 real plus extra
colors are distinct.  And they are every-pixel-addressable!

Why have we kept this little jewel a secret?  No, it's not that we were
planning to lull the competition into complacency and then spring an
instant double of the Amiga's color capacity on them.

Not all Amiga 1000s have Extra Half Bright mode.  All Amiga 500s and 2000s
have it.

This revision of the Amiga chipset occurred after the Amiga Hardware manual
was written, so it is not discussed there.  Note that you can't hurt
anything by running such a program on an older machine -- the values in the
6th bit plane will simply be ignored.  Color printing of Extra Half Bright
mode should work on AmigaDOS 1.1 and 1.2.



   ILMB - (interleaved bitmap) As in d_paint; It consists of the form
which makes up a large part of an iff graphic file. This form combines
many chunks into a single file, and because all of the chunks belong
to one graphic file, they are packed. The form contains a
single item of information: the length of the data file and the data
type. Next comes the labeling of the ilbm format. The file length then
the four letters ilbm indicate the particular format. The individual
chunks of the data file follow.
   BMHD (bitmapheader) this chunk contains the data
that cover the formal attributes of the graphic. It is handled as a
structure that is important later for opening the screen, because
it acts as a storage space for measurements, depth and other values.
2 chunk length
3 graphic width in pixels
4 graphic hieght in pixels
5 x pos og graphic
6 y pos of graphic
7 no. of bitplanes
8 masking
9 crunch type
10 ?
11 transparent colour
12 x aspect
13 y aspect
14 screen width in pixels
15 screen height in pixels

CMAP (colourmap) each colour register stores three byte values
(red, green, blue)
2 chunk length
3 colour 0 red value *255
4 colour 0 green value *255
5 colour 0 blue value *255
6 colour 1 red value *255

CRNG (colourrang) Its possible to cycle through a colour region
creating very interesting effects. The CRNG chunk supports this
function.
2 chunk length
3 0 (unused)
4 speed
5 active/inactive
6 lower colour
7 upper colour


CCRT (colour cycling range and timing) The ccrt chunk also controls colour
cycling. Both chunks are treated by independent tasks, depending on the
manufacturer. Commodore graphicraft uses the ccrt chunk, while deluxepaint
used the crng chunk
2 chunk length
3 direction
4 starting colour
5 ending colour
6 seconds
7 microseconds

GRAB (grab position) The grab chunk indicates the relative position of
the cursor. This is useful for placing brushes which can be placed at
any point on the screen.

DEST (destination bitplanes) This chunk allows placement of the
available bit-planes of the body chunk in other bit-planes of the graphic

SPRT (sprite) sprites can also be saved in ilbm files with the help of
this chunk. The chunks single value designates the precedence of
the sprite. The value 0 represents highest precedence. The higher the
value, the lower the sprite precedence. The sprite with the highest
precedence is graphically placed ahead of all others.

CAMG (commodore amiga computer) Unlike the other computers that
have iff file systems, the amiga includes a set of viewmodes. These
display modes include ham and interlace mode. A new chunk (camg)
compensates for the support not given by normal iff ilbm chunks
The CAMG chunk contains only the viewmode register.

BODY (all Bit-planes and the Optional mask interleaveD bY row)
The body chunk contains the bit-map the most important section of
the if graphic file. This chunk operates under certain rules set by
the other data.
2hunk length
3 1st line of first bitplane (for eventual packing see BMHD above)
1st line of second bitplane
1st line of 3rd bitplane
2nd line of 1st bitplane
ect

   ANMB - Animated bitmap delux video
FSQN - playback sequence information

   ANIM -  form type for animations developed by aegis
ANHD - animated header chunk
DLTA - delat mode data

   ACBM - (Amiga basic contiguous bitmap) The main file is very similar to
a standard picture file with the important difference: the bitplanes
are stored in such a way only one amigados read/write is required per
bitplane. This results in a substantial increase in speed for
reading iff files from basic. To convert use the utilities on the
extras disk.
ABIT - non interleaved bitplanes

   FTXT - Is the iff text spec which is not often used, the two chunks
supported by ftxt are chrs and fons.

FONS is the font specifier which indicates which font to use

CHRS This consists of the actual text.

   RAW - Contains all the bitplane data sequentialy. IFFconverter can
produce raw data from iff code.

   SMUS - This format allows the exchange of musical compositions between
music development applications.

SHDR Is the scoreheader chunk, the tempo variable of a piece of music
is given in increments of a quarter note per 128 minutes.

NAME - name of the piece

C - copyright notice

AUTH - auth/composers name

IRev - other information ie revision

ANNO - comments (annotations)

INS1 - data about the instrument to be used, but not the tuning.
2 register contains no. of instrument
3 type instrument name (type=0), or midi channel (type=1).
4 data1 midi only channel number
5 data2 midi only preset

type - specify instrument name (type=0), or midi (type=1)

TRAK - contains the notes the be played, each entry is two bytes long.
The first byte specifies how the second byte should be interpreted.

SAMPLER - Device to convert sound to computer input

MIDI - Musical instrument digital interface, device which allows a
       computer to control musical instruments.

   8SVX - The 8SVX format is used for the open exchange of digitized
sounds between sampler/sound digitizing applications.

VHDR - the vhdr chunk contains a voice8header

NAME -  sound name.

C - copyright notice.

AUTH - auther

ANNO - comments

ATAK - contains egpoint structure which allows you to control the attack of
the sound.

RLSE - information for controling the delay

BODY - contains the sample.

   Viewport - A window in the current screen

   Rasport - The current screen


   Fonts - There are two types of font; in a simple font each size of
charactor has a different file. In a proportional type the charactor
is re-calculated as it is enlarged so as not to display rough edges.
   The topaz font is default and stored in rom, the rest are disk fonts.
All fonts can be italic (the top half of the chr is pushed to the right).
Underlined or bold (the chrs are displayed and re-displayed pushed to
the right. The font header informs the machine how many fonts it has
in each type. ie.opal will say two because it only has two sizes,
therefore if you were to make a third you must change this data.

   Icons -  An icon is a small image with a icon header. There are six
types:-
trashcan - deletes a file.
disk  - disk icon ie workbench
tool  - starts a program
project - (files) are of the same general design as the tools (programs)
used to create them.. Double-clicking a project icon opens the tool
used to create that file, then the project itself.
drawer - directory icon which opens a window containing more icons
icons can be manipulate by icon master
kickstart - kickstart diskette (1000 only)

   Brush - This is an image which can be easily manipulated, it is
the most transportable of all images. Type of ilbm, see ilbm notes above.

   Bob - (Blitter OBjects [shapes]) Graphic elements (GELS) used in
programming, software sprites. They can be any size but there width must
be a multiple of 16.

  Vsprite - (virtual visible hardware type) Gels Image used in programming,
you are limited to eight of these. Type of ilbm there different SPRT codes
allow one sprite to move behind another in a game. The amiga has eight
sprites four in overscan mode and either one playfield containing up to six
bitplanes or two playfields in dual playfield mode containing up to three
bitplanes each. They can only be 16 pixels wide but any height and have three
colours, the mouse pointer is a hardware sprite. Hardware as there are 8
register channels for them. IFFconverter can create them from iff format.
vsprites are used for animation an ordinary sprite which is hardware sprite
(for the eight hardware dma channels) cannot and is not a Gel.

The blitter comprises part of the Agnes chip in the Amiga, and can only
access CHIP memory.  (CHIP memory is the lower 512K of memory in the
current Amiga models, but this may change.)  To the 68000, it appears as a
set of approximately twenty sixteen bit write only registers.  It can
access memory at 7.2 megabytes per second, or twice the bandwidth of
the 68000 (although, as we shall see, it doesn't always run this fast.)
Any video memory accesses can slow the blitter down, whether for
screen refresh or for the 68000.  For instance, the standard two bit
deep high resolution workbench screen can slow the blitter down by
approximately 30\%.  A low resolution single bit plane screen can slow it
down by about 8\%.  A high resolution four bit plane screen can slow down
the blitter by about 60\%.  The blitter is so fast, however, that even
with this handicap it performs its tasks many times faster than the 68000.

The first thing a programmer of this chip must realize is that
the Amiga blitter is not a `bit' blitter; rather, it operates on words.
This fact must be kept in mind when programming the blitter.
With the appropriate programming, it can manipulate arbitrary rectangles
of bits.

The blitter uses four DMA channels to perform its work; these are labeled
A, B, and C (sources) and D (destination).  Any or all of them may be
disabled independently.  The destination can be calculated from any of
256 possible logical equations on A, B, and C.  The A and B sources can
be shifted up to 15 bits to the right, and the first and last word in a
line from the A source can be masked by a constant.  Each of the four
channels has its own modulo.  The blitter also has an area fill and a
line draw mode.

\section Getting Access\\

There are currently four ways you can use the blitter.  Some work better
than others.  The first way is to use the standard ROM Kernel routines
for graphics.  This is the simplest and most reliable method; future
blitters and operating systems will not disrupt your code.  I am not
going to discuss this approach here, because I don't want to, and all of
that information is in the ROM Kernel Manuals.  The second method is
to arbitrarily write to the blitter registers, ignoring Intuition
and friends.  This is a good way to make enemies; you can trash disks
as well as system memory, but it makes for good laughs on those slow
winter nights.  Just pop some random values into those blitter registers,
and watch the pyrotechnics fly!

The third method is a variation of the second, but you politely request
permission from the system first, by calling \b OwnBlitter().  This routine
notifies the Amiga that you want exclusive access to the blitter, and you
don't want anyone else playing with it.  After this
call returns, you can almost use the blitter.  Unfortunately, someone
else may have already given the blitter something to do that hasn't completed;
therefore, you should call \b WaitBlit() before actually mucking with
the registers.  This second routine blocks until the blitter is actually
finished with its work.  Once \b WaitBlit() returns, you are free to do
what you like with the blitter.

While you have the blitter, you must remember that the rest of the system
cannot use it.  Therefore, \b Text() calls will not work, and your debug
printf's will block if they are written to the screen.
The blitter is used for disk I/O and most user interaction like gadgets,
so tying
up the blitter for long periods of time (longer than, say, a few
milliseconds) is considered highly unfriendly.  Tying up the blitter
for a second or more is grounds for lynching.

When you are finished with the blitter, you should call \b DisownBlitter()
to allow everyone else to do what they like.  Remember, however, that
\b DisownBlitter() might return before the blitter is finished with your
last operation, so before you use any data created by the blitter,
call \b WaitBlit() to allow the blitter to finish.
This last point is worth rereading, as it is often
the source of some subtle bugs.

Thus, your code might look like the following:

\bv
OwnBlit() ;
WaitBlit() ;
/*
 *   here you can muck with the blitter
 *   until it falls off . . .
 */
draw_my_polygons() ; /* for example */
DisownBlitter() ;
/*
 *   Now we want to examine the memory region
 *   the blitter played with.  We wait for
 *   the blit to complete.
 */
WaitBlit() ;
copy_to_disk() ;    /* for example */
$endverb

There is another way to gain access to the blitter; you can use the
supplied queue blitter routines.  This is described
in the ROM Kernel Manual, Volume 1, pages 2-62 through 2-65.  As of yet,
I haven't had reason to use these routines; perhaps a later edition of
this manuscript will have information on them.