jg2f+@andrew.cmu.edu (Jude Anand George) (05/01/88)
Help!!! I have two video cards in my Mac II, a 16-bit one driving an Apple color monitor and a 4 bit one driving an Apple greyscale monitor. I have recently upgraded the latter from 4 to 16-bit, expecting to get 256 shades on each monitor. Not so. Although they both show up as having 256 in the 'monitors' CDEV, one will display 256 while the other displays something between 16 and 256. The one that works properly is always the monitor that currently has the menu bar set to it (with the monitors CDEV); therefore it doesn't seem to be hardware dependent. Also, if I take either video card out and just use the other one, it works fine, with the maximum 256 colors. (I am testing this by running the MandelColor program). The problem isn't with the individual monitors, either, since I have swapped them and the problem remains the same. I have also put the cards in various slots with no effect. It seems to be dependent only on which monitor currently has the menu bar in it (i.e., is the main screen). It does not depend on whether or not I have it set to color or greyscale in the CDEV. If you know anything about Mac II video, please help! I especially need to know soon if it is a hardware problem, because the warranty on one of my video cards runs out in 4 days. --Jude George INTERNET: jg2f@andrew.cmu.edu CIS: 72307,1752 By the way, if it will help your diagnosis, I have the old ROMs, and am using QuickerGraf v1.0. It also doesn't seem to be a software problem, because I replaced the system files, and got the same results. I went into ResEdit to look at the scrn resource in the system anyways, and this is what it gives me: scrn ID=0 from System Num devices=2 **** sRsrc type $0001 Nubus slot (card slot+8) $0009 dctlDevBase $F9900000 mode sRsrcID 131 flagMask ($77FE) $77FE Is active 1 Is main scrn 1 Is color 1 CLUT rsrcID -1 gamma corr. rsrcID -1 Glob. rect 0 0 480 640 control calls 0 **** sRsrc type $0001 Nubus slot (card slot+8) $000A dCtlDevBase $FAA00000 Mode sRsrcID 131 flagMask ($77FE) $77FE Is active 1 is main scrn 0 is color 0 CLUT rsrcID -1 gamma corr. rsrcID -1 Glob. rect 0 640 480 1280 control calls 0
olson@endor.harvard.edu (Eric K. Olson) (05/02/88)
In a recent article Jude Anand George writes: >I have two video cards in my Mac II, a 16-bit one driving an Apple color >monitor and a 4 bit one driving an Apple greyscale monitor. I have recently >upgraded the latter from 4 to 16-bit, expecting to get 256 shades on each >monitor. Not so. Although they both show up as having 256 in the 'monitors' >CDEV, one will display 256 while the other displays something between 16 and >256. The one that works properly is always the monitor that currently has the >menu bar set to it (with the monitors CDEV); therefore it doesn't seem to be >hardware dependent. Also, if I take either video card out and just use the >other one, it works fine, with the maximum 256 colors. (I am testing this by >running the MandelColor program). The problem isn't with the individual >monitors, either, since I have swapped them and the problem remains the same. >I have also put the cards in various slots with no effect. It seems to be >dependent only on which monitor currently has the menu bar in it (i.e., is the >main screen). It does not depend on whether or not I have it set to color or >greyscale in the CDEV. What you are experiencing is due in part to poor programming in the software you are using to test, and in part due to Apple's not providing a simple way to do things correctly. Everything on a Mac II has a CLUT. PixMaps (multi-bit Bitmaps), Windows, Cursors, and Video Cards all have CLUT (color lookup tables). In order to display a PixMap on a monitor EXACTLY the way it was intended to look, the video card's CLUT must match the PixMap's CLUT. Apple provides two disjoint methods of setting the video card's clut: The Color Manager, and the Palette Manager. In the Color Manager model, the programmer explicitly sets the colors in the video card's CLUT. If there are two video cards, the programmer must set both CLUTs appropriately. In the Palette Manager model, the programmer associates a CLUT with a window and calls ActivatePalette() in response to a window becoming frontmost. The Palette Manager determines which video card(s) the window exists on and sets the CLUTs appropriately. For 256-gray-level images, the CLUT should just be set to a ramp, where Black = R 0, G 0, B 0, and White = R 65536, G 65536, B 65536, and an even distribution of Grays in between. Unfortunately, Apple has provided no way to tell the Palette Manager that a window requires EXACTLY a particular CLUT, with entries in a particular order. Had Apple done this (and had they released the Palette Manager interfaces earlier), many programs that don't work on multiple screens now might have had a fighting chance. My own code goes to great pains to emulate the Palette Manager's behavior, but with the ability to set a video card's CLUT EXACTLY. It is possible to get the Palette Manager to set all the colors in the video card's CLUT, but not in a particular order. This slows down Blitting to the screen significantly. Most code just sets the MainDevice's CLUT explicitly (this is what you are seeing). Blits onto other screens (whose CLUTs are still the Apple default) show about 12 Grey levels, because that's how many are in the default CLUT. The system software is VERY good about always showing you the best fit it can manage for the CLUTs it has to work with. There are other problems with multiple screens: the most annoying is that Pop-Up menus ALWAYS appear on the screen with the MenuBar. Apparently the Menu Manager doesn't know how to deal with multiple screens. Getting your software to work well with multiple screens is no easy task. -Eric Lexington Software Design: Tomorrow's Software Yesterday Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)
tecot@Apple.COM (Ed Tecot) (05/10/88)
[ The following is from Art Cabral, who wrote the Palette Manager. ] Here are some thoughts in response to Eric Olson's comments on explicitly ordered indexes, the Palette Manager, and the Color Manager. (Nice explanation, Eric; your analysis was very good.) Here are a couple of tricks Eric didn't mention that are not well tested but which should work. First, it is possible (although clumsy) to arrange for explicit indexes on each device and still use the Palette Manager model. To start with, when your application becomes active (under MultiFinder or SingleFinder) call the Color Manager routine SetEntries to set an explicit color environment on each device where your window(s) are drawn. You'll have to do some work to figure this out, namely by intersecting the device rects with your window's global portRect. We consider it discourteous to simply change all device's color tables whether your window uses them or not. Then, make sure the palette in your window exactly matches the ordering of the 'clut' you used in the SetEntries calls. Then force an ActivatePalette on your window. The Palette Manager will examine each of the devices and discover that the environment is sufficient and not cause any changes, so your indexes end up in the right order and everyone is happy, right? Almost. You've lost updates in the background. This is a problem when you are running under MultiFinder. The trick is to get the Palette Manager to generate the updates for you. So, during the SetEntries call, use a 'clut' that is almost correct, say one color (not black or white) is just a few insignificant bits away from what you need, and let the Palette Manager correct that for you, causing updates for everyone else on that device that needs them. This requires using a palette that has all entries pmTolerant with tolerance of 0. Make sure your 'clut' keeps white at entry 0 and black as the last entry or Color QuickDraw will exhibit some strange behavior. Also, try to avoid using two colors which match exactly, especially white or black. We hope to provide an alternate, more straightforward method for generating this sort of behavior, but it requires some changes in the Window Manager so you won't see it in the immediate future. At the same time we hope to provide a better method of palette prioritization so the same scheme will work when devices of different depths are encountered. Stay tuned to a system disk near you. In addition, stay on the lookout for a TechNote from MacDTS which describes many interesting changes and additions to the Palette Manager (such as the Application Palette and the routine CopyPalette). [ End of Art's comments ] >There are other problems with multiple screens: the most annoying is that >Pop-Up menus ALWAYS appear on the screen with the MenuBar. Apparently the >Menu Manager doesn't know how to deal with multiple screens. It does now. This has been fixed for System 6.0. _emt