[comp.sys.next] memory, LUTs, and a strangeness

garnett@cs.utexas.edu (John William Garnett) (12/18/90)

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

rca@cs.brown.edu (Ronald C.F. Antony) (12/19/90)

In article <1031@nada.cs.utexas.edu> garnett@cs.utexas.edu (John William Garnett) writes:
>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?

Yes. If they conform to the specs. (100ns or faster, only SIMMs of the same 
kind in the same bank, no mixture of parity and non-parity chips)

>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.

Did you happen to get an operating system 1.0 with the cube? Then you probably 
double clicked once on the odmach executable. I remember that in the time 
before 1.0a was out there were quite a few such postings. As far as I
know change the permissions as root with chmod a-wx 

Ronald
------------------------------------------------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man."   G.B. Shaw   |  rca@cs.brown.edu or antony@browncog.bitnet