LinuxSA Mailing list archives

  From: Stock, Nick <Nick.Stock@dsto.defence.gov.au>
  To  : 'Phil.Nitschke@caemrad.com.au'" <Phil.Nitschke@caemrad.com.au>, Linux SA <Phil.Nitschke@caemrad.com.au>
  Date: Wed, 11 Nov 1998 09:15:10 +1030

RE: Knowledgeable South Australian PC Component Suppliers

Hi all,

I will respond to this in two stages,

For anyone who is buying any computer parts for any system,
Linux or not you should be aware of the concept "fit for purpose".

If you walk into a computer store and ask for a component that
works with system A and they supply you with part B and it
doesn't work, you are entitled to take it back and get a refund
or swap it for part C (which hopefully does work).

You can specify any number of conditions, eg VX motherboard
running Linux. If they say "yep it will work" and it doesn't, take it
back. Of course the supplier is perfectly entitled to say "I don't
know" in which case you should either go to a more knowledgable
supplier or carefully sound the supplier out on the options if it
does hit the wall.

-----------------------------

This is now the second half of the email, for those who are interested
in the technical side, (no Linux component).

All DRAMs that have a synchronous interface are known generically as SDRAM.
This includes
CDRAM (Cache DRAM), RDRAM (Rambus DRAM), ESDRAM (Enhanced SDRAM) and
others, however the type that most often is called SDRAM is the JEDEC
standard
synchronous DRAM.

JEDEC SDRAM not only has a synchronous interface controlled by the system
clock, it also
includes a dual-bank architecture and burst mode (1-bit, 2-bit, 4-bit, 8-bit
and full page). A
?mode register? that can be set at power-on and changed during operation
controls the burst
mode, burst type (sequential or interleave), burst length and CAS latency
(1, 2 or 3).

SDRAM was initially introduced as the answer to all performance problems,
however it quickly
became apparent that there was little performance benefit and a lot of
compatibility problems.
The first SDRAM modules contained only two clock lines, but it was soon
determined that this
was insufficient. This created two different module designs (2-clock and
4-clock), and you
needed to know which your motherboard required. Though the timings were
theoretically
supposed to be 5-1-1-1 @ 66MHz, many of the original SDRAM would only run at
6-2-2-2
when run in pairs, mostly because the chipsets (i430VX, SiS5571) had trouble
with the speed
and coordinating the accesses between modules. The i430TX chipset and later
non-Intel
chipsets improved upon this, and the SPD chip (serial presence detect) was
added to the
standard so chipsets could read the timings from the module. Unfortunately,
for quite some
time the SPD EEPROM was either not included on many modules, or not read by
the
motherboards.

* From http://www.tomshardware.com (of course!)

Well that is the only VX SDRAM compatibility issue that I could find.

> The problem is that the VX chipset only has just so many address
> lines, and can't support 64MBit memory depth (so I've been told).  So
> the more conventional SDRAM DIMMs available today, which have a total
> of 8 chips, are not suitable.

64MBit is 8MB (MB = MBytes, Mb = MBits)
What you have just said is that the VX chipset can't support more than 8MB
or RAM... I don't think that is quite what you meant.

> But apparently there is a double-sided 64M SDRAM DIMM with 32chips; I
> just don't know who can supply these.

I could go and get out my Computer Hardware text books and try and
write a meaningful answer that we can all understand but I can't be
bothered. Basically follow the idea above...

Explain that you want an XMB of SDRAM to run in a VX board.
After that the compatibility problem is out of your hands.

As far as it working in a new machine. These days most new machines
are running PC100 SDRAM and the normal SDRAM you will be buying
will not run at 100MHz. Sorry...

Nick Stock
RJ-45 of all trades.

-- 
Check out the LinuxSA web pages at http://www.linuxsa.org.au/
To unsubscribe from the LinuxSA list:
  mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject