[comp.lsi] Magic on a Sun 110?

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)