I've still got almost all the RAM chips that have ever failed on me, and, aside
from one thoroughly voltage-abused board of small SRAMs, I've got very few that
are smaller than 64Kbits. There are a couple of 21L02's a couple of different
2114/2149 types, a dozen or so 4116-types, and perhaps a couple of 6116's. By
contrast, I have a paper box about half full of SIMMs and DIMMs, not to mention
VRAMs, etc, some of which may be separated from their healthy bretheren if I
feel ambitious or desperate some day. The pattern they seem to follow is an
order n^2 pattern, where the number of bits squared in a single device seems to
be reflective of the risk of failure. That means that a SIMM with 64 MB, one of
which I've got right here, with eight EDO DRAMs on it, is 8 times as likely to
fail as one with one of the same device type, but the device itself seems to be
about 16 times as likely to fail as one a fourth its size. As each shrink in
the geometries is brought forth, the industry claims its failure rate per bit
goes down, but I've seen nothing of the sort. It seems that the failure rate,
for DRAMs anyway, goes up as the square of the number of bits per device. Also,
a two-IC SIMM seems about a fourth as likely to fail as one with eight of the
same size device on it. That fits, doesn't it?
While I don't dispute Tony's experience, mine has been somewhat different. I've
still got the first SRAM boards I ever bought for the S-100 bus, all with 4Kbit
SRAMs (2147's), and those have never (yet) had a failure. Likewise, I still
have the first S-100 board with 32 WIDE SRAMs (6116's) on it, and it's also
never experienced a failure. Oddly enough, my S-100 DRAM boards using 4164's
have had no failures either, though there are more of them. OTOH, my 2 Ampro
Little Boards, have lost over a dozen 4164's over the 15+ years I've had 'em.
If one uses only 1000 or so part per week, one doesn't get a complete picture of
the real failure rates of memory devices, if you test 40 boards at a time, each
with 288 DRAMs on it, and test and ship 100+ boards a week, then you get a
picture. Believe me, it's different from what one gets in the basement personal
computer and electronics lab.
Dick
----- Original Message -----
From: "Ethan Dicks" <ethan_dicks_at_yahoo.com>
To: <classiccmp_at_classiccmp.org>
Sent: Friday, July 06, 2001 7:38 PM
Subject: Lack of robustness with 1K and 4K RAM chips (was Re: 2116 and other old
memory chips)
>
> --- Tony Duell <ard_at_p850ug1.demon.co.uk> wrote:
> > The 2114 SRAM is single-supply rail (+5V only). Again, it was made by
> > several companies (but I think most of the time it was called the 2114).
> > It also happens to be the chip I've had the most failures from :-)
>
> I, too, have had these fail numerous times. Much more so than other SRAMs
> or any DRAMs. The only ones that came close were from the same era: 4096
> DRAMs - I have them on some LSI-11 boards and inside a Z-80-based Gorf.
> When I first got all the parts together to refurb a full-sized Gorf machine,
> the internal tests showed a memory fault on one of the DRAM boards, covered
> in 4096 chips.
>
> I use the LSI-11 CPU, a COMBOARD (for its memory mapping/DMA engine) and
> a Fluke tester to check the 4K DRAMs - plug the COMBOARD on the Qbus,
> put the test RAMs on the LSI-11 board, plug the Fluke emulator/tester
> in the 68000 socket on the COMBOARD, fire it all up, hit the DMA enable
> bit on the COMBOARD, then through the Fluke, test a range of 68K memory
> that corresponds to the appropriate range of Qbus memory addresses and
> voila - a 4096 tester with about $25K-new-cost worth of test gear. (The Qbus
> COMBOARD memory map is divided into 4 regions, RAM, shared-memory, I/O and
> ROM. There are 22 bits of 68K space available to map each and every Qbus
> location into some valid local address. Who needs mapping registers! No
> FUBAR on a Qbus!)
>
> The first COMBOARD used 2114 SRAMs because they were more reliable than
> Intel's DRAMs of the day (plus the XC68000 would occasionally enter a
> microcode fault and reset, causing Z-80-style bus-driven refresh mechanisms
> to pause too long, letting all the bits leak out).
>
Since the MC68000 and its kin didn't have a Z-80-style bus-driven refresh
mechanism, this must have been implemented in external hardware that was turned
off when an exception was encountered, or it was done in software, which was
apparently not used in the exception handler.
>
> -ethan
>
>
> =====
> Visit "The Seventh Continent"
> http://penguincentral.com/penguincentral.html
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
>
>
Received on Fri Jul 06 2001 - 22:45:03 BST