SIMM, Address Lines Order?

Jeff Walther trag at
Mon Sep 26 14:37:03 CDT 2005

>Date: Mon, 26 Sep 2005 08:18:24 -0600
>From: woodelf <bfranchuk at>
>Subject: Re: SIMM, Address Lines Order?

>der Mouse wrote:
>>>When connecting DRAM chips to the pins of a SIMM (i.e. laying out the
>>>traces) does it matter if the  order of the address and data lines is
>>>preserved?  [...]
>>  What about refreshes?  (This is a question, not a challenge; I do not
>>  know enough about how dynamic RAM refresh works to know whether this
>>  really is relevant.  But it seems to me that it might be.)
>Just that all of them gets refeshed in the alloted time.
>Note they just have to be read for refesh. Still you better
>check the data sheets if you got them for the fine print.

I do have the data sheets.  I am planning to use the KM44C16100 from Samsung.

Looking at the various refresh options in the datasheet:

1) The RAS only, and Hidden Refresh cycles involve a Row address 
supplied on the address lines.   So, unless there's some undocumented 
requirement that these address be supplied in a particular order, I 
don't think that will cause a problem.  However, I recognize that 
sometimes datasheets (and documentation in general) assume general 
knowledge about the topic.  So if there is some implicit assumption 
about the addresses supplied during a refresh, I'd appreciate someone 
explaining it to me.

2) During CAS before RAS refresh, the address lines are listed as 
'don't cares'.

In other weirdness, I never saw the "der Mouse" reply to my posting, 
so I checked the cctalk archives, on a hunch.   There are several 
replies to my posting in cctalk which never appeared in the cctech 
digest or archive.   Is this normal?  How are the two lists organized 
wrt each other?  Does cctalk see all the cctech postings, but not 
vice versa?  It creates difficulties if folks on cctalk reply to 
cctech postings by emailing to cctalk.  Is it assumed that everyone 
is subscribed to both?  I am happy to adjust as necessary.  I just 
don't understand the arrangement, yet.

* Jim Battle frustum at writes:

>  Burst mode DRAMs could be a problem.

I mis-wrote.  These DRAMs have a Fast Page mode--not a burst mode.  I 
was mislead by discussion of burst reads in "The Guide to the 
Macintosh Family Hardware" but I believe those burst reads are 
between the CPU and the memory controller chip in the IIfx.

I should have written Fast Page mode, during which a Row address is 
supplied with the RAS, then a series of Column address is supplied 
while strobing the CAS for each change in Column address.  Because 
the addresses are explicitly supplied, I don't think that reordering 
the address pins should cause any problems.  A FP read will still 
stay within the same page (row address) for a given DRAM chip.

>  One last thing.  There were DRAMs that used a different number of 
>address lines
>  for RAS than for CAS.

Good point.  These are 12 X 12, 16M X 4 chips, so that should not be 
an issue.  If they were 13 X 11, I'd need to make sure that the upper 
two address line orders were preserved?

>  As a disclaimer, I have designed, implemented and shipped a number (10?) of
>  DRAM controllers, both in TTL and in ASIC forms, but the most recent to ship
>  was about 1991, so some details might have faded.

The computer for which I'm building the SIMMs was released around 
1991, so there's a nice symmetry there.

* Allison ajp166 at writes:

>  Tim Olmstead wrote a Z80 Dram interfacing manual

Google turned it up.  Thank you for pointing it out.

* Dwight K. Elvey dwight.elvey at writes:

>  Only that the first address lines that are used for refresh
>  need to be grouped. As example for a 128 cycle refresh, that would
>  be that one could mix any of the A0-A6 lines. This is because
>  of how the blocks of RAM are accessed and then selected by
>  a mux to the output.

Can you elaborate on this.  I must be missing some key bit of 
information about refresh.  I get that 7 address lines are 128 
addresses or blocks of RAM if one is just talking about Row 
addresses.  But how does that mean that some address lines can be 
mixed and others not?

Is there a refresh mode where multiple blocks are chosen at one 
time--where the upper address bits are defined, but the lower bits 
are don't cares?   That's not mentioned in the datasheet, but just 
because it isn't mentioned, doesn't mean it isn't assumed.

I've been trying to find out which refresh scheme the IIfx uses, but 
haven't found it in the limited documentation I have here.  I have a 
feeling I've read it somewhere...darn it.

Thank you for all the comments and help folks,


More information about the cctech mailing list