AlphaStation 200 memory
Oleg Solovianov
What kind of 72pin parity SIMMS could be used in an AlphaStation 200 4/233?
(so called Avanti)
It seems that it did not properly recognize dual-bank SIMMS...
F.ex 8Mx36 (32MB Samsung) SIMMS are detected as 8MB SIMMs :(
The only other difference is that these SIMMs are using 4Mx16bit memory
chips, not x4bit chips as DEC 16MB modules...
The firmware is 6.9-4, maybe this is a problem of 21071 chipset?
Regards,
Oleg Solovyanov
Terry Kennedy
> What kind of 72pin parity SIMMS could be used in an AlphaStation 200 4/233?
> (so called Avanti)
I have a bunch of the Onsale AS200's and have had no problems installing
random SIMMs in them. Mostly I add 4 32MB Kingston SIMMs (KTM8X36L-60T) to
bring the box up to 144MB (128MB of new memory plus the 16MB of original
memory).
Many older memory controllers insist that the largest SIMMs be installed
first, so I do that out of habit even if it's not strictly necessary. You
might want to try it and see if it helps.
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.spc.edu St. Peter's College, Jersey City, NJ USA
+1 201 915 9381 (voice) +1 201 435-3662 (FAX)
Charles M Richmond
>
> Hello!
>
> What kind of 72pin parity SIMMS could be used in an AlphaStation 200 4/233?
> (so called Avanti)
>
> F.ex 8Mx36 (32MB Samsung) SIMMS are detected as 8MB SIMMs :(
> The only other difference is that these SIMMs are using 4Mx16bit memory
> chips, not x4bit chips as DEC 16MB modules...
>
> The firmware is 6.9-4, maybe this is a problem of 21071 chipset?
>
Ah.. the old problem crops up again. *Many* 60ns 32M SIMMs exhibit
these problems. If you use 70ns SIMMs then you won't have any problem.
The 60ns SIMMs sometimes do not respond to the sizing as quickly as
they should and are then mistaken for 8M SIMMs. I have documented
this in previous posts for DEC, SUN, and AST h/w.
--
***********************************************************************
* Charles Richmond Integrated International Systems Corporation *
* c...@iisc.com c...@koibito.iisc.com c...@shore.net *
* UNIX Internals, I18N, L10N, X, Realtime Imaging, and Custom S/W *
* One Longfellow Place Suite 3309 , Boston , Ma. USA 02114-2431 *
* (617) 723 7695 (617) 367 3151 FAX (617) 723 6861 *
***********************************************************************
Terry Kennedy
> The 60ns SIMMs sometimes do not respond to the sizing as quickly as
> they should and are then mistaken for 8M SIMMs. I have documented
> this in previous posts for DEC, SUN, and AST h/w.
Say what?
FPM memory is asynchronous - the data is either there when it's needed
or it isn't (and if it isn't, you either mis-size memory or get a parity
error).
The only way your explanation makes sense is if you got some parts with
"60ns" labeling that were actually *slower* than 70ns parts. The memory
controller has no idea how fast SIMMs are - it just has a timing spec that
needs to be met. And if 70ns parts meet it, 60ns parts do as well, unless
they're defective.
Oleg Solovianov
>Charles M Richmond <c...@iisc.com> writes:
>> The 60ns SIMMs sometimes do not respond to the sizing as quickly as
>> they should and are then mistaken for 8M SIMMs. I have documented
>> this in previous posts for DEC, SUN, and AST h/w.
>
> Say what?
>
> FPM memory is asynchronous - the data is either there when it's needed
>or it isn't (and if it isn't, you either mis-size memory or get a parity
>error).
>
> The only way your explanation makes sense is if you got some parts with
>"60ns" labeling that were actually *slower* than 70ns parts. The memory
>controller has no idea how fast SIMMs are - it just has a timing spec that
>needs to be met. And if 70ns parts meet it, 60ns parts do as well, unless
>they're defective.
By the way, the DEC module 5423170 has 60ns chips for data and
70 ns chip for parity...
Samsung KMM5368003ASW-6 has 60ns chips for data and parity.
and do not work as 32MB, butas 8MB module.
I always thought taht the sizing should be determined by pins 68 and 67?
But Micron databook shows only 1,2,4 and 8 MWord values...
And how come that larger modules responds quicker/slower than smaller ones?
Why there shouldbe ANY difference?
Just curious,
Oleg Solovianov
Charles M Richmond
>
> Charles M Richmond <c...@iisc.com> writes:
> > The 60ns SIMMs sometimes do not respond to the sizing as quickly as
> > they should and are then mistaken for 8M SIMMs. I have documented
> > this in previous posts for DEC, SUN, and AST h/w.
>
> Say what?
>
> FPM memory is asynchronous - the data is either there when it's needed
> or it isn't (and if it isn't, you either mis-size memory or get a parity
> error).
>
> The only way your explanation makes sense is if you got some parts with
> "60ns" labeling that were actually *slower* than 70ns parts. The memory
> controller has no idea how fast SIMMs are - it just has a timing spec that
> needs to be met. And if 70ns parts meet it, 60ns parts do as well, unless
> they're defective.
Go tell it to Sun, LTX, Digital, AST, etc. AST found that some 60ns
parts reacted slower than 80ns parts in certain circumstances. I
have seen a list of bogus ram/cache chip combinations that was
provided by a Sparq5 SBC maker. I am sorry but I didn't keep a copy.
All of these will still work in PCs of course. Its like bad thread
code, which works on sloppy machines.
Charlie
PS: Conceptutalise memory sizing and you will understand more.
Terry Kennedy
> Go tell it to Sun, LTX, Digital, AST, etc. AST found that some 60ns
> parts reacted slower than 80ns parts in certain circumstances. I
Then those parts were incorrectly marked as 60ns parts, either by accident
or fraudulently. The manufacturer and part number info should be made avail-
able so people can avoid them.
> PS: Conceptutalise memory sizing and you will understand more.
I can "conceptutalise" it just fine, thanks. I used to design memory sub-
systems. When I spoke to a Kingston tech about the bus loading of their 128MB
DIMMs, the tech was quite happy to have a long technical talk with me, since
most of the calls he gets are from end users, and he hadn't had a chance to
talk about design issues for some time.
With asynchronous memory designs, the data is either there when it's needed
or it isn't. Period.
To address a question asked by another poster, 72-pin SIMMs have four
"Presence Detect" pins that can be used to determine what type of SIMM is
inserted in the socket. This can be found on page 4.4.2-3 of JEDEC Standard
21-C which can be found at:
http://www.jedec.org/download/freestd/pub21/4_4_2-R8.PDF
Not all SIMMs provide correctly configured PD pins. A good memory tester
like the Innoventions SIMCHECK:
http://www.simcheck.com/sim2se.htm
can tell you if the PD pins are configured correctly, as well as display-
ing the organization and speed of the part. And of course, whether or not
the part actually works!
It's possible that the memory controller in the AlphaStation 200 is con-
fused by parts with incorrect PD pins or non-FPM parts (for example, ECC-
mode EDO memory). But that is still not a speed issue.
Charles M Richmond
>
> Charles M Richmond <c...@iisc.com> writes:
> > Go tell it to Sun, LTX, Digital, AST, etc. AST found that some 60ns
> > parts reacted slower than 80ns parts in certain circumstances. I
>
> Then those parts were incorrectly marked as 60ns parts, either by accident
> or fraudulently. The manufacturer and part number info should be made avail-
> able so people can avoid them.
Right. You don't understand, so it must not have happened. If it
did then it must be mislabeling or fraud.
Get a life.
Terry Kennedy
> Right. You don't understand, so it must not have happened. If it
> did then it must be mislabeling or fraud.
What *you* don't seem to understand is that there is a standard for these
parts, with specs that manufacturers follow. My last article had the URL
for the relevant part of the JEDEC standard.
Your sole reference is something you saw sometime, but now can't locate.
Sounds suspiciously like "the dog ate my homework".
I invite readers to review both my and Mr. Richmond's posts, as well as
the supporting materials, and make their own decisions.
Tim Shoppa
>
> Charles M Richmond <c...@iisc.com> writes:
> > Right. You don't understand, so it must not have happened. If it
> > did then it must be mislabeling or fraud.
>
> What *you* don't seem to understand is that there is a standard for these
> parts, with specs that manufacturers follow. My last article had the URL
> for the relevant part of the JEDEC standard.
>
> Your sole reference is something you saw sometime, but now can't locate.
> Sounds suspiciously like "the dog ate my homework".
I, myself, don't know anything about the standards, but I do know
that our PC-Clone 32 Mbyte 72-pin parity SIMMs will always be identified
as 8 Mbyte SIMMs in DEC 3000-300 and similar machines. This
isn't a big hassle, as guaranteed-to-be-DEC-compatible
memory is available for just a few bucks more than the PC-clone
stuff these days. But I have been following this thread to
see if anyone might know why this is. I see four possibilities:
1. DEC didn't follow the relevant JEDEC standard.
2. The PC-Clone SIMM makers didn't follow the relevant JEDEC standard.
3. The standard is loose enough that there are loopholes (or, like
other situations, there are multiple incompatible standards).
4. The PC-Clone stuff really is below-spec.
My strongest suspicion is for #4, but the fact that all of
several different brands/makes of PC-clone 32 Mbyte SIMMs
were identified as 8 Mbyte SIMMs (and we ran several machines this
way for extended periods of time to see if any errors were logged)
means that I really have no evidence for #4.
Tim.
Oleg Solovianov
My suspicion is that Alphastation memory subsystem do not use at all
these PRD (presence detect) pins at all. Just for kicks I tried
to connect PRD pins to specify 70 and 80 ns, o see if there is a difference
the result is the same - 8MB instead of 32.
The question is, HOW the Alphastation will determine the memory size?
Teach us, the wizards of Oz :)
Regards,
Oleg Solovianov.
Terry Kennedy
> I, myself, don't know anything about the standards, but I do know
> that our PC-Clone 32 Mbyte 72-pin parity SIMMs will always be identified
> as 8 Mbyte SIMMs in DEC 3000-300 and similar machines. This
> isn't a big hassle, as guaranteed-to-be-DEC-compatible
> memory is available for just a few bucks more than the PC-clone
> stuff these days. But I have been following this thread to
> see if anyone might know why this is. I see four possibilities:
Interesting. I'll put my money where my mouth is...
Send me your address and I'll send you 2 or 4 new-in-the-box Kingston
KTM8X36L-60T SIMMs as loaners and a FedEx airbill for you to send your
SIMMs (same quantity) to me, and I'll put them on my memory tester and
see what it says. I'll also test 'em in an AS200 4/233. Then we can swap
'em back.
This is *not* an invitation for everybody on the planet to trade their
non-working SIMMs for good ones 8-). After Tim and I figure out what's
going on, I'd be willing to entertain requests from other folks who think
they're having a _different_ compatibility problem.
> 1. DEC didn't follow the relevant JEDEC standard.
> 2. The PC-Clone SIMM makers didn't follow the relevant JEDEC standard.
> 3. The standard is loose enough that there are loopholes (or, like
> other situations, there are multiple incompatible standards).
> 4. The PC-Clone stuff really is below-spec.
I'm sure there's something going on, since many people have reported
the problem. I just don't believe the other poster's assertion that 60ns
parts are responding too slowly, compared w/ 70ns or 80ns parts.
Terry Kennedy
> My suspicion is that Alphastation memory subsystem do not use at all
> these PRD (presence detect) pins at all. Just for kicks I tried
> to connect PRD pins to specify 70 and 80 ns, o see if there is a difference
> the result is the same - 8MB instead of 32.
It may not use them at all. It's up to the particular memory controller
implementation. See below.
> The question is, HOW the Alphastation will determine the memory size?
> Teach us, the wizards of Oz :)
Somehow the memory controller needs to determine the size of each memory
module (in this case, SIMM) installed in order to correctly route the right
number of address and select lines.
Some memory controllers (and discrete logic controller designs) just allow
for the maximum SIMM size in each socket, and if smaller SIMMs are used,
physical memory is sparsely populated, with the firmware or OS building page
table entries to make physical memory appear contiguous.
Newer designs have registers that control the starting address of each
DRAM as mapped into the address space. See the descriptions in:
http://developer.intel.com/design/intarch/DATASHTS/29055102.pdf
In particular, look at section 4.4 (DRAM Interface) starting on page 38
and section 3.2.17 DRB - DRAM Row Boundary Register starting on page 27.
I'm using this datasheet for the explanation as the DECchip 21071 chip-
set (the chipset in the AS200 4/233) documentation isn't public.
You can find a brief discussion (along with some things to look at under
VMS, or at the firmware prompt) at:
http://imcdasweb51.das-x.dec.com:9006/comet/data/notes/mikasa/s3/n391
Michael Moroney
was being developed. I don't remember seeing any part "size" incorrectly,
but then again we only tested 70nS parts. (60nS were either nonexistent
or absurdly expensive, and the system was spec'd for 70nS parts so there
was no reason to test 60nS parts) A few vendors were somewhat flaky (would
fail after many hours of thermal testing). I "heard" later that 60nS parts
may not work right, but I never understood any reason for this, or even if
it was true.
-Mike
Charles M Richmond
>
> Charles M Richmond <c...@iisc.com> writes:
> > Right. You don't understand, so it must not have happened. If it
> > did then it must be mislabeling or fraud.
>
> What *you* don't seem to understand is that there is a standard for these
> parts, with specs that manufacturers follow. My last article had the URL
> for the relevant part of the JEDEC standard.
>
> Your sole reference is something you saw sometime, but now can't locate.
> Sounds suspiciously like "the dog ate my homework".
I do not take my client's proprietary design documents. Do you?
>
> I invite readers to review both my and Mr. Richmond's posts, as well as
> the supporting materials, and make their own decisions.
>
Terry;
A good memory sizer is only going to accept the setting of the pins
as advisory. In fact a good power on diagnostic will measure contiguous
memory as part of its memory address testing. I was writing memory
diagnostics as far back as 1974 and as recently as 1986 was teaching
the DEC folks in Maynard how to do least-access memory diagnostics
and sizing. Now, neither of us actually know the mechanism of the
failure of the memory sizing in the various Alphas. As someone who
has experience writing similar code I have some suspicions. I also
have the advantage of having come across problems with 60ns 32M RAMs
in several different contracts for several different vendors.
You are being way too religious about this issue. Give it a rest.
Charlie
Terry Kennedy
> You are being way too religious about this issue. Give it a rest.
Only because I believe you're spreading misinformation.
We all agree that _something_ is going on. I just don't think it has to
do with 60ns parts being "too slow" which is what I believe you're claim-
ing.
Tim Shoppa is going to send me 2 32MB SIMMs that are known to report as
8MB parts, and I'll put them on my SIMM tester and try them out in an AS200.
I'll report back here with the results.
Tim Shoppa
>
> FWIW, I did some of the AS200 memory qualification for Digital when the AS200
> was being developed. I don't remember seeing any part "size" incorrectly,
> but then again we only tested 70nS parts. (60nS were either nonexistent
> or absurdly expensive, and the system was spec'd for 70nS parts so there
> was no reason to test 60nS parts) A few vendors were somewhat flaky (would
> fail after many hours of thermal testing).
In the case of the PC-clone 8x36 SIMM's that I have that are identified
as 2x36 SIMM's, I've run them for weeks (at the wrong size) with
no errors being logged. (In a 3000-300, which is admittedly
not a harsh thermal environment - DEC really knows how to cool
the insides of boxes! Pity the PC-clone makers haven't figured
it out yet...)
> I "heard" later that 60nS parts
> may not work right, but I never understood any reason for this, or even if
> it was true.
I've heard of folks who have succesfully used commodity 8x36's in
3000-300's - maybe they were using 70ns parts. I've only tried 60ns
parts, and none of those sized correctly. I *want* to blame it
on sub-standard quality of the PC-clone SIMM's, but the evidence shows
that these work just fine (at the wrong size.)
In any event, with guaranteed-DEC-compatible-memory only a few
bucks more than the PC-clone stuff, it's a non-issue these days
to me. 5 years ago when we bought the 3000-300's, it would
have saved us lots of $ to be able to use the PC-clone stuff!
Tim.
Charles M Richmond
>
> Michael Moroney wrote:
> >
> > FWIW, I did some of the AS200 memory qualification for Digital when the AS200
> > was being developed. I don't remember seeing any part "size" incorrectly,
> > but then again we only tested 70nS parts. (60nS were either nonexistent
> > or absurdly expensive, and the system was spec'd for 70nS parts so there
> > was no reason to test 60nS parts) A few vendors were somewhat flaky (would
> > fail after many hours of thermal testing).
>
> In the case of the PC-clone 8x36 SIMM's that I have that are identified
> as 2x36 SIMM's, I've run them for weeks (at the wrong size) with
> no errors being logged. (In a 3000-300, which is admittedly
> not a harsh thermal environment - DEC really knows how to cool
> the insides of boxes! Pity the PC-clone makers haven't figured
> it out yet...)
>
> > I "heard" later that 60nS parts
> > may not work right, but I never understood any reason for this, or even if
> > it was true.
>
> I've heard of folks who have succesfully used commodity 8x36's in
> 3000-300's - maybe they were using 70ns parts. I've only tried 60ns
> parts, and none of those sized correctly. I *want* to blame it
> on sub-standard quality of the PC-clone SIMM's, but the evidence shows
> that these work just fine (at the wrong size.)
I am successfully using 70ns "commodity 8x36's" in 2 3000/300X
boxes.