Path: utzoo!attcan!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Simple Frame Buffer boards
Message-ID: <16324@cbmvax.commodore.com>
Date: 5 Dec 90 19:57:48 GMT
References: <916@boing.UUCP>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 66

In article <916@boing.UUCP> dale@boing.UUCP (Dale Luck) writes:
>Why is it so difficult to design a simple memory
>mapped frame buffer board. I've gotten the specs
>on a couple, like the firecracker and most seem
>to have forgotten that the main cpu of the Amiga
>is 68000 based. Read: FLAT ADDRESS SPACE.

It really isn't very difficult.  The problem depends alot on the design.  Many
of the video controllers on the market like to have total control of the 
memory, so forcing the programmer to go through some register ugliness (like
the 8653/8568 chip in the C128, and other traditional video controllers)
rather than directly to memory simplifies the video controller design.  I
gather than even modern systems like the TI 340 series (especially the 34010)
force the same thing.  The other explanation is that many of the video toys on
the market have been designed with PC Clones in mind, and these babies not 
only have to deal with a 64K maximum segment, but a severe limit on the 
amount of address space that can be devoted to video display.

Neither of these is sufficient explanation, as far as I'm concerned, for why
such ugliness needs to find it's way onto the Amiga.  At least the TI34020
seems to have made provision for a host CPU interaction with memory, though
of course in the TI systems the host CPU needs less involvement anyway.  There
is supposedly a very cool sounding 34020 board coming out from some group in
Germany.  In that it supports real CAD resolutions rather than the typical
video resolution, it interests me personally more than FireCrackers and that
ilk -- I want CAD, not video.

>In my case I would like to support these frame buffer
>boards with the X Window System. Getting it to support
>this architecture is not trivial. I believe such interfaces
>are a step backward.

At least with the TI systems, they provide an interface library.  But you
can bet that going through I/O registers, speed-wise anyway, is going to
be a step backwards.  Ever wonder why 99% of the VGA devices out there are
slow?  It's not because there's no fast CPU around to push pixels around,
nor is it because of CPU segmentation.

>Is anyone doing a simple frame buffer board with VRAM
>to drive a reasonable resolution monitor with at least
>256 colors and a direct memory mapped raster? On the
>A3000 it could even be accessed 32 bits at a time to
>double the speed of operations.

On the 3000, you could in theory get at least 4x the speed of such a board
on the 2000, assuming the video fetch cycle didn't eat too much time.  I
don't have an answer, and actually wish I had some spare time myself to muck
with this.  The 3000 certainly has enough juice in the '030 to drive a video
board as fast as NeXT or the good '030 Suns, and faster than Mac NuBus video
toy.  You should be able to implement most of a simple, dumb video controller
in a handful of PALs and PLDs; depending on the architecture, it's not all 
that much more complicated than a plain old DRAM circuit, which can be done
in three or four PALs.  For example, the sleezy Zorro III DRAM board design
done for last summer's DevCon was something I cooked up in a week.  Taking 
the same simple approach, you would think someone could do a video toy in a
month or two, but I suppose they need to be convinced there's a market for 
it.

>Dale Luck     GfxBase/Boing, Inc.
>{uunet!cbmvax|pyramid}!amiga!boing!dale


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
		      Wheeeeeeeeeeeeeeee...........