Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
More EPROM stuff
81 views
Skip to first unread message
et...@whidbey.com
Dec 7, 2019, 1:20:48 PM12/7/19
to
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
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
Dec 7, 2019, 6:21:41 PM12/7/19
to
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
> Now on to the good stuff. I bought the GQ-4x4 Universal Programmer.
> 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.
et...@whidbey.com
Dec 7, 2019, 7:06:57 PM12/7/19
to
On Sat, 7 Dec 2019 15:21:37 -0800 (PST), whit3rd <whi...@gmail.com>
wrote:
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
wrote:
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
Dec 7, 2019, 8:16:57 PM12/7/19
to
whit3rd
Dec 7, 2019, 8:53:41 PM12/7/19
to
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 <whi...@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.
> On Sat, 7 Dec 2019 15:21:37 -0800 (PST), whit3rd <whi...@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
> download?
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
Dec 7, 2019, 9:29:03 PM12/7/19
to
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 :-#)#
Unknown
Dec 10, 2019, 6:46:12 PM12/10/19
to
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
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
et...@whidbey.com
Dec 10, 2019, 7:36:54 PM12/10/19
to
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
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
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
Chris Jones
Dec 12, 2019, 7:24:35 AM12/12/19
to
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.
0 new messages