Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!att!bellcore!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Dynamic Display Architecture
Message-ID: <20670@cbmvax.commodore.com>
Date: 15 Apr 91 22:36:48 GMT
References: <1991Apr15.200955.3438@waikato.ac.nz> <3340@crdos1.crd.ge.COM>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 43

In article <3340@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>  This sounds like the Intel video controller, part number forgotten.
>This is the one they announced, dropped, then said they'd make because
>people had committed to it.
>
>  I believe the ability to have a list of frame buffers, with the size
>and starting pixel of each, was one of the features. It sounded like the
>perfect display chip, but the TI came out at the same time and had a lot
>of other useful features, and the Intel didn't sell well.

	I think that was a "hardware windows" chip - a fixed number of hardware
windows, each with their own display memory ptrs, modes, color tables, etc.
The problem with this approach is "what happens when I need N+1 windows?"
Another thing the copper get you is an arbitrary number of virtual screens
than can be slid over each other, flipped between, etc, all very fast.  Then
there are tricks you can play with a copper like scrolling a screen without
moving any bits (Amiga Unix terminal screens use this trick).

	A "general purpose" display coprocessor can do far more arbitrary
operations, even a quite dumb one.  The reason you don't want the main CPU
doing this is latency issues (though a dedicated GP CPU combined with the
right display hardware might do as well, though perhaps at the cost of 
dual-porting registers or making a separate bus for it) and bandwidth issues.
Also, some operations may take a larger number of cycles for a general
purpose CPU, and when modifying an active display you need fixed, fast
response times (it's almost closer to the requirements for a DSP than a
general purpose CPU).  The worst thing possible is for the timing to be
non-fixed (ala caches).

	Of course, the current Amiga Copper is old technology (released in
1985).  Given more and faster silicon (the original custom chips are in 3u
NMOS) there are many enhancements and additions one would make to them.
Some are quite obvious, like bulk color register loads.  Some are more
esoteric.  As to what enhancements are or will be made, I'm afraid I can't
talk about that subject.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Thus spake the Master Ninjei: "To program a million-line operating system
is easy, to change a man's temperament is more difficult."
(From "The Zen of Programming")  ;-)