More EPROM stuff

First of all I'd like to say thanks to everyone who replied to
myprevious EPROM posts. I think I responded to everyone but I am a bit
scatter-brained and I miss stuff.
Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.
For a hundred bucks including shipping it seemed like a good deal. In
the box was not only the programmer itself but also the USB cable, an
EPROM puller, and 3 adapter boards for SOP 17-1.27, PLCC32, and PLCC32
for 27C64-27C512 devices.
I hadda also buy a UV eraser but I found a cheap one that works just
fine. After all I only need to 6 EPROMs, but I will be making several
copies so maybe 24 EPROMs total.
But the best part is the copy process. I inserted an erased chip
to check if it was blank and it was. So in goes the chip to copy. it
gets read and then I swap in the blank chip and program it. Just had
to click the write button. So easy.
In a couple weeks the machine will have a window of time where I
can do the copying of the chips particular to this machine. then I can
test the copies and if they work I'll keep the originals in a safe
place and just use the copies.
Eric

 

[whit3rd]

On Saturday, December 7, 2019 at 10:20:48 AM UTC-8, et...@whidbey.com wrote:

Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.

... So in goes the chip to copy. it
gets read and then I swap in the blank chip and program it.
...test the copies and if they work I'll keep the originals in a safe
place and just use the copies.

You might want to consider reading the originals several times, and
check for differences (MD5 checksum would work, diff will give more detail),
to detecf soft failure.
Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read
pattern is the correct data.

 

On Sat, 7 Dec 2019 15:21:37 -0800 (PST), whit3rd <whit3rd@gmail.com>
wrote:

On Saturday, December 7, 2019 at 10:20:48 AM UTC-8, et...@whidbey.com wrote:

Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.

... So in goes the chip to copy. it
gets read and then I swap in the blank chip and program it.
...test the copies and if they work I'll keep the originals in a safe
place and just use the copies.

You might want to consider reading the originals several times, and
check for differences (MD5 checksum would work, diff will give more detail),
to detecf soft failure.
Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read
pattern is the correct data.

I'm not sure how to check one read from another. The programmer
software has a command called verify that somehow "verifies" the
information written to the EPROM. I don't see a checksum command. I
suppose I could save the program in the buffer as a text file and
compare the text files.
Do you have any suggestions? Is MD5 checksum a program I can
download?
Thanks,
Eric

 

[John-Del]

On Saturday, December 7, 2019 at 6:21:41 PM UTC-5, whit3rd wrote:

On Saturday, December 7, 2019 at 10:20:48 AM UTC-8, et...@whidbey.com wrote:

Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.

... So in goes the chip to copy. it
gets read and then I swap in the blank chip and program it.
...test the copies and if they work I'll keep the originals in a safe
place and just use the copies.

You might want to consider reading the originals several times, and
check for differences (MD5 checksum would work, diff will give more detail),
to detecf soft failure.
Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read
pattern is the correct data.

That even happens with modern 25 series eeproms. I record the eeprom then verify it back using the programmer's software. If I get any errors, I keep copying it until the copy I have matches the .bin on the eeprom. Once I get a verified copy, I delete the others.

 

[whit3rd]

On Saturday, December 7, 2019 at 4:06:57 PM UTC-8, et...@whidbey.com wrote:

On Sat, 7 Dec 2019 15:21:37 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:

You might want to consider reading the originals several times, and
check for differences (MD5 checksum would work, diff will give more detail),
to detecf soft failure.

I'm not sure how to check one read from another.
Do you have any suggestions? Is MD5 checksum a program I can
download?

The usual programmer software (last one I used supported Motorola S-format but
decades pass) can make a binary or hexadecimal dump file, with
no extraneous info (date/time, for instance). It's a nuisance to proofread one such
file against another, so one would make a checksum; the MD5 algorithm can
hash large files down to 128 bits, and match of such hashes implies
bit-by-bit match of files, or even directories of files. There's lots of utilities that
can do such a hash, I've found 'em for Windows.

The 'verify' function tests a programmed unit against a file. What I was
suggesting, was comparison of twenty dumps from the elderly unit
against each other, to see if there were 'weak' bits.

The reason to retain twenty copies, is to pick the most-likely-to-be-correct
bit values if there IS a difference found, and the verify might not give enough
detail in its report. A checksum that's the same 17 times in 20 is probably
indicative of the 'right' data.

 

[John Robertson]

On 2019/12/07 5:53 p.m., whit3rd wrote:

On Saturday, December 7, 2019 at 4:06:57 PM UTC-8, et...@whidbey.com wrote:
On Sat, 7 Dec 2019 15:21:37 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:

You might want to consider reading the originals several times, and
check for differences (MD5 checksum would work, diff will give more detail),
to detecf soft failure.

I'm not sure how to check one read from another.
Do you have any suggestions? Is MD5 checksum a program I can
download?

The usual programmer software (last one I used supported Motorola S-format but
decades pass) can make a binary or hexadecimal dump file, with
no extraneous info (date/time, for instance). It's a nuisance to proofread one such
file against another, so one would make a checksum; the MD5 algorithm can
hash large files down to 128 bits, and match of such hashes implies
bit-by-bit match of files, or even directories of files. There's lots of utilities that
can do such a hash, I've found 'em for Windows.

The 'verify' function tests a programmed unit against a file. What I was
suggesting, was comparison of twenty dumps from the elderly unit
against each other, to see if there were 'weak' bits.

The reason to retain twenty copies, is to pick the most-likely-to-be-correct
bit values if there IS a difference found, and the verify might not give enough
detail in its report. A checksum that's the same 17 times in 20 is probably
indicative of the 'right' data.

I suggest using the verify function on the programmer several times,
however you release and then tighten the ZIP lock-lever prior to each
verify.

Good quality programmers (like the Xeltek SP-610P) have a handy feature
that allows for verify to be done at 5% below and above the 5.00 Vcc. I
enable that by default because every now and then it catches a bad chip.

John :-#)#

 

[Dave M]

Eric,
The "Verify" feature doesn't compute a checksum for the data. After the
device is programmed, the Verify simply reads the contents of the device
and compares it, bit by bit, with the original data file.. If the
contents of the device are the same as the original data file, then the
device is verified as being successfully programmed.
It's usually a good idea the run the verify function 3 or 4 times, just
to be absolutely certain that the device has the correct data. If the
verify function returns an error, that means that the device either
didn't accept the data correctly, it might have not been completely
erased, or it might just be a bad device.
Cheers,
Dave M


On Sat, 07 Dec 2019 16:06:55 -0800, etpm@whidbey.com wrote:

On Sat, 7 Dec 2019 15:21:37 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:

On Saturday, December 7, 2019 at 10:20:48 AM UTC-8, et...@whidbey.com wrote:

Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.

... So in goes the chip to copy. it
gets read and then I swap in the blank chip and program it.
...test the copies and if they work I'll keep the originals in a safe
place and just use the copies.

You might want to consider reading the originals several times, and
check for differences (MD5 checksum would work, diff will give more detail),
to detecf soft failure.
Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read
pattern is the correct data.
I'm not sure how to check one read from another. The programmer
software has a command called verify that somehow "verifies" the
information written to the EPROM. I don't see a checksum command. I
suppose I could save the program in the buffer as a text file and
compare the text files.
Do you have any suggestions? Is MD5 checksum a program I can
download?
Thanks,
Eric

 

On Tue, 10 Dec 2019 17:46:03 -0600, Dave M <dgminala at mediacombb dot
net> wrote:

Eric,
The "Verify" feature doesn't compute a checksum for the data. After the
device is programmed, the Verify simply reads the contents of the device
and compares it, bit by bit, with the original data file.. If the
contents of the device are the same as the original data file, then the
device is verified as being successfully programmed.
It's usually a good idea the run the verify function 3 or 4 times, just
to be absolutely certain that the device has the correct data. If the
verify function returns an error, that means that the device either
didn't accept the data correctly, it might have not been completely
erased, or it might just be a bad device.
Cheers,
Dave M

It seems to me that the best way to test the chips after programming
and using the verify function is to just place them back into the
machine and make sure the machine runs correctly. If the machine
functions all work then the chip must be good. But I will run the
verify test a few times on each chip just for luck.
Eric

On Sat, 07 Dec 2019 16:06:55 -0800, etpm@whidbey.com wrote:

On Sat, 7 Dec 2019 15:21:37 -0800 (PST), whit3rd <whit3rd@gmail.com
wrote:

On Saturday, December 7, 2019 at 10:20:48 AM UTC-8, et...@whidbey.com wrote:

Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.

... So in goes the chip to copy. it
gets read and then I swap in the blank chip and program it.
...test the copies and if they work I'll keep the originals in a safe
place and just use the copies.

You might want to consider reading the originals several times, and
check for differences (MD5 checksum would work, diff will give more detail),
to detecf soft failure.
Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read
pattern is the correct data.
I'm not sure how to check one read from another. The programmer
software has a command called verify that somehow "verifies" the
information written to the EPROM. I don't see a checksum command. I
suppose I could save the program in the buffer as a text file and
compare the text files.
Do you have any suggestions? Is MD5 checksum a program I can
download?
Thanks,
Eric

 

[Chris Jones]

On 08/12/2019 05:20, etpm@whidbey.com wrote:

First of all I'd like to say thanks to everyone who replied to
myprevious EPROM posts. I think I responded to everyone but I am a bit
scatter-brained and I miss stuff.
Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.
For a hundred bucks including shipping it seemed like a good deal. In
the box was not only the programmer itself but also the USB cable, an
EPROM puller, and 3 adapter boards for SOP 17-1.27, PLCC32, and PLCC32
for 27C64-27C512 devices.
I hadda also buy a UV eraser but I found a cheap one that works just
fine. After all I only need to 6 EPROMs, but I will be making several
copies so maybe 24 EPROMs total.
But the best part is the copy process. I inserted an erased chip
to check if it was blank and it was. So in goes the chip to copy. it
gets read and then I swap in the blank chip and program it. Just had
to click the write button. So easy.
In a couple weeks the machine will have a window of time where I
can do the copying of the chips particular to this machine. then I can
test the copies and if they work I'll keep the originals in a safe
place and just use the copies.
Eric

My only piece of advice:
Always double check the orientation of the chip in the socket when you
are putting it into the machine. It is very frustrating to see through
the window the brief incandescence from the melting VDD bondwire.