Matthew,

Caveat: It's a long time since I dealt with DRAM (back
in the heyday of Z80s) so the following is general
advice, and may not be technically accurate!  :-)

On Mon, 21 Jun 2004 01:47:55 -0400, Matthew Brush wrote:

> Hi all,
>
> Recently I asked about using some DRAM from a video
> card on an IDE bus.  It was made clear to me that I
> would have a lot harder time using DRAM rather than
> SRAM.  At first I didn't understand exactly why, but
> now that I've had a good few nights of reading about
> DRAM, I know understand why.

Yes, to sum it up in a word: Refresh!

> Now, I have decided to go with some 30 pin DRAM
> anyway.  Why?  Because I would like to learn how to
> use DRAM and also, I have piles of 30pin SIMM modules.
>  I haven't been able to find the datasheet for the
> stick I'm using, but I've found a generic pinout for
> 30pin SIMMs.  I just wanted to get a few things
> confirmed/clarified:

You're really going to need some data - if it's one of
the "normal" PC SIMMs from 486-to-Pentium 1 days, then
find a similar one (of the same speed) and that will be
good enough, but you can't do it without anything.

> 1. I am using a 1MB 1Mx9 70ns module (3 chips on the
> pcb, not the same chips, maybe a parity dealy or
> something).  So, I don't need the Address lines A10 &
> A11 correct, just A0-A9?

DRAM doesn't usually use linear addressing, so you can't
assume the above - it uses Column and Row addressing,

> 2. Can I think of the rows and addresses as:  Each of
> the rows as a byte and each column as a bit of that
> byte?

No!  The bits of each byte are spread across the chips,
so you always work in (9-bit) bytes.  You are dealing
with columns and rows within each chip, so each
Column/Row address pair represents one byte.  This gives
two advantages: you can address more memory with fewer
pins, and it helps with refreshing - see below.

In early implementations there were 9 chips,
contributing a bit each, but later, as in yours, each
chip has 3 bits.  But the addressing is still the same
for the SIMM itself.

> 3. Does a refresh cycle simply consist of addressing
> each row & column at specific time intervals?  So, I
> could just use a timer interrupt on a PIC which just
> runs though all the possible row/column combinations
> every few mS or something?

You need the specs!  There wouldn't be time to do each
byte of 1MB individually - if you think about it a 1MHz
cycle rate (just about possible with a PIC) would mean
you'd only do each one once a second, which is nowhere
near fast enough.  It's just possible that the SIMM is
self-refreshing, but I don't think this was ever done.

As far as I remember for a refresh cycle you address a
column only (perhaps with a "refresh" signal set, but I
can't remember exactly) and that read/refreshes the
whole column.  Z80's would do it for you, incidentally -
there was a "refresh register" that was incremented on
each instruction cycle, and sent out during the
execution part of the cycle, and you could pretty-much
ignore it in your programming.  But with a PIC you are
going to have to do a refresh cycle every now and then,
cycling through the columns at a rate that means that
you do every one well within its timing parameter.

> 4. I believe my SIMM has parity, does that mean I have
> to implement this, or can I just ignore the parity
> in/out lines?  I assume that the parity bit can be
> used as another data lines or something (hence the
> 1Mx9 instead of x8) ... correct?

The ninth bit is the parity bit.  I believe the "odd"
chip may include parity generation and checking, and if
you don't use it the chip will generate a "parity error"
signal when the byte you write has the wrong parity (50%
of the time, on average).  You can probably safely
ignore the signal, but you will probably need to connect
the parity bit pin to a weak pull up or down so it
doesn't float on input, and doesn't fry something when
driven the "wrong" way.

> Sorry if this are stupid questions, but I just wanted
> to see if I'm on the right train of thought.  I
> realize using SRAM would be easier, but where the fun
> in that?

Well it's your time (and hair to pull out! :-) but you
really do need documentation showing timings and so on,
or you won't get anywhere.

> P.S. If anyone cares, my intended application will use
> a 16F877A as a DRAM controller which will be connected
> to rest of the project via it's PSP port and it will
> provide a simple interface to the DRAM.  There will be
> another 16F877A doing some other stuff on the PSP bus
> (IDE, parallel port).  I need to use up some samples
> :)

I've just remembered something about DRAM in video
applications: if you design it right, so that the whole
of memory is read for each pass of the video image, it
may be possible to ignore refreshing because the normal
reading may fit within the timing needed and do it for
you...

Cheers,

Howard Winter
St.Albans, England

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics