[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [N8VEM-S100:597] Re: S-100 8086 Up and Running
- To: firstname.lastname@example.org
- Subject: Re: [N8VEM-S100:597] Re: S-100 8086 Up and Running
- From: Bill Lewis <wrl...@gmail.com>
- Date: Tue, 27 Dec 2011 10:53:37 -0500
- Authentication-results: gmr-mx.google.com; spf=pass (google.com: domain of wrl...@gmail.com designates 184.108.40.206 as permitted sender) smtp.mail=wrl...@gmail.com; dkim=pass (test mode) head...@gmail.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EbyAFci7UPyGgltiH4NMNn9DlzxOqAXIRyS3naYYGgQ=; b=bqjmyFGxX13CBepeatHi+6rtBasf2yWO7+X/H1KsRBGyNhVur9CPMq5z1+EN3fOXCK akSNx/5So5aTuK0iAFJ+eAy0WIskfbeBiM/LzRiRhbIzNYP/jAQD7p1zUr2CgOXCONwi XfxAT/Nrmxfm0zOp2esIeWqh8rS656mbAVZlA=
- In-reply-to: <59579FA3-BBD1-4AEE-B296-D2B2C204F8F4@mac.com>
- References: <email@example.com> <CAPSA6c9SaB2M3eOvnkCR-86RDqTtv7eGXPpFTcgp4=Ovejt=6A@mail.gmail.com> <59579FA3-BBD1-4AEE-B296-D2B2C204F8F4@mac.com>
- User-agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
When I made my first EPROM programmer and started playing
with it, I encountered a 2716 (Intel, I believe) that had
some stuck bits.
Of course, I assumed for a long time my programmer or its
software was the reason. But it wasn't. The chip was
A couple years later my roommate got a summer intern job
at TI someplace where they tested parts. He came back
with a barrel full of TMS 2516's or 2532's. I forgot which.
But they were the non-standard ones. I designed around them
since they were free and in later years regretted that
decision many times, being stuck with those pigs in a poke.
On 12/27/2011 10:28 AM, Douglas Goodall wrote:
Around the same time, I was working at a startup using quite a few
2716's. We were having quite a lot of trouble with them.
I came up with a technique for doing quality assurance on them
based on checking the content of the EPROM over time while
It seems that some cells take longer than others, and the later
portions of the erasing time is spent clearing the recalcitrant bits.
As it turns out, in some less well made EPROMS, after a while,
you may not be able to clear them all.
So I came up with another technique. Instead of demanding that the
EPROM go all the way to blank, once you have done what is
reasonable time-wise to clear it, you analyze the contents of the
mostly cleared EPROM to see if you can live with the stuck bits.
Perhaps they are towards the end in section you may not need if the
code does not fill the device. Or in the case at the time, we were using
12 2716's in each machine. There was always a possibility that one
of the twelve different EPROM images would happen to have a
correspondence of the stuck bits to the bit pattern desired, so no harm
Anyway we found that most EPROMS cleared by about the 60% time
frame of the erasing cycle, and those PROMs that had bit that didn't
clear until the last 10-20% of the erasing cycle were best declared
unstable and unreliable.
There was one other effect I noticed.
As production continued, we had regular incoming shipments of PROMs,
and we would program them and send machines out. If the machines
came back for re-programming, we would take the PROMs out in put them
in the to-be-used bin.
They would be reprogrammed and sent out, and if things went well they
stayed out. But if not they came back and the PROMs got pulled and put
back in the bin.
Then we went through a period of time when Intel had trouble with their
allocations and we missed several shipments. The to-be-used bin got
fairly low, and we also seemed to be having a lot of trouble getting
machines to run reliably.
At a certain point I realized that through natural selection, the good proms
went out and stayed out unless a programming change occurred, but
otherwise they stayed in the field. The realization though was that a
number of proms were poorly manufactured and resulted in machines
being returned for service.
At a certain point I suggested to management that there would be a
reduction of pain and suffering if w just tossed out the remaining proms in
the bin, many of which had been out an unknown number of times and had
been returned because of reliability problems. Due to natural selection, the
remaining PROMs we in actuality the pool of bad proms that had been
I implemented a procedure where a label underneath the PROM would get
another check mark each time the PROM was programmed, and a red dot
each time the prom came back in a troubled machine. Two red dots should
mean the PROM should not even been tried again.
But management in their infinite wisdom declared that 2716's were too rare
and expensive to throw any away, despite my observations. The tech time
trying to make those bad proms work costed less than the chips themselves,
up to a point.
Anyway that is my wisdom about PROMs, 2716's in particular.
And here we are in the future, and those existing 2716's, many of which were
harvested from old equipment, are truly an unknown in terms of reliability
and stuck bits..
Perhaps I should build a smart erased that profiles the chips while they
are erasing, instead of the simple,, "its blank" or "its not" test
On Dec 27, 2011, at 5:52 AM, Bill Lewis wrote:
35 years ago I left a 2716 or 2532 or something of that ilk outside
"in the sun" for a week. Granted, this was in gloomy Upstate NY.
But it was not erased.
Question on erasing though. Is exposure cumulative?
If you put a chip in the eraser for 1/2 the require time, and stop.
When you start again, will it require the full time, or only half?
On Mon, Dec 26, 2011 at 11:28 PM, John Monahan <mon...@vitasoft.org
FWIW Leon, the newer high capacity EPROMS have tiny cells and so
more susceptible to UV exposure. The old 2716's etc. were hard to
with a proper UV lamp! Remember with erasing, you move electrons
isolated charged island on a silicon insulator. It's not an all or
effect, as the charge builds up the cells with 0's will be
high speed reads.