taob@pnet91.cts.com (Brian Tao) (04/19/91)
I downloaded the TurboBee demo from tiberius FTP las night, and it turns out it is written by the Synnovision people. Does anyone know what the current state of their TurboRez project is? The doc file says they were demoing a second prototype last year (at KFest maybe?) using this bee demo. Any information regarding their enhanced video card for the GS would be greatly appreciated. Brian T. Tao *B-) | t569taob@bluffs.scar.utoronto.ca | "Though this be U of Metro Toronto | - or - | madness, yet there Scarberia, ON | taob@pnet91.cts.com | is method in 't."
ujmurphy@mcs.drexel.edu (Jim Murphy) (04/19/91)
In article 12801 taob@pnet91.cts.com (Brian Tao) asked: > I downloaded the TurboBee demo from tiberius FTP las night, and it turns > out it is written by the Synnovision people. Does anyone know what the > current state of their TurboRez project is? The doc file says they were > demoing a second prototype last year (at KFest maybe?) using this bee demo. > Any information regarding their enhanced video card for the GS would be > greatly appreciated. The second prototype of the TurboRez card was demonstrated at AppleFest Spring '90 in New Jersey. At that time the problem with the project was a lack of financial backing to get it manufactured. I have no information on what the current status of it is, but I'd hazard a guess that we won't be seeing it soon. The major question that arose at the time was if it would be capable of supporting QuickDraw II. Since QD II does not currently support third-party video cards (or even the 400 line mode with the VOC for that matter), this question should be directed at Apple. In my opinion, it should not be the responsibility of a third-party developer to patch QD II to work with their card. Opinions anyone? Jim Murphy CoOp - Software Quality Assurance Internet: ujmurphy@mcs.drexel.edu Reality Technologies, Ltd. GEnie: J.MURPHY7 Philadelphia, PA
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/19/91)
ujmurphy@mcs.drexel.edu (Jim Murphy) writes: > The major question that arose at the time was if it would be capable of >supporting QuickDraw II. Since QD II does not currently support third-party >video cards (or even the 400 line mode with the VOC for that matter), this >question should be directed at Apple. In my opinion, it should not be the >responsibility of a third-party developer to patch QD II to work with their >card. Opinions anyone? Apple keeps shuffling their feet when we talk about this. I think they are either afraid to deal with all the hardcoded crud in the toolbox (especially the interface -- Dave Lyons can probably give few examples that would break if 256 colors were present on screen, but won't share any ideas as to new toolbox calls to do the job, like MenuNewRes2 or something along those lines), or they are trying to keep us from developing it on our own and getting burnt. Todd Whitesel toddpw @ tybalt.caltech.edu
dlyons@Apple.COM (David A. Lyons) (04/19/91)
In article <1991Apr19.051118.5726@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >ujmurphy@mcs.drexel.edu (Jim Murphy) writes: >>[recommends Apple provide QuickDraw II support for the video overlay card >> and perhaps 3rd-party cards] > >Apple keeps shuffling their feet when we talk about this. I think they are >either afraid to deal with all the hardcoded crud in the toolbox (especially >the interface -- Dave Lyons can probably give few examples that would break >if 256 colors were present on screen, but won't share any ideas as to new >toolbox calls to do the job, like MenuNewRes2 or something along those lines), >or they are trying to keep us from developing it on our own and getting burnt. > >Todd Whitesel >toddpw @ tybalt.caltech.edu Rather than take offense at the above, I will explain my point of view. (1) If QuickDraw were modified to support a nonlinear screen buffer, or to support pixel depths other than 2 or 4, a large fraction of existing software would be incompatible with the new modes. Adding new toolbox calls does not make incompatible software any more compatible. With the current set of calls, it is already possible for an application to make a few checks about the drawing environment and special-case drawing directly to the screen if necessary for speed, but to use QuickDraw to be -safe- if it detects at runtime that there is something different about the environment. (2) The video overlay card is not dirt-cheap, and there aren't billions and billions of them out there. (3) If we patch out the Menu Manager to make it not hard-code any screen addresses, all the ROM 3 folks who *don't* use a special video card would be paying an pointless penalty in RAM space and execution speed. (4) Having more than one screen size and more than one aspect ratio would wreak havoc with several areas. Everything would look squashed in most applications. Applications that, say, save the locations of your windows and re-open them in the same place could easily open a window partly or totally offscreen, or draw icons offscreen, if the saved information comes from a different configuration. The system could partially but not completely compensate for that. (5) There is no shortage of toolbox enhancements that will benefit a wide audience of developers and customers. For these reasons, investigation of video card support is not high on my priority list. It's on there, but not high. -- 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.
mcgurrin@MWUNIX.MITRE.ORG (04/19/91)
Dave, I assume many of the problems you mention are do to the fact that video cards with differing resolutions were not taken into account when quickdraw II was originally designed? Excuse my lack of knowledge, but I'm wondering why the GS is different than the Mac, where there are lots of video interface cards supporting lots of different resolutions and # of colors?
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/20/91)
I did not mean to offend you, Dave, I was stating an observation. Thank you for finally giving us an indication of what Apple's view is. Now I can get on with other things (like LHG, an Application standard for frame buffer drivers that assumes direct access and not a toolbox, and TCP/IP drivers). Todd Whitesel toddpw @ tybalt.caltech.edu
dlyons@APPLE.COM (David A. Lyons) (04/20/91)
The main part of the problem is that a large fraction of commercial and other applications *bypass QuickDraw* and write directly to the screen. If this problem were solved, then using 640x400 on the video overlay card would be a problem because everything drawn would be squashed to half height. (On the mac you always have square pixels; resolution changes but aspect ratio does not.) --Dave
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/20/91)
dlyons@APPLE.COM (David A. Lyons) writes: >The main part of the problem is that a large fraction of commercial and >other applications *bypass QuickDraw* and write directly to the screen. >If this problem were solved, then using 640x400 on the video overlay card >would be a problem because everything drawn would be squashed to half >height. (On the mac you always have square pixels; resolution changes >but aspect ratio does not.) Two things: I do not care about using the VOC for desktop stuff. I have no wish to squint or buy sunglasses or whatever because of the flicker. I want info on Supervisor drivers so I can write one to arbitrate for use of the second VOC video buffer for a subtitler and a picture viewer. QuickDraw support would better be spent on a 640x400 VGA card that does 16 or more colors and fools the toolbox into thinking it is in 320 mode with the palette calls modifying a subset of the truly available colors. Eventually, GS/OS drivers following a naming and calling convention could be used to expand quickdraw's internal 1 bit images onto the hardware in the current pixel depth. Correct me if I'm wrong, Dave, but Quickdraw internally renders nearly everything in 1 bit and then copies it to the screen while expanding the pixel depth on the fly (using tables or some such). A video card that would let you write 1 bit images to it and automatically write 1's or 0's (or both) to memory from foreground and background color registers would be really cool and it would speed up one thing about QD that makes text rather slow to render. Todd Whitesel toddpw @ tybalt.caltech.edu
dlyons@Apple.COM (David A. Lyons) (04/20/91)
In article <1991Apr19.210948.6287@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >[...] >Thank you for finally giving us an indication of what Apple's view is. > >Now I can get on with other things (like LHG, an Application standard for >frame buffer drivers that assumes direct access and not a toolbox, and TCP/IP >drivers). You're welcome. However, remember that I don't speak for Apple in any official capacity. (I believe my engineering observations to be valid, though.) I wish more developers used QuickDraw, with special-cased direct hardware access if necessary so that their applications run fast today and remain compatible with any future GS architectures. That is, GS software could find itself running in an environment where it does *not* know how to access the screen directly, but where QuickDraw is very fast. I am not implying plans for any particular products--I'm only preaching the "use the toolbox, be more flexible" philosophy. -- 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.
rhood@pro-gsplus.cts.com (Robert Hood) (04/20/91)
In-Reply-To: message from dlyons@Apple.COM Concerning your recent post concerning the reasons not to upgrade QuickDraw to be compatible with the VOC, I am about to show my ignorance. Would it be impossible or otherwise prohibitive to package another version of QuickDraw with the VOC, to be installed as a RAM-based tool? In other words, could an alternate QuickDraw be written that would take "normal" QD calls and modify 'em to take maximum advantage of the VOC? I admit, I know next to nothing about the GS in this respect, but if you don't ask stupid questions, you'll never get intelligent answers. ---- ProLine: rhood@pro-gsplus | "Wherever you go...there you are." Internet: rhood@pro-gsplus.cts.com | -- Buckaroo Banzai UUCP: crash!pro-gsplus!rhood | Wanted: An unZIPper for a II! ARPA: crash!pro-gsplus!rhood@nosc.mil | If you have one, let's chat!
gwyn@smoke.brl.mil (Doug Gwyn) (04/21/91)
In article <9104200324.AA14018@apple.com> dlyons@APPLE.COM (David A. Lyons) writes: >The main part of the problem is that a large fraction of commercial and >other applications *bypass QuickDraw* and write directly to the screen. Right, but the standard screen is still supported, even though I have a VOC installed. (I'm looping the motherboard sync to the VOC.) >If this problem were solved, then using 640x400 on the video overlay card >would be a problem because everything drawn would be squashed to half >height. (On the mac you always have square pixels; resolution changes >but aspect ratio does not.) Whether or not the pixels appear "square" is a function of many things, and anyway it is not a big deal for most purposes. I would rather have twice as many vertical lines of resolution than preserving the current images (and the current fonts are overly "tall", in my opinion, due to low vertical resolution).
taob@pnet91.cts.com (Brian Tao) (04/21/91)
From dlyons@APPLE.COM (David A. Lyons): > If this problem were solved, then using 640x400 on the video overlay card > would be a problem because everything drawn would be squashed to half > height. (On the mac you always have square pixels; resolution changes > but aspect ratio does not.) But 320x200 has the same aspect ratio as 640x400, but icons still turn out OK (i.e., in the Control Panel). Things might look squashed, but at least nothing will run off the right side of the screen, since there are still 640 pixels across. Besides, having 640x400 resolution does not preclude the application from using 640x200. Existing apps would still call up the 640x200 mode in QuickDraw II, and any new programs can take advantage of the higher video. Brian T. Tao *B-) | t569taob@bluffs.scar.utoronto.ca | "Though this be U of Metro Toronto | - or - | madness, yet there Scarberia, ON | taob@pnet91.cts.com | is method in 't."
dlyons@Apple.COM (David A. Lyons) (04/22/91)
In article <1991Apr20.060038.22563@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >[...] Correct me if I'm wrong, Dave, but Quickdraw internally >renders nearly everything in 1 bit and then copies it to the screen while >expanding the pixel depth on the fly (using tables or some such). Yes, this is correct for text drawing only. For everything but text, there is a pen pattern and pen mask to apply, so doing 1-bit stuff wouldn't help. (And when you're drawing Shaston 8 in 640 and no clipping happens, it uses FastFont, which is already expanded to 2 bits deep and is preshifted for all possible offsets within a byte.) -- 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.
dlyons@Apple.COM (David A. Lyons) (04/22/91)
In article <8694@crash.cts.com> rhood@pro-gsplus.cts.com (Robert Hood) writes: >Would it be impossible or otherwise prohibitive to package another version >of QuickDraw with the VOC, to be installed as a RAM-based tool? In other >words, could an alternate QuickDraw be written that would take "normal" QD >calls and modify 'em to take maximum advantage of the VOC? Yes, that would be possible (it addresses my point that you wouldn't want the "regular" users to pay a performance penalty for hardware they don't have). The downside would then become supporting two versions of QuickDraw (maybe two per ROM version?) and also testing them, not only by themselves but in combination with other products, both Apple-labeled and third party. So it's a possibility, but it probably wouldn't be my first choice. -- 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.
dlyons@Apple.COM (David A. Lyons) (04/22/91)
In article <636@generic.UUCP> taob@pnet91.cts.com (Brian Tao) writes: >But 320x200 has the same aspect ratio as 640x400, but icons still turn out >OK (i.e., in the Control Panel). Things might look squashed, but at least >nothing will run off the right side of the screen, since there are still 640 >pixels across. "DrawIcon" style icons are always 16 colors per pixel; they are different width in 320 mode vs. 640 mode. A video-overlay 640x400 would have to be 4 colors, not 16. -- 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.