|
Joined: May 2004
Posts: 1,702 Likes: 1
Very Senior Member
|
Very Senior Member
Joined: May 2004
Posts: 1,702 Likes: 1 |
a lot of those techniques end up giving you 'stable, but still bad' reads however.
EEPROMS go bad, flash ROMs go bad (frequently) even mask ROMs go bad.
it's no different to floppies or cassettes in that sense, everything can fail, and eventually will fail.
|
|
|
|
Joined: Jan 2011
Posts: 248 Likes: 3
Senior Member
|
Senior Member
Joined: Jan 2011
Posts: 248 Likes: 3 |
I've been dumping eproms for decades and for some reason 2764s are particularly troublesome with inconsistent reads/verifies. Someone just sent me some dumps he made from a bunch of Northgate OmniKey keyboards, and two of them are bad. I should probably start logging which brands are the most troublesome.
Currently, I'm having the best luck reading them with a BP Micro BP-1200
|
|
|
|
Joined: Feb 2014
Posts: 796 Likes: 24
Senior Member
|
OP
Senior Member
Joined: Feb 2014
Posts: 796 Likes: 24 |
Interesting that 2764s are problematic. I'd tell you what make this chip is, but it has no markings on it after scraping off the label. I did have a idea, why not do a bunch of reads and count the number of reads that each bit is set. So if we sample it 32 times and get a different result, then we read it 2048 (0x800) times and see how many times each bit is set. If the count is less than 0x400, then we'll call it a low, otherwise a high.
// Dump 2764
//
// 22,23,25 -> not PROG, not E, not G
// 40-52 -> A0..A12
// 30-37 -> Q0..Q7
// and hooking up the GND and 5V to the arduino 5V
void setup() {
Serial.begin(9600);
pinMode(22,OUTPUT); // not PROG
pinMode(23,OUTPUT); // not E
pinMode(25,OUTPUT); // not G
for (int i=0;i<=12;i++)
{
pinMode(40+i,OUTPUT); // A0-A12
}
}
char buffer[32];
int dumparray[32];
void loop()
{
int groupsize = 16;
for (int base=0;base<(1<<13);base+=groupsize)
{
for (int i=0;i<groupsize;i++)
{
digitalWrite(22,HIGH); // NOT PROG
digitalWrite(23,LOW);
digitalWrite(25,LOW);
for (int j=0;j<=12;j++) digitalWrite(40+j,((i+base) & (1<<j))!=0 ); // a0..a12
delay(10);
int numsamples = 50;
int samplesarray[numsamples] = {};
int badreadflag = 0;
for (int sample = 0; sample < numsamples; sample++)
{
int outval = 0;
for (int j=0;j<8;j++) outval |= (digitalRead(30+j) ? (1<<j) : 0);
dumparray[i]=outval;
samplesarray[sample] = outval;
if ((sample > 0) && (samplesarray[sample] != samplesarray[sample-1]))
{
badreadflag++;
snprintf(buffer, sizeof(buffer), "%02x: %02x\n", (base+i), outval);
Serial.write(buffer);
}
}
if (badreadflag)
{
int bitsamplecount[8]={};
int dosamples = 2048;
for(int sample=0;sample<dosamples;sample++)
{
int outval = 0;
for (int j=0;j<8;j++) outval |= (digitalRead(30+j) ? (1<<j) : 0);
for (int j=0;j<8;j++) bitsamplecount[j] += (outval & (1<<j)) ? 1 : 0;
}
int calcval = 0;
for (int j=0;j<8;j++)
{
calcval |= ((bitsamplecount[j] > (dosamples/2)) << j);
snprintf(buffer, sizeof(buffer), "%02x: bit %x count = %02x\n", (base+i), j, bitsamplecount[j]);
Serial.write(buffer);
}
snprintf(buffer, sizeof(buffer), "%02x: calc value = %02x\n", (base+i), calcval);
Serial.write(buffer);
dumparray[i] = calcval;
}
}
snprintf(buffer, sizeof(buffer), "%08x ", base);
Serial.write(buffer);
for (int i=0;i<groupsize;i++)
{
snprintf(buffer, sizeof(buffer), "%02x ", dumparray[i]);
Serial.write(buffer);
}
Serial.println();
}
delay(10000);
}
so you see that if a bit is good, the count will read either 0x0 or 0x800, otherwise is will read something in between. At least it gives you an idea of which individual bits are suspect.
800: 9f
800: 8f
800: af
...
800: 9f
800: bf
800: 9f
800: bit 0 count = 800
800: bit 1 count = 800
800: bit 2 count = 800
800: bit 3 count = 800
800: bit 4 count = 382
800: bit 5 count = 3b9
800: bit 6 count = 00
800: bit 7 count = 800
800: calc value = 8f
801: a8
801: 2a
801: e8
801: 08
...
801: 8a
801: 48
801: 08
801: 4a
801: c8
801: bit 0 count = 00
801: bit 1 count = 2c8
801: bit 2 count = 00
801: bit 3 count = 800
801: bit 4 count = 00
801: bit 5 count = 268
801: bit 6 count = 314
801: bit 7 count = 407
801: calc value = 88
802: 00
802: 02
802: 42
802: 40
802: 02
802: 00
802: 42
802: 40
802: bit 0 count = 00
802: bit 1 count = 260
802: bit 2 count = 00
802: bit 3 count = 00
802: bit 4 count = 00
802: bit 5 count = 36
802: bit 6 count = 288
802: bit 7 count = 00
802: calc value = 00
etc.
...
|
|
|
|
Joined: Mar 2006
Posts: 1,069 Likes: 4
Very Senior Member
|
Very Senior Member
Joined: Mar 2006
Posts: 1,069 Likes: 4 |
rather than voting the bits to get the correct result, remember this about JEDEC eproms: if the bit is programmed/set and the floating gate has a non-zero voltage in it, it will read as a 0. if the bit is unprogrammed or the floating gate voltage has decayed to below the detectable threshold, it will read as a 1.
This effectively means: if a bit ALWAYS reads as a 1, it should (probably, unless it has decayed past the point where it reads inconsistently) be a 1. if a bit ALWAYS reads as a 0, it should be a 0. if a bit SOMETIMES reads as a 0, it should be a 0.
So what you should do is read the bad chip 100 times and binary AND together all of the dumps.
LN
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
1 member likes this:
exidyboy |
|
|
|
Joined: Mar 2006
Posts: 1,069 Likes: 4
Very Senior Member
|
Very Senior Member
Joined: Mar 2006
Posts: 1,069 Likes: 4 |
Also, heating up a bitrotten eprom like this (heated using a hair dryer or even a heatgun) may make it read more reliably. Kevtris did some tests with bitrotten eproms and a heatgun some time ago, although I don't remember the results offhand.
Slightly lowering(!) the voltage to the chip also helps, because the floating gate threshold comparator has a lower external voltage to compare against. So if the arduino you're using for dumping can run stably at 4.5v instead of 5v, this might help too.
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
|
Joined: Feb 2014
Posts: 796 Likes: 24
Senior Member
|
OP
Senior Member
Joined: Feb 2014
Posts: 796 Likes: 24 |
I see what you mean by the default value being 1. So if it reads 0 at all, then it should probably be a 0. Considering these roms are around 35 years old it's not surprising. I came across a text file that had some comments by kevtris that was interesting: <kevtris> well, you may want to talk about how an EPROM works first in basic terms
<kevtris> here's how an EPROM works: the EPROM is arranged as a bunch of individual memory cells that can hold a "1" when not programmed, or a "0" if programmed
<kevtris> the data is stored on the gate of a transistor; to program the EPROM, you inject electrons into the gate, where they get stuck. An ultraviolet light erases the EPROM, because it lets the electrons "leak" off the gate
<kevtris> Since no insulator is perfect, these electrons will eventually "leak" off, so the cell reverts back to an erased state, taking the data with it
<kevtris> the datasheets typically specify a 10 year guaranteed minimum programming lifetime
<kevtris> However, 20-25 years is about what they usually last
<kevtris> heat, ultraviolet light, and other things can cause premature erasure
<kevtris> There's no way to know when this effect will occur, and likely it will start out slowly, taking one or two cells out, then more as time goes on
<kevtris> if caught, it *may* be possible to "fix" the problems, but this is difficult, at best to do
<kevtris> I have seen bitrot first hand, so it is a real phenomena
<kevtris> I had 5 identical "things"* and all 5 had EPROMs on them
<kevtris> * = "things"... hard to describe. It was a modem with 4 LED displays and a keypad, meant to enter stock quotations :-)
<kevtris> I noticed that 2 of them didn't work right; they would crash when I tried various things on them
<kevtris> so I pulled all 5 EPROMs eventually (to re-use them) and sure enough, those 2 had some bit-rot on the EPROMs
<kevtris> some of the bits had reverted to a non-programmed (erased) state... i.e. bits changed from 0 to 1, and there were no 1 to 0 changes
<kevtris> 1 = erased, 0 = programmed
<kevtris> you cannot program a "1" if the cell has a 0 on it unless you erase the whole EPROM
<kevtris> using the EPROM causes slow degradation too, but we're talking 10+ years of 24/7 use here, at over a million reads a second
<kevtris> casual playing of proto's will not impact the lifetime more than a couple minutes or seconds probably
<blackjax> however, some one throwing uncovered eproms onto a scanner to brag about his find could cause some harm
<kevtris> naaah
<kevtris> fluorescent light won't hurt them
<kevtris> shortwave UV is what erases them
<blackjax> the stuff that we can't see
<kevtris> flo's may hurt it but it'd take 2-5 years to erase it under continuous exposure
<kevtris> sunlight would take several weeks of full sun and no clouds
<kevtris> there really is no sub for a good eraser
<reio-ta> bj: so that means dont take your proto in with ya when you go into a suntan chamber
<kevtris> naah that won't work either
<kevtris> that's the wrong wavelength
<kevtris> that's UVa
<kevtris> you need UVb or shorter... germicidal lamps are usually the ones used
|
|
|
|
Joined: Feb 2014
Posts: 796 Likes: 24
Senior Member
|
OP
Senior Member
Joined: Feb 2014
Posts: 796 Likes: 24 |
Trying to understand exactly how the PTS sensor (print timing sensor) works, there's a disk with slots (or slits) in it with a photosensor. When the drive belt moves, so does this sensor disk. I count 48 slits on this picture, and making a mark on the sensor disk and on the paper where the printhead is, then sliding it left or right and marking when that point on the disk comes around again, I get .8 of an inch (I make 10 marks across 8 inches from the origin mark) for a full revolution. Counting the slits and multiplying by 10 revs/8 inches 1.25 revs/inch * 48 slits/rev = 60 slits per inch or 60 dpi (which sounds like a reasonable dpi since it can print at 120dpi or 240dpi) ![[Linked Image from i.imgur.com]](https://i.imgur.com/zQRjvYo.png)
|
|
|
|
Joined: Feb 2014
Posts: 796 Likes: 24
Senior Member
|
OP
Senior Member
Joined: Feb 2014
Posts: 796 Likes: 24 |
Ok, I think I've figured out why the fx-80 won't print properly. I had a misconception about what fires the pins, it's strictly based upon writing directly to the printhead pins, nothing more. For some reason, I thought it was tied to the PTS signal. Looking at the diagram, I got the idea that it was dependent on the PTS signal. It is, but only indirectly, as everything goes through the main cpu. ![[Linked Image from i.imgur.com]](https://i.imgur.com/eBELHzU.png) ![[Linked Image from i.imgur.com]](https://i.imgur.com/XdSrMvh.png)
|
|
|
|
Joined: Feb 2014
Posts: 796 Likes: 24
Senior Member
|
OP
Senior Member
Joined: Feb 2014
Posts: 796 Likes: 24 |
The rom corruption can be seen in some of the italic characters from the self test: * + , - . / 01234 ![[Linked Image from i.imgur.com]](https://i.imgur.com/I4rIhLe.png)
|
|
|
|
Joined: Feb 2014
Posts: 796 Likes: 24
Senior Member
|
OP
Senior Member
Joined: Feb 2014
Posts: 796 Likes: 24 |
I was able to patch the font corruption by finding the same italics sequence from a different rom: ![[Linked Image from i.imgur.com]](https://i.imgur.com/0SFstEg.png)
|
|
|
Forums9
Topics9,069
Posts118,922
Members5,014
|
Most Online890 Jan 17th, 2020
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|