Couldnt really find a section for this..

[88GreenVN]

I just used the dos program x2444 see blow, any suggestions?

[festy]

That was written for a specific programming interface, not the programmer you have.
what happens when you try and write with ponyprog?

[88GreenVN]

I was using the programmer hardware for that program (ie I built the circuit in the PDF for the exe) The thing I like about this hardware is it has an LED so you can see when the serial port is communicating with it.

[antus]

It looks old enough that you might need a real (and old) dos computer, not a windows dos shell to make it work.

[88GreenVN]

yep that's it, and also i just tested writing to it, put the store recall pins on vcc as if ponyprog wasn't reading or write to it then there was only 300mv so it seems to enough to trigger a store, so now i guess i need another valid file to write and then ill fire it up.

What do you mean here, this seems to be the bit that is not working for me. I have pin 6,7,8, set to vcc so is that right?

When I put the meter across 5 and 8 I get -.494v. During the read and write I can not see the reading.

[88GreenVN]

Strange thing today, I inserted a chip from a new cluster to start from scratch. Read the chip and when I wrote the chip back it gave me a failed message (no change) however when I re read the chip in it had retained the new hex code. So even thought the message tells me it has failed it saves the hex code. However when I put the chip back in the cluster to check it comes back with 555555. Do you think that first part is some kind of chip checksum? IE I just loaded the full bin and not replaced the last 3 sections.

So I can now read and write but when I put it back into the cluster I get the standard corrupted error. (I am using the test bin 348982 )

[festy]

The failure message isn't a checksum - it's probably a verification failure.
After writing the data, it then reads each byte back and compares returned vs expected, and for some reason they're not matching.
Did you re-read the chip before putting it back in the cluster? Was every byte exactly the same as the test bin?
The fact that you're getting the 5s displayed means you're at least modifying the eeprom in _some_ way, which is an improvement over not being able to write at all

[88GreenVN]

Just to let you know, I have one working.

Still get the failed message but when I reinserted it back into a working cluster, it showed the correct reading.

So looks like my main issue was the program reporting it had failed and a number of corrupt chips from me playing.

Very cool, Now I have to look around for something else to work on, that was fun!

Again thanks to this great group for the willingness to stick with it

[88GreenVN]

255937 is the target.
First the digit-pair nibbles -
25 59 37
So now to get the checksum word for the group, add the digit pairs together - but remember these are hexadecimal ((25+59+37)^FF) = 4A, and has cmp of B5.
so now we've got 4AB5

Still a bit of logic issues with the total check digit.

eg 148856

(14+88+56 )^FF) = Hex (E+58+38) = 61 9E = After all the look ups and reversals = 7986

However this fails 7986 d728 ee11 956a

What have I missed this time?

[festy]

"but remember, these are hexadecimal" - not "then convert them to hexadecimal"