Random Explanations From the Experts
Compiled from Usenet by Andre Frech
Articles excerpted contributed by Matt Dillon (...!ucbvax!CORY.BERKELEY.EDU!dillon)
Hans Hansen (...!isum!hah)
and George Robbins (...!cbmvax!grr)
Each author's comments have been edited for clarity and accuracy (read: typos)
are preceded with the following initials:
MD: Matt Dillon, University of California at Berkeley
HH: Hans Hansen,
GR: George Robbins, Commodore Engineering,
AF: Andre Frech, Amiga Atlanta.
Preliminaries:
GR: Somewhat against my better judgement I'm going to answer these, although
I know others have already attempted the feat...
AF: Before we begin, it may be necessary to explain some of the terms and
concepts that will be brought up. First of all, Usenet is an international
network of Unix machines who communicate through a rat's nest of phone lines
and other hookups. You may now wail, "What is a Unix Machine?" Unix is an
operating system similar to AmigaDOS which was developed by AT&T in the 1970s.
Whenever you hear references to Usenet most of the text will come from a
newsgroup called comp.sys.amiga, which has an average traffic flow of about 400
messages per week. Usenet is not usually a subscription service, although a
few nodes (such as the WELL and the Soup Kitchen) exist for this purpose.
Usenet is free, if you can get in. Many colleges, government installations,
and small computer companies tie into usenet and it usually takes an inside
connection to access the network. Ho hum.
Here are some more terms that may need clarification. If you are somewhat
computer literate, you may want to skip on to the questions.
0xnnnnnnnn: As in 0x2468ACEF, this indicates a hexadecimal, or base 16 number.
Hex, for short, is a convenient way of representing certain computer
fundamentals such as memory locations, specific values, and so on, since hex
is a good compromise between how the computer actually stores numbers (in
binary, base 2 numbers) and how humans can easily remember and use these values
(definitely easier than adding two 64 digit binary numbers! For example, the
ever popular Guru Meditation Number is composed of hex digits.
68k: No, this is not memory capacity, but it is short for the MC68000, the
central processing unit (CPU) of the Amiga.
bitmap: From what I can understand, a bitmap is an area in memory which is
reserved to represent each pixel on your screen. See also pixel and bitplane.
bitplane: This is an area of memory set aside as a subset of the bitplane.
There can be up to six bitplanes in a bitmap. A bitplane contains values
giving rise to the colors in certain areas of your screen.
CRT: Acronym for Cathode Ray Tube. You may have heard this term if you have
been around computer types, or watch Max Headroom on television. Simply put,
monitor, TV, boob tube, what have you.
DMA: Direct Memory Access. This is a technique where data in memory is
transferred to something that needs it without the intervention of the
processor. In many cases the processor is needed to supervise this transfer,
which of course takes more time, and therefore DMA is quite fast for many
applications.
HAM: Hold and Modify. It's a special video mode that titillates the eye.
More detailed description are found below.
PAL: Programmable Array Logic. This is a special type of integrated circuit
which is custom designed by an individual by preserving and destroying certain
links, sometimes called fuses, in the integrated circuit to achieve a certain
logic pattern in hardware. Their advantages are less cost, less filling, and
they taste great.
Pixel: This is not a fairy, but instead it is the smallest dot on your screen.
If you've ever looked closely at your TV you get a headache, but before that
you can see that the picture is composed of a lot of dots. That was a bunch of
pixels staring you in the face.
OS: Operating System. Also this is Og the Caveman's brother.
Overhead: Refers to memory and processing time never seen by the outside user.
Vaguely, some tasks require elbow room to accomplish their purpose, and a
programmer must sometimes make decisions as to the tradeoffs due to time versus
overhead.
MegBytes, MBytes, MB, Meg, etc: Spelled out, it's one MegaByte. One million
bytes, or 2 to the 20th power (1 048 576 bytes.)
Atari ST: I have no idea.
Oh well, on with the show.
Q: Amy vid chip
MD: The Amiga's Video chip.
GR: Confusion - Amy is a diminutive used in some circles to refer to an
Amiga. The Amiga functions are actually distributed over 3 custom
chips, but it appears as only entitity from the programming model
point of view.
Q: blitter
MD: A device which offloads graphics tasks from the main processor. As far
as I know, there are two terms: 'blitter', and 'bimmer'. A blitter is
basically a DMA processor which can do copies between rectangular
areas on a bitmap. This is slightly more complicated than a standard
memory copy as the rectangular areas can be any width and height, and their
upper left hand corner need not be the upper left hand corner of the bitmap.
Blitters usually have the ability to draw 'lines'.
GR: These are subfunction "processors" in the Amiga custom chips. The
blitter (aka bimmer) performs bit-oriented logical operations on
bit planes. "blit" is an formalism/algorithm for performing such
operations.
Q: bimmer
MD: A bimmer is a more powerful version of a blitter. The Amiga's
blitter is really a medium scale bimmer, since it can perform arbitrary
logic operations on the bitmap data. We call it a blitter because the
term stuck. In any case, as far as the Amiga goes, its blitter can do any
arbitrary logic operation from three sources to one destination. The
destination can also be included in the logic operation by specifying it as
one of the sources.
Q: copper
MD: The Copper is a simple two instruction co-processor in the Amiga.
The Copper can (A) Wait for the video chip to get to a particular scan line
on the display, and (B) stick some immediate data into almost any IO
register. The Copper is thus used to change video modes on the fly (i.e.
change the color registers, sprite pointers, video modes, etc....). Again,
the whole idea is to offload work from the 68000. Although the Copper
steals cycles from the 68000, it runs a very small percentage of the time
(less than 3%). To do all the stuff the Copper does in the 68000 would take
*considerably more time (10%+).*
HH: Anybody want to guess at maybe 100-200%. Lets consider what is done by
the copper, (Agnus), and also understand that the copper is the heart of
the three chip co-processor call the "Custom chips". When you consider that
these three chips handle all of the serial I/O thru the RS-232 port, the
floppy drive I/O and the blitter decodes the trackdisk, the video screens
and sprites, four audio channels, plus the interrupts for the system, I
think that you will have to agree that you would need at least two more
68ks to do the work and still have the same quality of overall performance
that the Amiga custom chips deliver. Dont forget the lost processing
time that the 68k could not do if it were handling all of these other
functions.
GR: The copper is another "processor" that runs in synchronism with
the beam position on the CRT screen. While it's organization is
simple, it allows tricky screen manipulations without visual
artifacts and with minimal 68000 overhead.
Q: chipmem
MD: Chipmem refers to the area of memory that the custom chips can access
with their DMA. Currently, the custom chips have only enough address lines to
access the lower 512K of memory. Any custom chips which steal processor
cycles only do so when the processor is attempting to access this area of
memory.
The 256K expansion you stick in the front of your Amiga gives it
exactly 512K (not including the OS, which has its own 256K).
HH: Close, but Chipmem actually refers to the first 2MegBytes of RAM in the
Amiga's memory map. The existing copper, due to a lack of pins, can only
address 512k of memory.
GR: Loosely (!!!) chip memory is that memory that the custom chips are
able to access directly. Expansion memory is accessable by the
processor and external DMA, but not the custom chips. Although the
chip memory is normally shared by the 68000 and the display without
interference, some video modes and all blitter/copper actions may
co-opt processor cycles.
Q: fastmem
MD: FastMem refers to any expansion memory you might add to your
Amiga beyond the first 256K expansion you stick in the front of your machine.
That is, any RAM beyond the 512K mark is fast memory.
The term 'fastmem' comes from the fact that the 68000 can run at
full speed when referencing FAST mem no matter how many cycles the custom
chips are stealing from CHIP memory.
Needless to say, the WCS (Writable Control Store) that the OS is
loaded into is 'fastmem', although effectively ROM.
HH: Close again but... Fast mem refers to the memory above the chip mem area
of the memory map, or any RAM at or above 0x00200000.
Two problems here. First the custom chips don't "steal" memory cycles,
instead they utilize the bandwidth more effecently than the 68k and are
therefore told to take more of the chip memory bandwidth to get the
job done. (I know it's splitting hairs but how can you steal something
that you are ordered to take?). Secondly the reason the 68k can run
faster when not addressing chip mem is that the chip mem area is seperated
from the rest of the 68ks address map thru a DMA port that fully isolates
the custom chips and their RAM from the rest of the system. Only by
addressing the chip RAM area of the Amiga's memory map and then thru
an arbitration process within two PALs is the 68k allowed access to the
chip mem area.
GR: Fast memory is memory that is not affected by the custom chip
cycle "sharing". That is a program running in fast memory can run
full speed even though you may be beating the chip memory to death.
Internal expansion (> 512K) on new machines is somewhere in between
in that it works like chip memory, but isn't accessable by the
current custom chips. External memory is still "fast".
Q: graphmem
MD: Graphics memory? Generic term meaning the memory available to
some graphics device. On the Amiga, this is the lower 512K portion of memory.
HH: I believe this is a non-Amiga term to describe the assigned video RAM
area of their systems.
Q: color look-up table
Q: color registers
MD: Both mean the same thing. If a given pixel on the screen is made up
of, say, 4 bits (4 bit-planes), then it can assume one of 16 colors normally.
(exception: HAM, see below). On the Amiga, there are 4096 colors available.
You want to be able to pick 16 out of the 4096 colors to use for that screen.
Thus, your color look-up table would have 16 entries in this case (each entry
being able to specify any of the 4096 colors). Each entry represents a
combination of bits that are 'on' for that pixel.
Some times 'color look-up table' means the lookup table is in RAM
rather than in hardware registers.
GR: Means of translating a limited number of bits per pixel to one of a
many color shades.
Q: Agnus, fat agnus, paula, portia, diane, etc.
MD: The Amiga's custom chips, with some hardware terms sprinkled in.
HH: Never heard of a "fat agnus" or the "diane", and as far as I know neither
are C-A chips.
GR: These are the Amiga custom chips.
Agnus - Address Generator - Contains all the pointer registers, update
logic and DMA control. Also the blitter, copper, sprite engines, etc,
and sync generation.
Fat Agnus - is a modified Agnus chip used in the A500. It integrates
various logic from the A1000 board into the Agnus package, but does
not add any new capabilities.
Paula (orginally Portia) handles most of the random I/O functions
includingserial port, floppy and sound.
Denise (orginally Daphne) handles the video shifting, color lookup
table, sprite/bitplane priority andmouse motion.
Two 8520 "Versatile I/O" chips handle the mundane I/O operations
including the keyboard, parallel port, floppy control and RS232
control.
Q: SUPER_BITMAP
MD: Refers to a window containing a bitmap which is much larger than
the window, so you can only see a small part of the bitmap in the window
at one time.
GR: A bitmap bigger than can actually be displayed on the screen.
Q: What are the various ways of representing a monitor image in memory?
bitplanes?
MD: On the Amiga, it's bitplanes. E.G. if each pixel is 5 bits, then
the screen has 5 bit planes. Each bitplane is a contiguous segment of
memory and can be referenced independently of other bitplanes.
Other machines might, for instance, stick all the bitplanes together
in one big chunk so each BYTE represents the information required to display
one bit. I for one do not like this method because it is difficult to
provide for expansion beyond 8 bits per pixel without changing the way
memory is organized (i.e. to go to 16 bits per pixel, you have to now make
each word reference a pixel). Whereas with the bitplane approach, you
simply add another bitple amount of bandwidth,
the chunky approach always takes the maximal amount. Of course, if the
maximal amount can be handled without slowing down the processor, this does
not present a problem.
Q: each dot has it's own contigous group of bits for color (chunky memory)?
chunky-planar?
MD: See above. It's a contiguous group of bits (as in one byte represents
a pixel), or broken up via bitplanes.
Q: HAM?
Can anyone give a 2 or 3 paragraph explanation of just how HAM works?
How about any other "exotic" memory map scheme?
MD: HAM is a 6-bitplane low-resolution video mode on the Amiga. The
difference is that bits 5 and 4 (543210) now control how the remaining
four bits are used.
5 4 3...0
0 0 color of pixel is that found in the color register 0-15
(as if you had 4-bitplane normal video).
0 1 use the color of the pixel to our left, but modify the BLUE
using our 4 remaining bits (3210).
1 0 same as 01, but the RED color is modified
1 1 same as 01, but the GREEN color is modified.
Thus, you can effectively get all 4096 colors on the screen. By
making proper use of your 16 'static' colors, you can get to any of the
4096 available colors within 2 pixels...
The idea behind this is that in many pictures, one has a gradual
change in color. HAM mode can allow you to make this gradual change without
wasting ANY color registers. For those parts of the pictures which have
sudden changes, you can use a color register and 'jump' to that color...
or close enough to that color that nobody would notice the difference.
Q: What is bandwidth (I need a really exact definition of this one, it's all
kind of fuzzy in my head, must not be enough bandwidth, eh?), and how does it
relate to graphics display?
MD: There are two kinds of 'bandwidth'. One refers to the 'bandwidth
of your monitor' (basically the resolution it can support). The other
refers to MEMORY bandwidth... how many bytes/sec can be transfered from
main memory. An Amiga 1000 has a total memory bandwidth of about 7MBytes/sec.
(memory access every two cycles of a 7.14Mhz 68000 = 3.57M access/sec, @
16 bits / access = 7MBytes/sec). (correct me if I'm wrong).
HH: Partially correct, the 68k's bandwidth is 7.14 MByte, however the bandwidth
of the Amiga is really 14.28 MBytes. The custom chips run at twice the
data rate of the 68k! This is the main reason that the 68020 turbo, 14.28 MHz
processors work so well, (well maybe just a little help from the forsight
of Dale Luck and C-A).
GR: Bandwidth is basically the number of bits per unit time that you can get
through a device. In the case of video, it is the number of bits/second
you need to handle screen refresh. In the case of high resolution/lots of
bits/pixel displays this becomes a critical design factor.
The Amiga performs 1 16-bit memory cycle every ~280 nanoseconds. This yields
a total bandwidth of 7.16 Megabytes/Second. Normally half of these cycles are
used by video refresh and half by the processor, however it is possible to
select video modes that use more than 3.58 Megabytes/Second, in which case
cycles normally allocated to the processor will be used.
This is a basic design limitation of the Amiga chipset and can only be
avoided by implementing faster memory cycles, specialized memory chips,
32-bit wide video memory, external display hardware or some combination of
the above.
The Atari ST suffers from the same limitations, but doesn't have any display
modes fancy enough to exceed half the available bandwidth.
Additional comments:
HH: For the most part Matt's answers are correct, and I would not
have added to his answer except I was just tired of seeing people say
that the custom chips steal memory cycles! The DMA circuit in the
Amiga is very efficient and using the copper to do tasks is the most
efficient use of the chip memorys bandwidth. The fact that the 68k
can be blocked from memory access to the chip ram during heavy usage
of the blitter, just says to me that the custom chips are doing something
that would take the 68000 4 to 20 times as long to do. One related
thing that is mostly over looked and that is that if the 68k really
needs to take back the chip memory accesses that it has given up it
can. There is one "hole" on every scan line left open for just the
purpose of turning off blitter_nasty_mode.
I really wish that C-A would write all of this up and use
it in their ads, or at least give it to their dealers.
Experimenting With your Kickstart RAM
by Steve Schoettler (...!ucbvax!schoet)
If you've ever wanted to modify kickstart routines, here's the
information you've been waiting for.
If you use metascope and would like to trace your program as it
calls some kernel routine or set breakpoints in the libraries, the
following information should be very useful.
How many times have you called OpenWindow() and bombed but didn't
quite know why?
Even with this modification, when you're not interested in writing
to kickstart, you can switch the capability off and it's
write protected just like a normal Amiga!
Of course, this leaves the ram open to crazy programs, but that
simply means that if a program goes wild and happens to write to
a critical area you have to turn off the machine to reboot kickstart,
rather than just inserting workbench. To me, the ability to debug
is worth it. Besides I can easily return to write protection.
First, a few words about how the kickstart sequence works:
When you turn on your Amiga the bootup ROM reads the Kickstart
disk into the Kickstart RAM at $fc0000. Then the 68000 does a read
to the location $f80000. (Actually, anything with Address bits 19-23
high and A18 low would do). This condition is detected by a PAL called
DAUGCAS, which write protects the kickstart ram.
There are three methods you could use to disable the write protect:
(1) Install a switch to force the write protect signal (WPRO*) inactive.
This is the method I used, and is really simple because
C-A graciously left two holes in the circuit board for the wires
to my switch. It could probably be removed (in case you had to
take it in for servicing at a later time) without leaving any
traces. Well, actually you would have to drill a hole in the
back panel to mount the switch.
(2) Replace the PAL with one that had a different equation for the
WPRO*. This has the glamor of not needing any solder.
The equation could be set up to never write protect the RAM,
but that's probably not such a good idea.
A better method would be to make the RAM toggle the WPRO*
signal with every read to $f80000. A simple C or
Basic program could be written to read this location. Just
so you know what state it's in (WPRO* or not), you could read
location $ffffff, write something else to it, and read it back
again. If it's the same, it's write protected, otherwise it's
not so put the old value back.
(By the way, the location you choose should not be any code
another task might be executing. Maybe you could overwrite the
copyright notice. To be safe, a forbid() and permit() would
probably be a good idea.)
(3) Remove the instruction that reads location $f80000 in the first
place. This is in the Boot Rom, so you'd have to change that.
I don't like that solution because it's permanent.
If you like the PAL method (2), you're on your own for now. I have
figured out how to make the new PAL, but I can't post the equations
and I can't distribute the chips without violating C-A's copyrights.
I have gotten a preliminary OK from Commodore to distribute the PALs,
and as soon as I get a written OK, I'll let you know about it.
They should cost less than $10.
Following is a description of how to install a WPRO* switch
(method (1), above):
********** But first, a disclaimer *******************************
****
**** 1. I can't be responsible for anything you do to your Amiga.
**** I believe I've explained this thoroughly enough so someone
**** with soldering experience and a reasonable mechanical
**** intuition can do it without much difficulty, but you
**** are taking your computer into your own hands.
**** 2. Commodore may have or may in the future change the layout
**** of the circuit board or change the PAL's, making these
**** instructions obsolete. If your board doesn't look like
**** what I'm describing, DON'T DO ANYTHING.
**** 3. This will void your warranty.
**** 4. I represent no company or organization in any way whatsoever.
UNPLUG YOUR AMIGA!!!! It will be very easy to strike a metal
object (soldering iron, solder, resistor, wire, watch, etc) across
two consecutive traces and who knows what might happen.
First, you need to take off the cover of your Amiga and take
off the metal shield that covers the circuit boards (yes, all
19 screws and 2 twist tabs).
So we agree on orientation, the front of the Amiga is towards you,
the power supply is on the left, and the parallel port is on the
upper right side. I will refer to the rear of the Amiga as the
"top."
There is a main mother board, and an L-shaped "daughter board"
which is upside down, above the main board. The PAL is located
on the daughter board at location J-6. It's on one of the
inside corners, next to the letter "J" and it says "DAUGCAS"
alongside it. This is a 20 pin chip.
There should be a white outline of the chip between the
pins with a notch at one end. From the notch, count pins
clockwise until you get to pin #13, which is the third one from
the upper right corner of the chip. Pin 13 is the WPRO* signal.
Originally, the WPRO* signal went through a resistor and LED
to +5V. Since WPRO* is active low, the LED would go on during
bootup while the ram was being written, and then go off at about
the time it told you to insert the Workbench, and remain off
until you turned the machine off.
Well, it's silly to have an LED inside a closed box, so C-A
decided to save costs and not insert the resistor and LED, but
the circuit board should still be the same.
I don't know on how many boards the LED was inserted, or on
how many boards the LED socket will still be around, so inserting
the wire to the switch may be a slightly different procedure for
some of you.
If you follow the trace from pin 13 of DAUGCAS it will go to
one of the resistor terminals. Insert the stripped end of a wire
into this hole at the left end of the resistor. (Just heat the
hole with your soldering iron and push the wire through).
As a precaution, before working on the board, put a piece of paper
under where you'll be soldering so solder splats don't hit the
board below. I didn't get anything on my paper, but it's good
prevention.
Above the resistor space is a white box marked "1" with 2 solder
holes. Insert the stripped end of another wire in the left-most
of these two holes inside the box. You now have the two wires
necessary to run to your switch: one is connected to WPRO* and
the other to +5V. With the switch "on" you will pull WPRO* hi
(inactive) and make the ram writable.
A note about mounting of the switch. I suppose you will want to
mount this in the back panel. This panel is removable, so it's
easy to put it flat on a table and drill a new hole.
Before you remove the back panel and drill the hole, however,
put the metal shield back on (screws not necessary) and hold your
switch in the location you wanted. If it's like most switches, it
probably won't fit next to the metal shield UNLESS it's as far right
as possible (over the keyboard jack).
Now, go drill the hole.
When cutting the wires, leave a few inches of slack so they can fit
through the crack in the metal shield in the upper right corner.
(convenient, huh?)
Now put it back together and you have switchably writable kickstart!
A note about operation:
For normal operation, leave the switch "off" when you power
up. This will look and act exactly like a normal Amiga.
To enable writing the ram, turn the switch "on".
If, after you have been writing the ram, you decide to
write protect it, the switch alone won't do it - TURNING THE
SWITCH BACK OFF STILL LEAVES THE RAM WRITABLE. You need to
either do a read to location $f80000 or turn the machine off
and on again.
If you want the facility to turn off WPRO* with a switch,
you can use a 3 pole switch with WPRO* in the middle terminal and
+5V on one side and GND on the other, but there isn't a convenient
hole for GND so you'd have to find one on the board. This would
have an immediate reaction with any direction of the switch.
Technicalities:
All of the above works, but if you want to know a little more
about how, read on.
The WPRO* signal is actually both an output and input of the
DAUGCAS PAL. The logic used to generate it has what we call a
"set" term and a "reset" term. It acts like a S/R flip-flop.
The "set" term makes WPRO* active when the processor does a read
cycle from an address whose bits 19-23 are high and bit 18 is low.
The "reset" term comes from the hardware reset line that is active
when the machine powers on.
Once WPRO* is set, it won't be reset until power on again, and
once it's reset it won't be set until that read instruction.
WPRO* is both an output and an input of the PAL. The output is
generated from the above equation, and the input is used to disable
a write signal from ever getting to the RAM.
The very astute of you might criticize the forcing high of a low
output. Well, the only time the output is forced is during the read
cycle (a couple hundred nanoseconds), because after that WPRO* is
tricked into thinking it was reset and the output agrees with what
is being forced so no more contention. The PAL used, according to
the manufacturer, is able to handle voltage applied to outputs up to
Vcc, which is +5V, so we're within specs.
Happy hacking!
How to Attempt Correct Video Centering
by Steven E. Price, P.E. (...!tektronix!videovax!stever)
Keith Doyle asks:
How do you determine what 'correct' video centering is for video recording?
The Amiga Preferences centering control allows you to adjust for individual
monitors and TVs, but where is the right place for VCR's and television
broadcasting? (any gurus from Tektronix out there?) . . .
Steven replies:
The controlling specification in this case is RS-170A -- "Color Television
Studio Picture Line Amplifier Output." While there are many numbers given
in this standard, the "Front Porch" width and "Sync to Set-Up" are the two
that count. The diagram below shows the horizontal interval:
\ /
\ /
\ _____________ /
\ / \ /
\ / \ /
\_____ __/ Color Burst \_____/
\ / \ /
| | | \ / |
| | Horizontal | \_____________/ |
| | Sync | |
| | | |
| | | |
| \__________________/ |
| |
| | |
| Front | <---------- Sync to Set-Up ------------> |
| Porch | |
The negative-going edge of the Horizontal Sync pulse is the reference for
all timing in the line. Standard NTSC video has "set-up" on each line,
which is just a small positive (upward) voltage added to the signal
everywhere except in the horizontal interval. I don't know whether the
Amiga composite output (the one you feed to a TV or VCR) has set-up or
not -- I've just not looked!
RS-170A specifies the Front Porch to be 1.5 +/- 0.1 microseconds, and
Sync to Set-Up to be 9.4 +/- 0.2 microseconds. For computer graphic
output, you want to center the picture, though -- so put up a signal that
has a clearly-defined boundary (e.g., a standard, full-screen CLI window
with borders, or the Preferences window) and use an oscilloscope to adjust
the centering (using Preferences) until the picture is positioned with
equal additional space to the left of the front porch and to the right of
the nominal beginning of set-up.
As an example, adjust for 4 microseconds (1.5 + 2.5) from the end of
video to the leading edge of sync and 11.9 microseconds (9.4 + 2.5) from
the leading edge of sync to the beginning of video. In this example, an
"extra" 5 microseconds of blue background has been divided equally between
the time before the front porch and the time after the nominal position
of set-up. This will, in general, produce the best results.
You can't use a standard TV set to perform the adjustment, because the TV
set almost certainly suffers from overscan. "Overscan" just means that
the picture is slightly too large, with some of it being lost at the top,
bottom, and sides. TV manufacturers build their sets this way to ensure
that there aren't black areas at the edges of the screen -- people
complain about pictures that are too small, but not ones that are too
large!
Neither can you make the adjustment with your Amiga 1080 monitor (which
has *much* less overscan, by the way!), because the Amiga monitor has its
own centering control. Unless you have previously adjusted the monitor
with a known-good signal (and you know for certain the kids haven't messed
with it), you are just misadjusting the computer output to compensate for
the misadjustment of the monitor. . .
Timothy Rue (AAi member)