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!