jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (06/28/91)
asong@pro-nbs.cts.com (Andi Song) writes: >In-Reply-To: message from jb10320@uxa.cso.uiuc.edu > Are you serious!!??! Get real! :) So technically the IIgs IS >upgradeable in video resolution like the IBM? Now, the hardware is the easy part. Getting the new hardware to work with QuickDraw and old applications is not so easy. > So we could buy this "card" and BAM!, 640x400 (or better)? I >suppose we would have to buy a new monitor. Where would we get that? Would >a Macintosh monitor work or what? You could, but you'd have to write custom programs that only worked with the board until Apple supported it. And that's not likely to happen. -- Jawaid Bazyar | "Twenty seven faces- with their eyes turned to Graduated!/Comp Engineering | the sky. I have got a camera, and an airtight bazyar@cs.uiuc.edu | alibi.." Apple II Forever! | I need a job... Be privileged to pay me! :-)
meekins@anaconda.cis.ohio-state.edu (Tim Meekins) (06/29/91)
In article <1991Jun27.221915.17202@ux1.cso.uiuc.edu> jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) writes: >asong@pro-nbs.cts.com (Andi Song) writes: > >>In-Reply-To: message from jb10320@uxa.cso.uiuc.edu > > >> Are you serious!!??! Get real! :) So technically the IIgs IS >>upgradeable in video resolution like the IBM? > > Now, the hardware is the easy part. Getting the new hardware to >work with QuickDraw and old applications is not so easy. > >> So we could buy this "card" and BAM!, 640x400 (or better)? I >>suppose we would have to buy a new monitor. Where would we get that? Would >>a Macintosh monitor work or what? > > You could, but you'd have to write custom programs that only worked >with the board until Apple supported it. And that's not likely to happen. > Ah, but Apple has published the low-level entry points for QuickDraw II, so it is quite feasable. After all, these all need to be patched to write printer drivers. Since thrid parties have written printer drivers, I don't see why patches in an init couldn't be written for a video. The only problem lies in QuickDraw II's assumption of how palettes are stored and formed. Worse, the number of applications that assume these things.
ujmurphy@KING.MCS.DREXEL.EDU (Jim Murphy) (06/29/91)
Tim Meekins said this, but I'm not in the mood to quote everyone else: ( In respect to the feasibility of adding a QuickDraw II compatible video card ( to the IIGS...) > Ah, but Apple has published the low-level entry points for QuickDraw II, > so it is quite feasable. After all, these all need to be patched to write > printer drivers. Since thrid parties have written printer drivers, I don't > see why patches in an init couldn't be written for a video. The only > problem lies in QuickDraw II's assumption of how palettes are stored and > formed. Worse, the number of applications that assume these things. We do have one other major problem. Certain parts of the toolbox do not use QuickDraw II when drawing to the screen. A perfect example is the Menu Manager in respect to menu caching. It blasts the images right to the screen RAM. This is a major problem, unless it is either changed in the future by Apple to be more friendly, or it can be successfully patched. There are most assuredly other issues, but this is one that is foremost in my mind. Jim Murphy "I know that you believe you understand Internet: ujmurphy@mcs.drexel.edu what you think I said. But I am not sure GEnie: J.MURPHY7 you realize that what you heard is not AOL: Jim Murphy what I meant."
mattd@Apple.COM (Matt Deatherage) (07/01/91)
In article <9106291504.AA14620@mcs.drexel.edu> ujmurphy@KING.MCS.DREXEL.EDU (Jim Murphy) writes: >Tim Meekins said this, but I'm not in the mood to quote everyone else: > >( In respect to the feasibility of adding a QuickDraw II compatible video card >( to the IIGS...) > >> Ah, but Apple has published the low-level entry points for QuickDraw II, >> so it is quite feasable. After all, these all need to be patched to write >> printer drivers. Since thrid parties have written printer drivers, I don't >> see why patches in an init couldn't be written for a video. The only >> problem lies in QuickDraw II's assumption of how palettes are stored and >> formed. Worse, the number of applications that assume these things. > However, although we've published the _main_ QuickDraw bottlenecks that most applications would need to do alternate drawing methods, we haven't published nearly all of them, and certainly not enough to let you invent a new physical drawing paradigm. > We do have one other major problem. Certain parts of the toolbox do not >use QuickDraw II when drawing to the screen. A perfect example is the Menu >Manager in respect to menu caching. It blasts the images right to the screen >RAM. This is a major problem, unless it is either changed in the future by >Apple to be more friendly, or it can be successfully patched. There are most >assuredly other issues, but this is one that is foremost in my mind. > Jim, you're suffering from a delusion that plagues magazine writers from time to time. The rules are created to assist in compatibility with the system software. The System Software can maintain compatibility with itself in whatever way it chooses, including in ways that are not accessible to non-system software programs. The Menu Manager can draw directly to the screen if it wants because it's part of the system software, and it knows as well as QuickDraw does that there's currently only one screen, and that QuickDraw really isn't non-Apple extensible to fix that. If this were to change in QuickDraw, it would probably also change in the Menu Manager. As if that wasn't enough (and it is), you also seem to be forgetting that the Menu Manager would be following external rules totally if it used the information in the locInfo record of the Menu Manager port to determine what pixels in the pixel map a given rectangle will occupy and calculates memory addresses from there. (In fact, it may actually be doing that.) The Menu Manager _has_ to read screen memory directly to cache the image under a menu or it would have to call _RefreshDesktop every time a pull-down menu was released. Fortunately, the Menu Manager _is_ system software and it can do that, and as explained above even non-system software could do this. Sorry to burst your "Apple's breaking it's own rules again bubble," though. :) >Jim Murphy "I know that you believe you understand -- ============================================================================ Matt Deatherage, Developer Technical | The opinions expressed herein are Support, Apple Computer, Inc. | not those of Apple Computer, and Personal mail only, please. Thanks. | shame on you for thinking otherwise. ^^^^^^^^ Technical questions are not personal. Please post them instead. ============================================================================