Path: utzoo!mnetor!uunet!husc6!mailrus!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: Instant Windows (making the copper/blitter obsolete)
Message-ID: <48056@sun.uucp>
Date: 4 Apr 88 05:22:40 GMT
References: <2007@pasteur.Berkeley.Edu>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 60

[Note I reordered some of the lines here ... ]

In article <2007@pasteur.Berkeley.Edu> (Jonathan Dubman) writes:
> OK- I'm ready for the bad news.  Somebody respond and tell me that Fairchild
> or Texas Instruments or somebody has had the GFX1152 for three years that
> already does everythig I'm saying.

Intel makes it, and 'it' is called the 82786, I helped design it. The 82786 
is designed into three basic parts, the memory/processor interface, the 
Graphics engine, and the Display processor. The Display processor does what
you describe, basically you set it up with a bunch of 'descriptors' for 
the screen which is made up of tiles, overlapping windows can be designed
by breaking them up into the required tiles like so ...

+-----------------------------+
|       Tile 1                |
|........+----------------+...|
|        |                | T |
| Tile 2 |  Tile 3        | i |
|        |                | l |
|        |                | e |
|        |                | 4 |
+--------+----------------+---+

Window 1 is composed of Tiles 1,2,4 and Window 2 is composed of Tile 3. The
algorithim for converting from window space into tile space was interesting
but not especially difficult. 

The limitations are 8 tiles to a horizontal line, tiles are a minimum of one
line high. This in turn limited you to 8 totally generic windows or more
'virtual' windows where window position could be restricted. 

(Why 8 tiles? well that had to do with how fast the Display processor could
fetch descriptors from memory) The other nice thing about this chip is/was 
that each window could be any 'depth' (1,2,4,8 bits) and characters could
be blitted rather easily, although they were limited to 64 X 64 pixels if
I recall. 

> This ain't no pipe dream.  I have a decent idea of how to design it, and 
> I'm not even a "hardware person".  ...
>  ... Naturally, there will have to be some finite limit to the "see-through",
> like 8 deep or something.

The key thing is memory access time. If you keep the sprite descriptions 
'on chip' then you eat lots of real estate, if you keep them in RAM then 
you need really fast RAMs. The problems you encounter are very similar to
those encountered when designing a memory management unit. Basically, the
'video' processor puts out a request for the pixel at [x,y] which your mapper
has to map into a pixel of some sort. This involves mapping the virtual x,y
address to a physical address, and if it is transparent then checking the 
next mapping that fits the requirements. Doing this 8 times is pushing it
for 100ns DRAMS. (Note that Video RAMs are of absolutely no use here.)
For a given display (say 640 X 480) and a 32 Khz scan rate, one pixel time
is 49 nanoseconds. You can fudge a couple of nanoseconds by starting right
at the horizontal retrace time and slowly getting behind during the line.
As you can see your 'counters and gates' had better be Gallium Arsenide! :-)

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.