Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!agate!eos!shelby!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Simple Frame Buffer boards
Message-ID: <16654@cbmvax.commodore.com>
Date: 19 Dec 90 01:59:35 GMT
References: <916@boing.UUCP> <23699@grebyn.com> <918@boing.UUCP> <1411@mpirbn.mpifr-bonn.mpg.de> <1990Dec5.165513.16570@eagle.lerc.nasa.gov> <1421@mpirbn.mpifr-bonn.mpg.de>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 16

In article <1421@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes:
>As I said, it is _easier_ to write code for a memory mapped framebuffer
>but doesn't imply major performance loss. Think of a framebuffer addressed
>through the concatenated row and column number which isn't a flat contigous
>memory at all but which is surely faster to access for graphics purposes.

	Worse yet, if you need to access the frame buffer via registers,
you either have to allow only one task to use it (ever), or save/restore
those register on every task swap.  Fun fun fun.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)