tamir@LOCUS.UCLA.EDU.UUCP (02/05/87)
Does anybody have Magic running on a Sun 110 ? If so, is it the same code (the same binary) that runs on a Sun 160 ? Are there any problems with it ? I saw a message somewhere (perhaps on this mailing list) indicating that there are problems with Magic on the Sun 110. Yuval Tamir Internet: tamir@cs.ucla.edu UUCP: ...!{ihnp4,ucbvax,sdcrdcf,trwspp}!ucla-cs!tamir
smb@MIMSY.UMD.EDU.UUCP (02/05/87)
I tried to run Magic on a 110, but it always came up in black and white mode. I was working on a demo system running Sun 3.2. I traced the problem to the way Magic determines what type of display it is running on. On Suns, Magic does a FBIOGTYPE ioctl on /dev/fb which returns the frame buffer type (amoung other things). The 110 *should* return FBTYPE_SUN4COLOR, but instead returns FBTYPE_SUN2BW. Apparently, the system doesn't know about the on-board frame buffer (/dev/cgfour0). I checked the EEPROM settings for the frame buffer default, but to no avail. I have not been able to try Magic on a real (non-demo) 110 running 3.2. I had hoped that the demo unit had a buggy version of 3.2. Also, I was not able to work around this bug, as I couldn't get the source code for Magic onto the 110. Steve Burinsky smb@mimsy.umd.edu
davis@unc.UUCP (02/06/87)
> Does anybody have Magic running on a Sun 110 ? > If so, is it the same code (the same binary) that runs on a Sun 160 ? > Are there any problems with it ? > > Yuval Tamir We at the University of North Carolina have magic running on our sun 3/110c's. We are currently running a pilot version of release 3.2 of the sun operating system (bsd 4.2 based). Without modification, the code we were using for our 3/160c ran as though the 3/110c was a color machine. We recompiled magic on a 3/110. We used standard sun 3 source (1986 as it comes off the tape + Bob Mayo's fixes for sun3 + latest version of scmos tech file). We have done two versions one without and one with the extract bug fix recently redistributed, no problems associated with that. There is one minor additional problem. The version of the operating system thinks that a 3/110c is a black and white sun (as identified by the ioctl calls). This is an additional problem to recompiling on a sun 3/110. To solve this problem, specify the device as a sun160 when invoking magic. ( magic -d SUN160 ...). Hopefully this problem will be fixed in the standard release 3.2 which our systems people just got and are installing now. By the way, the binaries for the 3/110c work fine on the 3/160c. -Mark
david@david.UUCP (02/06/87)
In article <8702052032.AA08704@mimsy.umd.edu> smb@MIMSY.UMD.EDU (Steve M. Burinsky) writes: >I tried to run Magic on a 110, but it always came up in black and white mode. >I was working on a demo system running Sun 3.2. I traced the problem to >the way Magic determines what type of display it is running on. On Suns, >Magic does a FBIOGTYPE ioctl on /dev/fb which returns the frame buffer >type (amoung other things). The 110 *should* return FBTYPE_SUN4COLOR, >but instead returns FBTYPE_SUN2BW. Apparently, the system doesn't know >about the on-board frame buffer (/dev/cgfour0). I checked the EEPROM settings >for the frame buffer default, but to no avail. Wrong, ioctl breath! In order to allow pre-3.2 programs to run on the 110 (albeit in monochrome mode), the cg4 frame buffer emulates a bw2. The easiest way for a pixrect program to determine if it's running on a color frame buffer is to do a pr_open() and look at the depth of the returned pixrect. (If you want to get fancy you can use pr_available_plane_groups()). If you can't modify Magic, here's a program which will lock the frame buffer in its native (FBTYPE_SUN4COLOR) mode: /* * cg4lock -- locks cg4 in native mode */ #include <stdio.h> #include <sys/file.h> #include <sys/types.h> #include <sys/ioctl.h> #include <sun/fbio.h> #define error(args) { printf args ; exit(1); } main(argc, argv) int argc; char *argv[]; { char *dev; int fd; struct fbgattr attr; dev = argc > 1 ? argv[1] : "/dev/fb"; /* open frame buffer */ if ((fd = open(dev, O_RDWR)) < 0) error(("%s: open failed for %s\n", argv[0], dev)); /* * get attributes, make sure it's a cg4 and not * owned by another process */ if (ioctl(fd, FBIOGATTR, &attr) == -1) error(("%s: get attributes failed for %s\n", argv[0], dev)); if (attr.real_type != FBTYPE_SUN4COLOR) error(("%s: device %s is not a cg4\n", argv[0], dev)); if (attr.owner != 0) error(("%s: device %s is owned by process %d\n", argv[0], dev, attr.owner)); /* set emulation type to cg4 */ attr.sattr.flags = 0; attr.sattr.emu_type = FBTYPE_SUN4COLOR; if (ioctl(fd, FBIOSATTR, &attr.sattr) < 0) error(("%s: set attributes failed for %s\n", argv[0], dev)); while (1) sleep(30000); } Run it in the background, then start your pixrect program. For more information on the cg4, emulation mode, etc. refer to the SunOS 3.2 release manual. Disclaimer: No one else at Sun understands this, so how could they be responsible for it? -- David DiGiacomo {decvax, ihnp4, ucbvax}!sun!david david@sun.arpa Sun Microsystems, Mt. View, CA (415) 691-7495 David DiGiacomo {decvax, ihnp4, ucbvax}!sun!david david@sun.arpa Sun Microsystems, Mt. View, CA (415) 691-7495
berry@solaria.UUCP (02/06/87)
In article <8702052032.AA08704@mimsy.umd.edu> smb@MIMSY.UMD.EDU (Steve M. Burinsky) writes: >I tried to run Magic on a 110, but it always came up in black and white mode. We run Magic (4.33(LP)) on SUNs with 3.2, including 3/110C's and it works fine. Color and everything! With our version it is necessary to specify "-d SUN110" on the command line whan starting up Magic. -- "We can't stand around doing nothing -- people will think we're workmen!" Prof. Ned Quatermass -- Berry Kercheval -- berry@mordor.s1.gov -- {ucbvax!decwrl,siesmo}!mordor!berry Lawrence Livermore National Laboratory, Special Studies Program ("O" division)