Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!ncsuvx!mcnc!rti!xyzzy!poirier
From: poirier@dg-rtp.dg.com (Charles Poirier)
Newsgroups: comp.sys.amiga
Subject: Re: How about Sliced EHB ??
Summary: SHAM is not cpu-intensive
Message-ID: <1325@xyzzy.UUCP>
Date: 11 Dec 89 23:29:03 GMT
References: <568@h.cs.wvu.wvnet.edu> <8912030118.AA15320@en.ecn.purdue.edu>
Sender: usenet@xyzzy.UUCP
Reply-To: poirier@ellerbe.dg.com (  Poirier local)
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 55

In article <8912030118.AA15320@en.ecn.purdue.edu> bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) writes:
>In article <568@h.cs.wvu.wvnet.edu>, dbl@a.cs.wvu.wvnet.edu writes:
>>    Ok, heres an idea (and I hope no one has been posting this to death)
>>how about a sliced Extra Halfbrite display?  If sliced ham can be done
>
>Is it just me, or is anyone else out there getting disturbed by all of the
>dynamic/sliced/diced/minced display modes involving cpu-intesive activity,
>just to bring up the image?  I mean, what are things migrating toward here?

Actually, SHAM does not use the CPU any more than any other mode.  The
change of color registers at each line is accomplished automatically
by the copper (one of Amiga's coprocessors), without cpu intervention.
The copper list (set of instructions to the copper) is precomputed and
doesn't need massaging during SHAM display.  Because of the high number
of bitplanes (usually 6), SHAM and HAM do steal memory cycles from the cpu,
in effect slowing it, but that is a limitation of the memory bandwidth.

What are things migrating toward?  More complete utilization of the
machine's abilities.  I'm surprised it has taken this long for an
enterprising hacker to bring up SHAM.  There are other hardware abilities
that are underused, too.  Who has done anything with the audio channels'
abilities to amplitude-and/or-frequency-modulate another audio channel?
(Possibly the narrator device does, I don't know.)

>SHAM is not a friendly or very practical thing to be working with (in paint
>programs,

SHAM is basically as practical as HAM, which some paint programs do just fine.

>or for that matter, for anything on this *multitasking* machine).

If SHAM and Intuition don't get along, it is a definite problem.  But it is
the current incarnation of Intuition wherein the problem lies, in my opinion.
Intuition ought to support as completely as possible the Amiga's screen
possibilities, including SHAM, overscan, dual-viewport, and double-buffering.
And sliced-extra-half-bright if such a thing is feasible.  (16 x 2 SEHB
ought to be easy enough, 32 x 2 SEHB would drag in interactions between
successive lines since only 15 color registers can be changed per horizontal
retrace interval.)

>We definitely need drastically improved graphics in the A3000.  That's all I
>can say.
>| Jeff Bevis
>| bevis@en.ecn.purdue.edu

Probably true.  Just one contrary point: up to now we have maintained
total compatibility (memory aside) between all Amigas.  If Commodore put
out a nice premium graphics machine, it would be a shame to lose that
total compatibility.  On the other hand (plot, scheme), having incompatible
classes of Amiga software might result in the allocation of more Amiga
retail shelf space.  (Remember when there was just one brand of Coke?)  :-)

	Cheers,
	Charles Poirier

Disclaimer: I own some Commodore stock, big deal, I still says what I thinks.