Well, this post contains both good news and bad news:
Good News part 1.
I spent the later half of yesterday wiring up the arduino to the EEPROM board proper. I then began to check basic functionality such as proper voltages, proper and state of the EEPROM control lines. Everything checked out, so I decided to test with an NVRAM that has an identical pinout. I encountered a few errors in the software in this process.
The next round of testing dealt with the 12V erase line. Before actual testing I did a visual check and found I had arranged the circuitry improperly, such that the controller would get 12V on its I/O pin. I swapped it around to more closely match what I had designed, such that a diode would prevent backfeed to the controller. The pulse output from the optocoupler is 11.75V, still within the +/- 0.5V tolerance prescribed in the EEPROM's datasheet. Considering everything checked out, I decided to go ahead and test with the EEPROM.
This is where we reach the Bad News.
The reason I took on the task of making an EEPROM programmer, is because my last one failed, likely because of water damage through the leaking roof vent it was sitting under. The EEPROM couldn't be tested to see if it wasn't damaged as well, and so it sat for quite some time since. Initial testing did not look promising, initial dump read the device as containing all 0s, which should not be the case with an erased device, let alone one that has been programmed to contain a program. I forged forwards with the erase test, and I failed to perform a proper dump to ensure it was erased, only using my debug 'query size' option, which reported 128 bytes as expected with a device filled with all 1s.
That likely was not the case.
I tried to write to the device, and initally it managed to pass the verification check for the first two blocks, but it halted on the third, as it had encountered an error. I canceled and re-dumped the ROM data. The first 256 bytes indeed write succesfully, but everything after was either 0s or a byte of random data mixed in. This leads me to believe the EEPROM is irreparably damaged.
Good News part 2.
As a last ditch effort, I decided to dump out the data in the NVRAM I was testing with, and see if it could still retain data without power, so it could be used instead. The internal battery of the NVRAM is now more than 20 years old and I had no idea if it could still hold data. As it turns out, it can. What was written to it the previous night matched up perfectly with what I dumped out from it, so I still have memory to use until I can get a new EEPROM (making sure to get one with the ability to be rewritten on a per-byte basis without 12V).
For now I consider this project 100% done, allowing me to move on to writing software for my Z80 computer.
Good News part 1.
I spent the later half of yesterday wiring up the arduino to the EEPROM board proper. I then began to check basic functionality such as proper voltages, proper and state of the EEPROM control lines. Everything checked out, so I decided to test with an NVRAM that has an identical pinout. I encountered a few errors in the software in this process.
- The controller was not allowing the device to complete a read or write cycle before moving on to the next byte, fixed by adding a 1ms delay between pulling the read or write lines low, and pulling them back up.
- I accidentally left out a = in the test part of some if statements, so it would read as 'if(Error=1)' instead of 'if(Error==1)'. This caused the send/receive portions of the write and dump routines to fail out, thinking the Xmodem packet was being improperly received or sent.
- The first 128 bytes of the NVRAM was being rewritten with data from the last 128-byte block, this is due to the loop not exiting out immediately after receiving an <EOT> byte, which signals that the previous packet was the last one.
The next round of testing dealt with the 12V erase line. Before actual testing I did a visual check and found I had arranged the circuitry improperly, such that the controller would get 12V on its I/O pin. I swapped it around to more closely match what I had designed, such that a diode would prevent backfeed to the controller. The pulse output from the optocoupler is 11.75V, still within the +/- 0.5V tolerance prescribed in the EEPROM's datasheet. Considering everything checked out, I decided to go ahead and test with the EEPROM.
This is where we reach the Bad News.
The reason I took on the task of making an EEPROM programmer, is because my last one failed, likely because of water damage through the leaking roof vent it was sitting under. The EEPROM couldn't be tested to see if it wasn't damaged as well, and so it sat for quite some time since. Initial testing did not look promising, initial dump read the device as containing all 0s, which should not be the case with an erased device, let alone one that has been programmed to contain a program. I forged forwards with the erase test, and I failed to perform a proper dump to ensure it was erased, only using my debug 'query size' option, which reported 128 bytes as expected with a device filled with all 1s.
That likely was not the case.
I tried to write to the device, and initally it managed to pass the verification check for the first two blocks, but it halted on the third, as it had encountered an error. I canceled and re-dumped the ROM data. The first 256 bytes indeed write succesfully, but everything after was either 0s or a byte of random data mixed in. This leads me to believe the EEPROM is irreparably damaged.
Good News part 2.
As a last ditch effort, I decided to dump out the data in the NVRAM I was testing with, and see if it could still retain data without power, so it could be used instead. The internal battery of the NVRAM is now more than 20 years old and I had no idea if it could still hold data. As it turns out, it can. What was written to it the previous night matched up perfectly with what I dumped out from it, so I still have memory to use until I can get a new EEPROM (making sure to get one with the ability to be rewritten on a per-byte basis without 12V).
For now I consider this project 100% done, allowing me to move on to writing software for my Z80 computer.
Comments
Post a Comment