From: jdrew@cryo.rain.com (Jim Drew)
Subject: Re: Who has a working EMPLANT?
Newsgroups: comp.sys.amiga.emulations
X-NewsSoftware: BBX-UMB 0.27 beta (Nov 22 1992)
Date: 23 Nov 92 06:13:14 PDT
Organization: Cryogenic Software - Portland, OR


> Jim,
> 
> On your BBS, someone hinted that the reason Emplant runs so much slower in
> color is the extra DMA bus contention.  I would have expected most of the
> emulation to run in fast ram, and be immune to this.  Is it the display
> conversion routines that are effected here, or more generally, is it
> primarily the overhead of converting color video that is stealing CPU time
> from the emulation?
> 
> What future options might we have for getting a real time color display with
> no CPU overhead?  AGA chunky pixels?  Another video card?  Other???
> 
> When the Mac II operates in B&W, is screen memory similar to what it was
> like on older B&W Macs, in that a one bitplane Amiga screen could display it
> directly with no conversions, ala AMax?
In 16 color hires there is severe DMA contention with non-AGA machines. 
As much as 58% of the CPU time is being stolen for the Amiga's own video.
The memory you select for "Video Memory Type" is where the conversion
from Chunky to planer takes place.  Let me explain exactly how our video
driver works and why:
 
We have a fake NuBus video card in ram.  It is identical in every respect
to a MAC video card.  It has a simulated declaration ROM and everything. 
The ROM tells the MAC what kind of a video board it is, including the max
resolution, max # of colors, and how much video memory is on board.  What
we do is allow the MAC to draw data into the video memory pointed to by
the ROM.  This pointer is the memory type that you selected in the setup.
We have a seperate Amiga task (contained in the video driver) that
updates the MAC video at the rate you set in the setup (20 FPS, etc). 
The conversion is done by taking 32 MAC pixels and using a series of
lookup tables, convert them into 32 Amiga pixels.  Using 32 pixels is a
longword of data, the fastest method of storing.  Now, you might ask "why
let the MAC draw into a fake buffer, and then do the conversion instead
of having the MAC draw directly into the Amiga screen?"...well, that
would work, however, what happens when a program goes low level?  Like a
game or graphics program (like some paint programs).  These programs go
to the NuBus video card and fetch the screen's address from the card
directly instead of calling operating system routines.  Obviously, there
is no way to patch every program made to use the Amiga video directly,
and there are over 3,000 routines in color quick draw that would have to
be patched to make the system write directly to Amiga video.  The way we
are doing the video is one level slower than what the MAC really does,
however, we remain 100% compatible with all MAC software this way.  Video
boards like the Resolver, Vivid24, and Rembrandt all use the TI graphics
processor and use chunky format, so we can get real time speeds with
these boards (or anything else that supports SAGE).
 
AGA machines have no DMA contention and a full 32 bit wide access to the
graphics department.  :-)  32 bit access on non-AGA machines are broken
into 2 word accesses which takes substantially more time.  The A4000 runs
our video driver about 30 times faster than my 40Mhz VXL*30.
 


Jim Drew - Vice President, Utilities Unlimited, Inc.
           1641 McCulloch Blvd. Suite #25-124
           Lake Havasu City, AZ  86403
           (602) 680-9004     (602) 680-9006 FAX    (602) 453-9767 BBS
Newsgroups: comp.sys.amiga.emulations