wogg0743@uxa.cso.uiuc.edu (William Shakespeare) (04/20/91)
Actually, it would be easier to support larger bitmaps than one would at
first imagine. Actually, I should say better resolution on a large bitmap.
If one were to put a large video buffer in, for instance, bank $E2, filling
the entire bank (ie., the buffer is twice normal SHR size), and assuming
the hardware to support the buffer existed, the ROM graphics routines could
be used to draw to it, with some minor complications.
Here's how:
The ROMs support 4 or 16 color images (2 or 4 bit planes) and when not
drawing to the normal SHR screen can handle any screen width, as long as
it involves a multiple of 8 bytes (160 bytes/line normally for SHR). This
feature is to support off-screen bitmaps, but code be used to support a
third party graphics card instead, provided that it used either 2 or 4
bit planes. I assume that there is a practical limitation of 64k for
such a buffer, but it would still allow QD to support modes like
o 640x200x16 colors
o 320x400x16 colors
o 640x400x4 colors
Obviously, someone would have to produce the hardware to support such a
beast, but one should not think that QD would hinder the production of
higher resolution graphics on the GS, though it would limit available
colors (QD only will understand 16).
There is a hitch involved with toolset which expect the screen to be in
specific place (didn't someone says something about the menu manager?)
But these things could most likely be worked around.
Anyway, just something for you hardware hackers to consider the next time
you're throwing together a graphics board.
--
William ("Shakespeare") Gulstad / So where are the C.S. babes?
wogg0743@uxa.cso.uiuc.edu / Joni Mitchell for President!
I vote, so I can complain! / Did you vote? Then don't complain!
Republican is the opposite of democracy! / Tune in, drop out, log on.dlyons@Apple.COM (David A. Lyons) (04/22/91)
In article <1991Apr20.070832.24635@ux1.cso.uiuc.edu> wogg0743@uxa.cso.uiuc.edu (William Shakespeare) writes: >Actually, it would be easier to support larger bitmaps than one would at >first imagine. Actually, I should say better resolution on a large bitmap. >If one were to put a large video buffer in, for instance, bank $E2, filling >the entire bank (ie., the buffer is twice normal SHR size), and assuming >the hardware to support the buffer existed, the ROM graphics routines could >be used to draw to it, with some minor complications. All true, given the appropriate hardware. In fact, a third party could -easily- patch QuickDraw to work with a larger screen buffer, given that the buffer is still linear, still 2 or 4 bits per pixel (BTW, the VOC does not provide a linear buffer for 640x400). InitPort and OpenPort are probably the only routines you'd have to patch. There would be a performance hit because (1) you're dealing with more memory and (2) parts of QuickDraw are optimized for the $x12000 160-bytes-per-scanline screen, but with a fast accelerator it would be usable (with applications that use QuickDraw). >[...] I assume that there is a practical limitation of 64k for >such a buffer If there is, it's news to me! QD is actually supposed to work with >64K pixel maps without problems. This has not been tested as well as the normal case of a 32K screen; maybe there are problems. >There is a hitch involved with toolset which expect the screen to be in >specific place (didn't someone says something about the menu manager?) Yes, the Menu Manager currently "knows" where the screen is. I'm not happy with that, and I expect someday the Menu Manager will be more friendly to QuickDraw. Oh, the other thing is cursor tracking--QuickDraw's cursor handling code also knows where the screen is and would have to be patched out. >William ("Shakespeare") Gulstad / So where are the C.S. babes? >wogg0743@uxa.cso.uiuc.edu / Joni Mitchell for President! -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II System Software Engineer | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.