• Previous message: cfk: "Re: Unable to allocate 7 planes..."
• Maybe in reply to: Stefan Robert: "magic 7.2 and compile problems with MacOS X"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear Stefan,

> First, I tried the recommended configuration using OpenGL + X11 and I 
> got those error messages when compiling libgraphics.o

Interesting.  These are all real problems---the variables noted are
multiply defined.  They should be moved to the "tkCommon.c" file and
extern'd elsewhere.  I will fix this for the next distribution.
I don't know why MacOS X is the only compiler to pick up on this
error.

> /usr/bin/libtool: can't locate file for: -llibtcl.dylib
> /usr/bin/libtool: file: -llibtcl.dylib is not an object file (not 
> allowed in a library)
> /usr/bin/libtool: can't locate file for: -llibtk.dylib
> /usr/bin/libtool: file: -llibtk.dylib is not an object file (not 
> allowed in a library)

This is an error in the Makefile which I thought I fixed but
apparently I managed to overwrite the fix with an older version
config file.  It will be fixed in today's distribution, and with
any luck, will stay there.

> Yes, to my surprise Matlab 6 installs a version of "ldd". However, 
> since on MacOS X we use "otool", this Matlab version of "ldd" runs 
> "otool" by default. This means that the magic config script finds and 
> believes that I have "ldd" on my mac. This tricks the script into using 
> cfield = 3 instead of cfield = 1 in the config script for this command 
> when the Matlab MacOS X "ldd" is in reality "otool":

Since your fix shouldn't break anything on other systems, I have
implemented it as suggested.  Leave it up to the MathWorks guys to
break UNIX systems. . .

> Now that I got magic to compile on MacOS X, when I run "magic -w 
> -Tmytech" I get this error/warning at the console:
> 
> Magic 7.2 - Compiled on Sun Mar 30 14:53:28 EST 2003.
> Using Tk console window
> Using PseudoColor, VisualID 0x43 depth 8
> Unable to allocate 7 planes in default colormap; making a new one.
> Only 124 contiguous colors were available.
> 
> Then, magic is totally unusable. All colors are mixed up and the layer 
> tablet is also all mixed up.

I get colormap-related problems every time I encounter a new video card
type.  In this case, it is necessary to find out what the underlying
graphics mode is, because there are two ways to run things: 1) pure
8-bit graphics, which works fairly well, 2) overlay 8-bit graphics in
a 24-bit display, which works okay on my desktop, but I have no idea
about other systems.

Assuming that the Mac video card & driver are running in a 24-bit mode
with 8-bit overlays, it will probably take some time to work out the
problems with the colormap.  HOWEVER, if I had to hazard a quick guess,
I would say the following is happening:  In graphics/grX11su1.c and
graphics/grTk1.c, there is a machine-dependant section as follows:

  /* machine-dependent constants - see below */
  #ifdef macII
  #define X_COLORMAP_BASE         128
  #define X_COLORMAP_RESERVED     4
  #else
  #if defined(CYGWIN)
  #define X_COLORMAP_BASE         128
  #define X_COLORMAP_RESERVED     0
  #else
  #define X_COLORMAP_BASE         0
  #define X_COLORMAP_RESERVED     2
  #endif
  #endif

Note the "macII" dependant line at the top.  This has to do with
underlying video hardware for 8-bit pseudocolor visuals, because a
lot of hardware likes to pre-allocate cells for "black" and "white",
and the Mac likes to pre-allocate a couple of shades of gray as
well.  There's no standard for this, so some cards allocate it at
the beginning of the map, and some at the end.  Magic needs 128
contiguous cells, so it can grab the lower half (BASE=0) or the
upper half (BASE=128).  Unfortunately, there is no way (that I know
of) to determine this on the fly.

If you do "set MAGIC_COLOR 24bit" (csh,tcsh) or
"export MAGIC_COLOR=24bit" (bash,sh) before running magic, you
can force 24-bit mode, assuming that you have 24-bit plus an
8-bit overlay.  Otherwise, recompile with the changed BASE and
RESERVED values and see if that changes the color behavior.

I was told that the behavior changed in a recent update to Mac OS-X.
My guess is that the new version added support for 8-bit overlay
planes, which is where the trouble started.  However, believe me
when I say that 8-bit overlay planes are really good to have, for
magic.  The two best video modes for magic to run in are 1) OpenGL,
and 2) 8-bit overlay.

Does anybody know what Mac hardware is compatible with which colormap
BASE and RESERVED values??  The values in the code (BASE=128 and
RESERVED=4) go WAY back, to a MacIIfx which used to sit on my desk at
Stanford.  Probably the hardware changed with the introduction of the
iMac/eMac series, but I haven't played around with those machines
enough to know.

By the way, the missing file in the tutorial directory was caused by
me trying to write more tutorials.  I'm hoping to have a full set of
tutorials outlining running Magic under Tcl, as well as updates to
all of the old tutorials.  The most complete new tutorial is the one
on running IRSIM + magic under Tcl.  There will be an LVS (layout-vs.-
schematic) tutorial coming soon.

That should be enough for you to chew on for a while.

					Regards,
					Tim

• Next message: John Griessen: "magic-7.2.32 tutorials, books"
• Previous message: cfk: "Re: Unable to allocate 7 planes..."
• Maybe in reply to: Stefan Robert: "magic 7.2 and compile problems with MacOS X"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]