Patty said:
The old ram is FPM w/parity. The motherboard will run with parity but
doesn't need it. I tried to run the new RAM totally by itself, with the
old out and it still would not work, I believe I said that in my original
post, so it shouldn't have mattered what the old RAM was in that case. If
it was an incompatibility problem with the old and the new, it should have
worked with just the new and it didn't.
Normally I'd agree but with what should be good RAM not working I'm
grasping at straws and wondering if the BIOS left some residual setting due
to the old ram that interferes with the new even when it's alone. Not
likely but then it shouldn't have been likely the 23 meg EDOs would have
problems either.
I did run EDO RAM with the old
parity RAM before with no problems, but that was two sticks of 16MB RAM and
this time was two sticks of 32MB RAM.
That would cause one to think it's the 32 Meg size/configuration itself.
The motherboard is an old
M-Technology R-534 (mti-usa.com). The board was originally purchased in
1997.
I went to their site and looked it up but the information left is minimal
and of little use, for memory anyway. What they have for download as 'the
manual' is nothing but CPU jumper settings.
The BIOS gives few choices for setting RAM. It gives a CAS latency setting
either 2T or 3T. It gives some other settings (I don't remember off hand,
but they are all set to 4T which is the default. The BIOS is Award 4.51PG.
Yes, I went online and found some different RAM. I'm also wondering about
the 2K and 4K thing, but I have no idea what this KByte RAM is and have no
idea how to check it.
Neither do I. Tiger direct has nothing of value (no big surprise) and
K-Byte has apparently disavowed that they ever made SIMMs. There's not a
mention of ANY SIMMs on their site in either products or 'support' or even
their memory configurtor.
I'm thinking that the board more than likely needs
the 2K rather than the 4K but there's no indication of that anywhere.
What's the difference between the 2K and the 4K?
It's how many refresh cycles, and of what type, it takes to refresh the
memory cells. System memory is "dynamic", meaning the data literally fades
away unless it is read and put back on a regular schedule, I.E. "refresh."
The memory controller does that transparent to the system but it has to
know what kind of refresh is needed, and be designed to handle it. It's
designed so doing a 'row read' refreshes a whole row to speed things up
(I.E. not every cell has to be explicitly accessed all by it's little
lonesome).
It's related to the organization of the memory chips used to make up the
module. The chips are organized as Y bits deep by X bits wide, which is NOT
the 8x32 **MODULE** size in the K-Byte description, and, without getting
into actual chip design, the organization affects how they design the
refresh circuitry, although that's not the sole determinate.
A 'standard' 32 meg SIMM uses 16 chips, 8 on each side (I.E. "double
sided"), with each chip being 4 megabit deep and 4 bits wide, I.E. 4x4. So,
the way it works is, 8 chips that are 4 meg deep and 4 bits wide make for
32 bits wide (the module width) and that's 16 meg (4 meg deep by 32/8= 4
bytes wide. e.g. 4 meg by 8 bytes for 16 megabytes) and there's two sides.
I.E. two "banks" (from the days when motherboards used multiple modules to
make a "bank" of memory) of 16 meg. Or, in current day parlance, two ranks.
If your modules don't have 16 chips, 8 on each side, then they are not only
not 2K refresh but are also not the standard 'density'.
To know if they are standard density you need to have either the chip type,
e.g. 4x4, specified or know the number of chips they used (from which you
can deduce the chip organization). Unfortunately, it seems no one tells you
the chip organization for SIMMs anymore but you will see "16 chip, 2K
refresh" listed when it's "industry standard."
Unfortunately, I can't see find any detailed motherboard docs so I don't
know what memory types it supports. Looking at generic docs, however,
there's a suggestion, I emphasize 'suggestion', it should work with 4K
refresh 32 meg SIMMs, but then you have a problem with yours.
As I've explained, the
board has a problem with the RAM on the first reboot of the system. It
gets up and running with no apparent problems the first time and then craps
out on subsequent reboots both cold and warm.
Frankly, it doesn't make obvious sense. And by that I mean, the symptom
doesn't point to a classic problem. If it 'runs' one would think it should
reboot.
I'll check out the website you mentioned. Thanks!
Btw, on a general note, the SIS5571 chipset used on that board can support
up to 256 meg of memory (although I'm still trying to figure out how they
come up with 4 32 meg SIMMs equaling 256 meg) but it can only cache 64 meg
(this is a chipset limitation). Which means the system will likely be
faster with only 64 meg of RAM than more, unless you're running something
that requires a *lot* more than 64 meg, in which case even the slowness
from non-cached ram might be faster than huge amounts of disk swapping. Oh,
and Windows doesn't figure out some way to use cached memory 'first' so it
isn't as if it'll be 'fast until' it gets to the uncached part. You'll see
this mentioned in generic memory faqs under titles akin to "why is my
system slower after adding memory?"
Some other notes. The SIS 5571 is one of the earliest chipsets to support
SDRAM but it isn't the SDRAM we know today. The original stuff used a 2
clock setup, and is what the chipset supports, that didn't really work very
well so later SDRAM uses a 4 clock design. The upshot is, virtually all
'normal' SDRAM is 4 clock and won't work. If you wanted to try SDRAM you'd
need to find old modules specifically saying they're they're 2 clock type
(very rare, just in case you're thinking SDRAM might work better than your
SIMM problem). Alternately you could use EDO DIMM.
Also, that chipset has a rather strange "single SIMM" boot capability. To
explain why that's strange, 32 bit processors use a 64 bit wide memory bus
and, noting your memory modules are 8x32, you can see it takes two 72 pin,
32 bit wide, SIMMs to make a 64 bit wide memory bus. And that's why you
will universally hear the warning with 72 pin SIMMs "must use in pairs."
Well, that's normally true for 32 bit processors but not for 16 bit
processors like the 486, which has a 32 bit wide memory bus, and that's
what 72 pin SIMMs were originally designed for, the 486, and they fit a 32
bit bus mono a mono just fine. But, as the world turns, 32 bit processors
came out almost as fast as the 72 pin SIMMs did and the "must use in pairs"
became the understandable mantra.
Now, enter SIS making a "Pentium Class" chipset for el-cheapo systems, and
being able to use one SIMM is cheaper than 2, so they came up with this
"single SIMM boot" dealie where it double reads the one SIMM to get the
required 64 bit wide data word. Slow as hell, for the obvious reason of
needing a double read, but you only need one SIMM.
Now, I suppose it's possible that, in addition to the other potential
compatibility issues we've discussed, there's something about those 32 meg
SIMMs that bumfoozzles the SIS chipset's determination of if it needs to do
it's funky dunky "single SIMM" cheater routine but I don't know why it would.
I did try looking up other boards using the same chipset but no one,
including the chipset docs I found, give any indication of what memory is
supported beyond the generic description of EDO, FPM, etc. and module
sizes. That usually means 'standard' (how could they know what someone in
the future would dream up?).
I wish I could come up with an "ah ha! That's it" for you but it just isn't
happening. The only thing I can think of is to try SIMMs with *known*
'standard' specs and see if they work but, considering the strange nature
of the problem, that isn't a slam dunk guarantee either. Now, considering
the 64 meg cache limit anyway, it might be safer to use 4 16 meg SIMMs
since you indicated you've used those before without problem (that's what I
do, btw, on these older chipsets).
I did discover they have a newsgroup: alt.comp.periphs.mainboard.m-tech
Who knows, maybe someone in there has a magic bullet.
