Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!garnett
From: garnett@cs.utexas.edu (John William Garnett)
Newsgroups: comp.sys.next
Subject: memory, LUTs, and a strangeness
Keywords: 040 memory color lut troubleshooting
Message-ID: <1031@nada.cs.utexas.edu>
Date: 18 Dec 90 02:18:20 GMT
Organization: UT at Austin, Dept. of CS
Lines: 37

This is a multi-part question with each part not necessarily related
to the other parts. 

1) will third-party RAM chips which work in the 030 NeXT cube also work in
the 040 NeXT cube?  In particular, if a particular brand of SIMMS will fit
in the 030 cube, will they also fit in the 040 cube?

2) some time ago there was a non-trivial amount of discussion relating
to the color capabilities of the Color NeXTstation.  As I remember it,
one of the commonly stated criticisms was that the Color NeXTstation
didn't offer a LUT chip.  However, someone recently informed me that
they remember someone posting that it (the Color NS) did offer a
LUT chip.  Does anyone know the whole story?  Does the color NeXTstation
have a LUT chip?  If so, is this chip accessible to the programmer?  If
not accessible to the programmer, how does the system use the chip?  Suppose
that I create an image that only uses 256 colors (or some number less than
the LUT will index).  Will the LUT (if it exists) allow more than 4 bits
per color component (R, G, and B) for this image?

3) Today, I had a cube refuse to boot from the optical (this is an optical +
40 MB swapdisk system).  The cube would ask for the optical, the optical disk
image (icon) would spin for a few revs and then everything would stop.  I used
the ROM Monitor to turn on extended diagnostics and found that all tests
were passed.  The freezeup was occuring just after the boot from optical
process began.  The last message was the one saying that 7.xxx Megs of
RAM were available (or somewhere near here).  This same machine booted
fine the night before.  I thought, "Oh great... the optical drive is shot".
Fortunately, replacing the /odmach executable on the optical caused the
problem to go away.

Does anyone have any idea of what may have happened here?  I'd really like
to avoid this problem in the future.
-- 
John Garnett
                              University of Texas at Austin
garnett@cs.utexas.edu         Department of Computer Science
                              Austin, Texas