>> der mouse shrieked:

Hmm, that's not the verb _I_'d use :-)

>> Yes, it is.  I've used this mode as a memory sizing tool - when I
>> have a 72-pin stick of unknown size and width, I set diag-switch?
>> true, pop it in, and watch the messages.
> Oh.  I find it easier to just check the P/N's of the components on
> the SIMM.  :>

If I had suitable reference material to do likewise, I might find that
easier myself. :-)

>> putting good 4Mx36 sticks on either side of it will usually
> Ah, that's worth knowing.  I.e. put the suspect SIMM in slot 1 and
> populate slots 0 and 2 with 4M devices?

Or 0 and 3, in which case you can try out two suspect sticks at the
same time, in 1 and 2.  (Not 1 and 3 with the suspect in 2; IIRC I
found that you _must_ have something in socket 0.)  As long as both the
lowest and highest ones are good, the POST seems to be happy.  I
speculate that it uses very low physical addresses early on (thus the
requirement for RAM in socket 0), and reserves some memory for its own
purposes at the top of available RAM after sizing.  If you look at the
addresses printed for the RAM regions when diag-switch? is true, you'll
see that the highest nonempty socket appears to end something like
0x2000 before it actually does.

> Isn't there any sort of rule regarding "largest devices in lowest
> slots"?

On the ELC (and I think the IPX as well, though I'm less certain) I
haven't seen any such.  The sockets are 16M apart and each stick
occupies either the whole of that 16M or the low 4M of it, depending on
whether it's a 16M or 4M part.  If you put a 4M part other than last,
this just means physical memory is noncontiguous.  I have a SIMM
"adapter" which has four 30-pin SIMM sockets and plugs into a 72-pin
SIMM socket; if I populate only some of the 30-pin sockets, the RAM
fails POST (of course) - but I hacked on the SPARC /dev/mem driver to
permit access to any <64M address even if it wasn't in the memory map
and found that upon booting (with enough good RAM to run in, of course)
and poking at the partially-populated adapter's space, some of the
bytes worked and some didn't - in byte terms, the low two address bits
select which 30-pin SIMM is used, though I daresay the underlying
memory path is 32 bits wide with each small SIMM supplying 8 of those
bits.  With some sockets empty, some of the bytes just didn't work.  (I
forget whether they always read as 00, always read as ff, or what - I
have a hazy memory of there being a case where a value recently written
sometimes affects a value read, but only very soon after; etch run
capacitance, maybe?)

>> reducing the failure mode to an error from the memory selftest.
> Sure would be nice to know the fancy "light flash" codes on the
> keyboard!  Had some bad 4M SIMMs in an LX (?) and couldn't even get
> the banner/logo to appear!  :-(  But, could see that something was
> obviously running by the patterns on the keyboard LEDs

Ah, I don't know anything about that.  All my playing was done with
serial console.  (I think diag-mode? true produces output on the serial
port much earlier than it produces anything on the framebuffer, which
is hardly surprising as the FORTH engine has to be up to initialize
many framebuffers.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B