T.R | Title | User | Personal Name | Date | Lines |
---|
2256.1 | A quick explanation. | SMAUG::SPODARYK | Jefferson, I think we're lost. | Mon Feb 20 1989 11:54 | 20 |
| I'm sure you will get more technical explanations, but a
major reason for the Amiga's graphics speed is due to it's
custom chip set.
The main graphics chip ("Agnes") is a blitter. This is
a chip dedicated to manipulating memory at high speeds,
mainly for graphics applications... Fills, lines, windows,
software sprites, etc.
I believe there are also chips for disk i/o ("Gary"?), etc,
but here my knowledge is somewhat hazy. Having these custom
coprocessors allows the CPU to off-load many functions, and
frees up the 680x0 for other computational based duties.
This allows an Amiga to perform better (depending on the
application) than a Mac counterpart, when both are using a
similar CPU (M680x0).
Hope that helps.
|
2256.2 | | LEDS::ACCIARDI | | Mon Feb 20 1989 16:16 | 78 |
|
'Fast' depends on what you're doing. The Amiga 'feels' fast when
moving windows, sliding virtual screens up and down, and other
graphics-intensive operations. (Quick, how many other personal
computers can have multiple screens active, all with different color
pallettes and resolutions? Right.)
In actual performance benchmarks, most of the 68000 and 80286 systems
offer comparable computational performance WHEN DOING ONLY ONE THING.
The Mac SE, IBM AT (and clones), Atari ST, and Amiga all can perform
computations at about the same speed, give or take 10%, when factoring
out things like math chips and compiler efficiency. I won't compare
these affordable systems to more expensive 68020/68030 and 80386
machines, since you're now into real 32 bit machines with
workstation-like performance. I'm also deliberately leaving out the
Apple IIGS, which, though I don't have actual benchmarks for, feels
like the slowest computer on God's green earth, where you can actually
watch menus being painted onto the screen as they drop down. Anyway,
the Amiga really starts to kick ass in a multitasking situation, ie;
downloading, formatting floppys, playing music and editing text all at
the same time.
In my opinion, performing computaions quickly is not a very good
way to make a computer feel fast (for the nit-pickers, I know that
moving windows about is 'performing computations', but you know
what I really mean.)
Performing computations is not what the Amiga does best, although it
can certainly hold it's own. What the Amiga does best is generate nice
graphics and sound, simultaneously. (Doesn't this sound like it could
be fun?) A good example of this is the famous Amiga Bouncing Ball
demo. This demo was remarkable at the time it was introduced, and was
used to demonstrate how wonderful the Amiga was. Atari promptly
reproduced the demo on it's ST computers to show that you could get the
same performance for less money. What the Atari could not do was slide
the Bouncing Ball screen down and load and run two or three other
graphics and sound intensive demos at the same time. The Amiga could
do this, with only a small decrease in speed of the Bouncing Ball
scre
The Amiga has a very innovative multitasking OS which takes
good advantage of the available processing power. While a user
is banging away on the keyboard at a word processor, waiting an
eternity between keystrokes, the CPU is available to direct other
activities that are helped out by the graphics and sound coprocessors.
I'll take a stab at describing the Amiga blitter chip, but a more
technical person might want to elaborate. The blitter can perform
operations on any section of CHIP memory (ie, stuff you see on the
screen) in hardware that would otherwise have to be done by the
CPU. The CPU says 'move this chunk of screen over to there' and
the blitter does it with no further CPU intervention. The Amiga
blitter provides support for block moves and fills, polygon moves
and fills, and line drawing, and maybe a few other operations I
missed. It can also perform boolean operations on chunks of screen
memory.
The main advantage of the blitter is not how fast it performs it's
operations, (although it is very fast, something like 2 million
pixels/sec) but that it can work in parallel with the CPU.
The Copper chip (for graphics coprocessor) is responsible for
controlling the color pallette and display resolution. The copper lets
you slide screens up and down in real time with no performance hit. It
can completely alter the color pallette and screen resolution between
any two adjacent horizontal scan lines, 60 times per second. It
can also alter the color pallette on the fly within a given scan
line, with some color change restrictions. This is the photographic
'HAM' mode you may have heard of. Again, this is all done by dedicated
hardware with no CPU performance loss.
By the way, there is a Macintosh emulator for the Atari ST that has
been around for ages, and has been refined to a high state of
functionality. It also runs Mac software 15% faster than the real
thing. (I threw that in for our friends with STs, the only reasonably
competent computer that gets kicked around more than the Amiga :^))
Ed.
|
2256.3 | Better Software | TLE::RMEYERS | Randy Meyers | Mon Feb 20 1989 20:23 | 124 |
| Re: .0
Both .1 and .2 praised the Amiga's custom hardware. They are correct in
pointing out that this is where the Amiga gets a good bit of its speed.
I want to point out the role of software.
The Amiga's operating system and windowing system are designed very
differently than the Mac's. This give the Amiga a natural speed
advantage that it would have even if the Amiga didn't have its
special hardware.
The Amiga supports several different window types. The most popular
window type is "smart refresh." A smart refresh window is "smart"
because the system, and not the application program, will handle much
of the refreshing of the window.
Consider two windows, with one of the windows overlapping the other.
The part of the back window that is obscured presents a special
problem. The memory used to store that part of the window's image
has been overwritten by the window in front. In the graphics memory
being displayed by the video hardware, the image of the window in
front has replaced the covered up part of the window in back.
Now, imagine what happens if the user clicks the mouse and pushes
the window in front to the back. Now, the old window in back is
the new window in front. Part of the new front window was previously
covered up, and now isn't. In fact, that part of the window now covers
up the new back window.
The graphics memory for that uncovered piece of front window needs
to be "refreshed," or redrawn. Its image needs to replace in the
graphics memory the image of the newly covered section of the window
in back.
In an Amiga smart refresh window, the system does all of this type
of refresh. When a window is covered up, the system allocates a block
of memory large enough to hold the part of the image being obscured.
It then quickly copies that part of the image into the system
managed buffer before it allows the obscuring graphic to overwrite
the image in graphics memory. When the obscured portion of a window is
later uncovered, the system quickly copies its private buffer containing
the covered image back into graphics memory.
Thus, the application program need not (and usually doesn't) know that its
window was once obscured and now isn't anymore. The system has completely
managed this situation for it, and the system did so in a way that didn't
involve much "thought": the system knew what the bits should be, and it just
copied them.
On the Mac, refresh is handled by the program, not the system. When part
of a window is uncovered, the program is told by the system, "redraw
the following part of your window..." The program then reconstructs what
the window's contents should be and redraws them. "Oh, yeah, I wanted a
slider over there, I'd better redraw it. And I was displaying the checking
account balance. Its stored in this variable here. Let's convert it
to ASCII, and call the graphics primitive to display the characters...."
Mac programs are intimately involved with screen refresh, and refreshing
the screen involves figuring out what the bits should be as well as
moving them into graphics memory. Performing window refresh is a process
that involves "thinking."
So, Amiga "smart refresh" windows require less CPU time to keep refreshed
but use more memory. Mac windows are slower, but use less memory (the
Mac's windowing system was designed for 128K non-expandable machines).
By the way, if you like the Mac's memory for speed trade off, you can
use "simple refresh" windows on the Amiga: they work just like Mac windows.
(Workbench drawer windows are simple refresh. That is why you can see
the icons redrawn if you move those windows around. Workbench was designed
for 256k Amigas.)
The prevalent use of "smart refresh" windows on the Amiga means the system
does respond faster most windowing operations. Its natural software
advantage is then multiplied by the fact that the bit copying done to
maintain fresh "smart refresh" windows is being performed by the blitter,
leaving the 680x0 free.
Another software advantage is that with so many windowing tasks being
performed by the system, the responsiveness is better. The Amiga operating
system is very good at responding quickly to events and dispatching
work to appropriate task: it is a realtime operating system. (I read
somewhere that because of this fact, a prototype Mars walker probe
is being controlled by an Amiga.) The parts of the operating system
that handle many windowing events are usually idle, just waiting to
get their chance to perform their function. In contrast, on the Mac,
the program has to handle windowing events. If the program is busy
sorting a data base, it is going to take slightly longer before it
is willing to snap to and redraw that display. (Don't worry: the
Mac program will not wait to finish its sort before processing the
window event. Mac programs MUST periodically take a break from what
they are doing to allow window refresh to occur, desk accessories
to run, and mutifinder to multifind.)
SIDEBAR (Some definitions so you don't get the wrong idea)
When I talked about "graphics memory", I was talking about memory in
the process of being used by the video hardware as the source of the
image being displayed. In the Amiga, any part of "chip memory" may
become graphics memory as I've just used the term: the video chip
can be told to fetch its data from any part chip memory. In fact,
as you flip between different Screens or pull Screens down using their
drag bar, the video chip will access different parts of chip memory
as "graphics memory."
Usually when people talk about graphics memory in the Amiga, they
mean all of chip memory, or chip memory that has been allocated
for some graphics use even if that memory is not currently being
used currently by the video hardware (a Screen completely hidden
behind another Screen is an example of this). In the above
discussion, I needed a term for "memory being currently used by
the video hardware," and "graphics memory" seemed like the handiest
term.
When the system allocates memory to hold hidden smart refresh window
areas, it allocates the memory from chip memory. The system wants to
use the blitter to move the bits, and the blitter can only work with
chip memory. So, using the usual definition, the system's private
smart refresh buffers are in graphics memory, too (even though the
video hardware doesn't look at those private buffers at all).
"To multifind" is a verb. It is what the Multifinder on the Mac does.
Multifinding bears a strong resemblance to multitasking; however,
multifinding involves many inefficiencies and special considerations,
and so should not be confused as being the same thing as multitasking.
|
2256.4 | Thank you all | MARCIE::GDEJULIO | | Tue Feb 21 1989 13:46 | 10 |
|
I would like to thank you all for taking the time to answer my
questions so effectively. I would enjoy hearing more if you've
got the time and the desire, because I can never get too much
information.
Thanks,
- Jeff C.
|
2256.5 | | BAGELS::BRANNON | Dave Brannon | Tue Feb 21 1989 15:09 | 16 |
|
my favorite is the mouse pointer. Try watching the mouse pointer move
or have text scroll under it on "other" computers. With hardware sprites
you don't have to redraw the display after the mouse pointer passes
over it. Or redraw the pointer when the display under it scrolls.
That should save a few cpu cycles.
From the previous notes, you'd almost get the impression that the
multitasking was designed in from the hardware on up. Lots of extra
effort to reduce the load on the 68000, that frees up cycles so
it can handle more mundane tasks like running a real time, multitasking
OS.
-Dave
|
2256.6 | | LEDS::ACCIARDI | | Tue Feb 21 1989 17:10 | 7 |
|
Gee, call me a sap (go ahead, really) but talking about the Amiga
architecture, software and hardware, still makes my short hairs
stand up, even after three years. Can Jay Miner be nominated for
sainthood? Shouldn't we at least build some sort of shrine?
Ed.
|
2256.7 | Does DECwindows need smart-refresh windows? | COOKIE::WITHERS | You know you can't memorize Zen | Tue Feb 21 1989 18:32 | 0 |
2256.8 | sap -> | SAUTER::SAUTER | John Sauter | Tue Feb 21 1989 21:04 | 32 |
| re: .6
You're a sap. (Not really.)
The Amiga hardware is a pretty obvious extension to the 68000-based
systems that came before it. The low-level software is a perfectly
ordinary real-time kernel. The high-level software is pretty neat
stuff, but there's nothing really mind-blowing in it.
The sum is greater than the parts, of course, and the Amiga taken as a
whole is a very nice machine which pushes the state of the art, but
then most (non-IBM) machines are like that. Pretty soon there'll be a
machine which pushes the art further, and the Amiga won't be at the
forefrunt any more. At that point the techno-freaks will go on to
the newest machine. That won't make the Amiga any less useful, just
less glamorous.
I've seen it happen before. The IBM 7090 was the "standard computer"
of the early 1960s, but the Burroughs B5000 had the best programming
environment. The B5000 attracted its share of wizards, but they
abandoned it for the IBM 360/67, which had paging. Some wizards did a
lot of good work for the PDP-10, but the VAX attracted them away.
Maybe Steve Jobs' NeXT will be the next attractant.
Don't be overly impressed by the latest neat computer---it won't be the
latest in 6 months or so, and if you always insist on the latest you'll
never get anything done.
I suspect this sounds like the writings of a jaded old man.
John Sauter
|
2256.9 | | DECWET::TBAKER | Tom Baker - DECwest CSSE | Tue Feb 21 1989 23:37 | 12 |
| re .8
>> Some wizards did a lot of good work for the PDP-10, but the VAX
>> attracted them away.
Actually the VAX didn't attract them away, DEC pushed them away.
...but that was another computer war....lost long, long ago in a
galaxy far, far away....
tom
|
2256.10 | Just not a passing fad... | JFRSON::OSBORNE | Blade Walker | Wed Feb 22 1989 08:14 | 11 |
| re: .8
>... if you always insist on the latest you'll never get anything done.
> I suspect this sounds like the writings of a jaded old man.
Not really. What I think I hope for, and expect, is that the Amiga will
develop enough of a customer base for its architecture, before it becomes
obsolete, that software will be built to push the hardware as far as it
can go. This has happened with the Apple ][, I think, and I would like to
believe I've invested in an "Apple" and not a passing fad.
John O.
|
2256.11 | | TLE::RMEYERS | Randy Meyers | Wed Feb 22 1989 18:56 | 20 |
| Re: .8
You are a jaded old man. (Not really.)
Although the Amiga's architecture isn't really to radical for anyone
familiar with "real computers" (non-personal computers) it is a
breathtaking masterpiece when compared to the crop of pre-Amiga (and
even post-Amiga) personal computers.
Most personal computers still have the "CPU" handle everything.
Most personal computers still have non-multitasking operating systems.
In many ways, the hardware and software architecture of personal computers
still ignores ideas that were accepted 25 years ago for real computers.
Fifteen years ago, much more sophisticated operating systems were standard
and expected for machines with a fraction of the memory and CPU speed
of today's personal computers.
It's like those folks have to reinvent every idea.
|
2256.12 | Hold Back the Power | SALLIE::GDEJULIO | | Thu Feb 23 1989 09:17 | 21 |
|
It's true that the technology to do these things has been here for
a while, but PC (personal computer not just IBMs) manufacturers
haven't felt the need to give us the power that could be ours.
This could be due to the high price of the technology or because
their profits would not be high enough. If you do want the state
of the art, they make you pay an arm and a leg for it.
I still can't believe that a company like Amiga was the first computer
to put everythng together in a package that is so affordable. I
am glad that someone finally did somethng right. The Amiga will
hopefully make the market more competitive and drive performance
up and cost down. With the Next computer making its debut, higher
end PCs will have the same type of competition. I hope this will
have a good effect on companies like Apple, which have had good
products when they first are released, but they never increase the
power of their machines without an outrageous cost.
- Jeff C.
|
2256.13 | | BAGELS::BRANNON | Dave Brannon | Thu Feb 23 1989 18:52 | 11 |
| re:.12 can't believe
Amiga as a company was dying when Commodore bought them. Possibly
too much engineering and too little selling. Consider how well
the C64 and IBMPC have sold, then ask yourself, "do you really
need 4096 colors, stereo, etc., for most pc applications?".
Then consider what most pc applications could become if only that
level of hardware/software were the default configuration.
-Dave
|
2256.14 | The Default Clone will not be bagbiting forever | TLE::RMEYERS | Randy Meyers | Fri Feb 24 1989 18:39 | 31 |
| Re: .13
> Amiga as a company was dying when Commodore bought them. Possibly
> too much engineering and too little selling.
The death of Amiga, Inc. was entirely due the the fact that they were
spending $30,000,000 of engineering with only $20,000,000 of capital
investment. The market never got to vote on whether the product
was desirable. Since Amiga, Inc's only products were a smoke screen
(they sold joysticks), I don't think they had any significant revenue
coming in.
(On capital investment: Praise be to Doctors with too much money looking
for exciting investments. They brought us the Amiga.)
>Consider how well the C64 and IBMPC have sold, then ask yourself, "do
>you really need 4096 colors, stereo, etc., for most pc applications?".
The C64 is sort of a special case: it was (is) a home computer for those
on a budget. The IBM pc is a more interesting case, and a more forceful
argument. However, that world is changing pretty quickly: A friend of
mine who is pretty immersed in the clone world (both personally and
professionally) stated recently, "Everyone buys VGA these days, unless
they have a ridiculous budget." Won't be long before the clone world
is of the opinion that millions of colors are necessary for most applications.
> Then consider what most pc applications could become if only that
> level of hardware/software were the default configuration.
You're absolutely right. The default configuration is very important.
(Have you been giving advice to Steve Jobs, Dave?)
|
2256.15 | Value of a fast machine | AITG::WISNER | Paul Wisner, ...I have a totally traditional haircut... | Mon Feb 27 1989 13:00 | 12 |
| I was just reading "Computes AMIGA Resource" magazine. They have interviewed
several promenent AMIGA game designers. The question was asked "Why do you
do games for the AMIGA first?" ANSWER: (paraphrased, copied, condensed)
Because the AMIGA is a more powerful
machine and the designers can be more ambitious. Even though the AMIGA
market is small (about 1/40 the size of the IBM PC market for example), by doing
the AMIGA version first you end up with a better product for the IBM when you
port down. "The AMIGA version is a real good showcase for the product."
I don't know if the same mentality caries over to the productivity software
developers.
|