Newsgroups: comp.sys.atari.st
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!jato!hanauma.jpl.nasa.gov!hyc
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: Graphics on the STE - v. generally speaking...
Message-ID: <1991Apr5.231704.19657@jato.jpl.nasa.gov>
Sender: news@jato.jpl.nasa.gov
Nntp-Posting-Host: hanauma.jpl.nasa.gov
Organization: SAR Systems Development and Processing, JPL
References: <1991Apr3.051045.1894@ns.network.com> <1991Apr03.150135.26529@chinet.chi.il.us> <40922@cup.portal.com>
Date: Fri, 5 Apr 91 23:17:04 GMT

In article <40922@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes:
>>It seemed reasonable to point out here that VGA uses a minimum of (I hope I
>>have this right) 256 K of screen memory.  I'm rather nearer to certain that
>>most super VGA uses a Meg.  This isn't the sort of thing that would have bee
>>considered reasonable when the ST was designed.
> 
>That's very true..!
> 
>Of course, the ST was designed over *FIVE YEARS* ago, and has never really
>changed since then.. 
> 
>                               ( WHY???)
> 
> 
>An Atari 8-bit screen only took up 8k of RAM...   if you want to take it to
>extremes, an AstroCade only needed 2K to display a full screen..
> 
>Why not change with the times..?  Why not provide competitive graphics
>modes..?

I think that's a good question... Lessee... Lots of systems out there
have 1280x1024 monochrome displays now. There have been 2048x2048 and
larger for the military and other applications for a while too. I just
wonder - if you can draw 1280x1024 = 1.25Mpixels/frame, 60+ times a
second, why can't you do it in color? Doesn't increase the speed requirements,
just the width of the bus...

I would like to build a true-color board that uses, say, 16 bits per pixel
and 8-bit style display lists. Then hardware scrolling in either direction
only becomes a matter of updating display list pointers, instead of copying
huge amounts of pixel memory. I guess there's not much point to having
multiple graphics modes though. (is there?) Lessee, 1.25Mpixels @ 16bits
gives 2.5MBytes/screen. Big deal, memory is cheap. We'll say the board has
16MBytes of memory, enough space for 6 screens plus 1MB for display lists
and palettes/CLUTs. (Ok, 16MBytes *minimum*.)

The display list entries will have to include the address to begin drawing
a scanline from. Let's have an optional flag to include palette and address
changes at arbitrary pixel counts into the scanline - that gives us the
ability to move windows around the screen very rapidly, and allow windows to
have their own independent palettes. All of this can be achieved with a
simple state-machine, so it should be simple to do quickly in hardware.

I was also considering one or two separate bitplanes for text-only, which
would be overlayed simultaneously. (Who needs multicolor text anyway, eh?)
Haven't given much thought to the text-management though, maybe a separate
buffer would be harder to manage than it'd be worth. (But geeze, who wants
to waste cycles scrolling 24-bitplanes worth of *text*??)

Hm... Is there a practical use for 64K colors out of a larger palette? Mebbe
8 bits per pixel is sufficient, especially given that palettes can be switched
on the fly. Mebbe there *is* a reason for multiple modes... Oh well.

It seems to me that most of today's workstation vendors spend so much time
on how to draw things into their frame buffers, (Oooo, we can do 6 trillion
shaded polygons per second!) but no time at all thinking about what they
can do with the frame after it's been drawn - no thought spent on panning,
zooming, rotation, what-have-you... The display-list idea is incredibly
powerful. Have another option for memory-increment to next pixel - this
gives you the ability to do instantaneous reductions (zoom-out), as well
as 90-degree rotations (corner-turns) just by choosing the appropriate
increment. Use another option for pixel-replication, with a count, and you
get instant expansion (zoom-in). All of this can be implemented with just
an adder/counter circuit and maybe a couple more address registers.

Oops. Keyboard run-on again... Well anyway, if I ever get this thing
built, I'm sure y'all will find out about it. }-)
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
	Disclaimer: How would I know, I just got here!
