Path: utzoo!attcan!uunet!husc6!mit-eddie!killer!elg
From: elg@killer.DALLAS.TX.US (Eric Green)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <5110@killer.DALLAS.TX.US>
Date: 7 Aug 88 02:47:05 GMT
References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu> <1189@ficc.UUCP> <3084@tekig5.PEN.TEK.COM>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 30

In message <3084@tekig5.PEN.TEK.COM>, wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) says:
>In article <1189@ficc.UUCP>, peter@ficc.UUCP (Peter da Silva) writes:
>> 
>> The Blitter can be used to pump LIFE along at a bit over 20 generations
>> per second. The 68000 can't hope to catch up. How's the 68030?
>
>Okay, so how does blitter help if the cell array is the frame buffer.  I
>mean it seems kind of a waste to work in an array and then to move it 
>out to the frame buffer.  

The Amiga blitter is in "chip" memory (the memory also accessible by
the video chip and other custom DMA devices, e.g. the sound DMA
channel which runs around 32khz or so). I assume that this is what you
are referring to as a "frame buffer". In the microcomputer world,
generally the video memory is in the same addressing space as the rest
of CPU memory -- it's just on an isolated bus, where video refresh
cannot interfere with CPU operations (at least in the case of IBM PC
type thingys, and, partially, the Amiga). In any event, blitter memory
and "video" memory are the same, so there's no need to do any moving.
I assume that this is the case with most viable blitter systems.

In the microcomputer world, "frame buffers" are generally associated
with "frame grabbers", i.e., video frame digitizers. Perhaps this is a
case where workstation/Sun terminology slams into conflicting
microcomputer terminology?

--
Eric Lee Green    ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg
          Snail Mail P.O. Box 92191 Lafayette, LA 70509              
       MISFORTUNE, n. The kind of fortune that never misses.