28Cxxx EEPROM Programmer

[BigDumbDinosaur]

UnaClocker wrote:

Ok, gave it a whirl with a 32k image on 28C256 chip, write in 4.6 seconds and verified correct. WAY faster than before, good job! I think it was taking 3-4 minutes on the old version.

4.6 seconds sounds about right for a 28C256. Looks as though it's working for you.

[UnaClocker]

The erase seems to work, it seems near instant. Blank Check doesn't do anything when I click it. In fact, when I click "Run Sequence" with all 4 checked, it stops on the blank check and the "Run Sequence" stays greyed out after that.
The GUI looks more refined and cleaner, I like it.

[rpress]

Oh somehow that's not the newest version. I played around with the buttons and briefly lost the code for that one. Anyway I updated that post with a version that should work, the same as the code in my repo. Thanks for testing it.

[rpress]

I've built the boost circuit and it works fine, I tweaked a few things to optimize it. It's nice that the voltage can be changed depending on the chip used. The Arduino sketch is unchanged, the voltage was very close to the calculation.

Another thing to consider is going with the 74HC164 instead, as the latch is not needed. This will free up an I/O pin and take less board space.

[Aslak3]

In case anyone's interested, I too have made a 28C256 EEPROM programmer. I made it for my 6809 based project. My programmer uses counters instead of shifters, and a standard ATMEGA8. My main motivation for making my own programmer was that nearly all the comercial ones work only on Windows. Plus of course it was done for fun.

Parts list:

* ATMEGA8
* 74HC590 8 bit counter
* Push button
* 3.5mm jack plug for serial
* USB socket for power
* LEDs and resistors

You can read about on my blog:

http://aslak3.blogspot.co.uk/2013/03/ee ... rcuit.html
http://aslak3.blogspot.co.uk/2013/03/ee ... -code.html
http://aslak3.blogspot.co.uk/2013/03/th ... ng-on.html
http://aslak3.blogspot.co.uk/2013/04/ee ... d-and.html

If anyone wants a PCB I made up 10 and have about 8 spare.

[mkl0815]

@rpress: OK, I found the time to have a closer look at the GUI and the arduino code. Many thanks again for your improvements and changes. I will do some tests with a Leonardo clone too, if I ever manage to solder the ZIF socket on UnaCLokcers PCB
I hope this week I'll get the time for this finally. What are the reasons for the "sequence" in the java GUI? I see the point, if you want to verify the image that is burned, but why should I erase, clear and write in one sequence? Are there special requirements for other (E)EPROMS then 28Cxx?
You also changed the offset list. It's OK to extend the list, but why you use these "strange" steps? I think in some projects it is a good practice to devide a 32k or 8k chip logically into different parts. You may have the basic IO routines in the first 1k (0x0000 to 0x03ff) of the EEPROM, maybe from 0x0400 to 0x0fff you have you basic interpreter, or what ever. So I think at least 1k steps for the offset should be possible.
On my Mac you GUI appears always over the top of all other windows, even if the program is not the active one. Also the size of the window is not right after the program started. Is this only MacOS related, or does anybody has the same behavior on Windows or Linux? I tried the binary version you uploaded to this forum.
You asked about the 57600 baud rate I set for communication. This had historical reasons, because the first plan was to create a board like Aslak3 posted here. A standalone Atmega328p running with the internal 8MHz clock. Therefor normally you would not use a rate higher then 19200, because of an increasing error rate. My first prototype used the Arduino nano with a 16MHz clock and higher rates were possible. I set it to 57.600 sometime and never changed it again. I've tested with my prototype today, but everything higher then 115.200 caused communication errors. This may caused by my USB hub, because I have also problems with my logic analyzer if it is connected via the hub rather then using the direct usb port on my MacBook. So using 115.200 as the "default" rate seems to be a good compromise.

My intention for this project is still to keep it real simple, so that everybody is able to build it and use it. UnaClockers PCB was a big step in that direction. There are always possibilities to make this better, but I'd like to keep it as simple as possible. Adding a feature to write EPROMs with a 12V booster circuit is really cool and we should try to have a second Arduino Shield that covers the additional parts. I think I will take the changes to the ardino sketch into the "main line" of the project and make some "quality tests" burning eeproms and reading them back using my prototype and the arduino shield. The java part will also be updated to respect the changes on the Arduino firmware. But I will leave the gui unchanged in this first step. Maybe we should use the github functionality to handle this project. Issue tracking is a good start to manage feature requests and discussing feature changes.

Mario.

[rpress]

mkl0815 wrote:

What are the reasons for the "sequence" in the java GUI? I see the point, if you want to verify the image that is burned, but why should I erase, clear and write in one sequence? Are there special requirements for other (E)EPROMS then 28Cxx?

Yes, most Flash memory devices require a specific erase procedure. The 28C256 does not require it, but it does have a hardware erase that is much faster than writing to each byte individually.

mkl0815 wrote:

You also changed the offset list. It's OK to extend the list, but why you use these "strange" steps? I think in some projects it is a good practice to devide a 32k or 8k chip logically into different parts. You may have the basic IO routines in the first 1k (0x0000 to 0x03ff) of the EEPROM, maybe from 0x0400 to 0x0fff you have you basic interpreter, or what ever. So I think at least 1k steps for the offset should be possible.

The usual reason that the offset it used, is that the chip is bigger than desired so some address lines are not needed. But the unneeded address lines might be high or low, so on a 32k chip maybe every 8k would make sense, and smaller chips could use smaller offsets. Dividing the chip up like you say is indeed very common! But I have not seen separate binaries being made with these unique offsets, it seems like it would be a pain to burn it. The usual way is to have the linker put everything into one binary file at the right locations.

Maybe you do something different than what I have seen, no problem there. I think it you want every 1k, something other than a drop down box is needed because there are just too many options. I guess it could be a text input box too but then it's hard to limit the acceptable range of values.

mkl0815 wrote:

On my Mac you GUI appears always over the top of all other windows, even if the program is not the active one. Also the size of the window is not right after the program started. Is this only MacOS related, or does anybody has the same behavior on Windows or Linux? I tried the binary version you uploaded to this forum.

It seems the "always on top" was checked sometime, but I have already pushed a fix for that. I changed the GUI style to "native" so it looks a lot better, but I guessed there could be problems. I tested on Win7 and Ubuntu but I don't have a Mac. If the window needs to be a bit wider than that is no problem, but not too much or else it won't fit on my netbook screen.

mkl0815 wrote:

You asked about the 57600 baud rate I set for communication. This had historical reasons, because the first plan was to create a board like Aslak3 posted here. A standalone Atmega328p running with the internal 8MHz clock. Therefor normally you would not use a rate higher then 19200, because of an increasing error rate. My first prototype used the Arduino nano with a 16MHz clock and higher rates were possible. I set it to 57.600 sometime and never changed it again. I've tested with my prototype today, but everything higher then 115.200 caused communication errors. This may caused by my USB hub, because I have also problems with my logic analyzer if it is connected via the hub rather then using the direct usb port on my MacBook. So using 115.200 as the "default" rate seems to be a good compromise.

Ok that sounds good to me. The Leonardo is nice because it doesn't even care what the bps is set to, it runs flat out all the time. Maybe in the future a "negotiate" can occur to set the speed to the highest one that works.

mkl0815 wrote:

My intention for this project is still to keep it real simple, so that everybody is able to build it and use it. UnaClockers PCB was a big step in that direction. There are always possibilities to make this better, but I'd like to keep it as simple as possible. Adding a feature to write EPROMs with a 12V booster circuit is really cool and we should try to have a second Arduino Shield that covers the additional parts. I think I will take the changes to the ardino sketch into the "main line" of the project and make some "quality tests" burning eeproms and reading them back using my prototype and the arduino shield. The java part will also be updated to respect the changes on the Arduino firmware. But I will leave the gui unchanged in this first step. Maybe we should use the github functionality to handle this project. Issue tracking is a good start to manage feature requests and discussing feature changes.

Mario.

Okay, whatever you'd like to do is fine. I am happy, I have a working programmer. I wanted to give my changes back if anyone wants them, and I am happy to help if you would like anything else.

Thanks again,
Ryan

[UnaClocker]

Yeah, great work guys. When I run out of the first batch of boards, I'll redesign the board with the booster circuit, and the ZIF holes will definitely be bigger. It should be possible to build the board without the booster components, if they aren't needed/wanted.

[rpress]

Aslak3 wrote:

In case anyone's interested, I too have made a 28C256 EEPROM programmer.

Nice project. I like the use of the counter, makes it fast to go to the next address!

[Aslak3]

rpress wrote:

Nice project. I like the use of the counter, makes it fast to go to the next address!

Thanks.

Yeap, and since generally all the programmer needs to do is increment, and reset, the address (for writing, and validating) this works very nicely. Even seeking, if you wanted to do it, is not so bad. The average time to count to an arbitrary address is in the order of a few miliseconds.

[scotws]

Just wanted to report that I finally, finally got to put Mario's Meeprommer to use (with UnaClocker's Arduino shield), and it worked perfectly. Thanks again for all the work, guys.

[Justin]

I built something very similar to this recently. A few differences:

1. It programs 2764s. That's what I chose to use because I had a bag of them lying around
2. Only uses 2 I/O lines for the shift registers instead of 3. You can tie SRCLK and RCLK together, you just have to clock it an extra time at the end to move the SR bits to the output latches.
3. All of the software is in the Arduino. It accepts Intel Hex record format. There is no GUI or CLI on the host - any terminal program that can upload a file and delay between lines will work. I use TeraTerm.

I built it on a solderless breadboard and it goes together in about 30 minutes. It is fragile and error-prone, but I only needed to burn a couple of ROMs with it to get my 6502 SBC online.

The Unaclocker and others described here look very nice and are clearly more mature, solid products. I wish I had seen them before doing my own - I probably wouldn't have bothered But, just in case anyone needs to burn a 2764 or wants to integrate some of these features into their own design, I have attached a copy of my code. Feel free to do whatever you'd like with it.

[UnaClocker]

I thought you needed 12v to program the 27 series eproms.. What are you doing for the +12v?

[Justin]

UnaClocker wrote:

I thought you needed 12v to program the 27 series eproms.. What are you doing for the +12v?

The particular device I'm using (2764) needs 21 volts. I just use my bench supply to provide the 21 volts between the black and red jumpers that are exposed in the picture. I have the software prompt me to manually connect and disconnect it at the beginning and end of a write operation.

I am using the Arduino itself as the 5 volt supply. The 21 volts ONLY goes to the Vpp pin and only when it's in write mode. I found out the hard way that if you leave Vpp at 21V during an Arduino reboot it will corrupt the ROM

IIRC, your design uses a charge pump and a transistor switch to generate and control Vpp. That is a more elegant and foolproof way to do it.

[UnaClocker]

I sold out, all 10 of the boards I had made. I created a new board with rpress's revisions and just sent that off to the fab. I'll have to order some more eeproms to confirm the new design works. And rpress, I'll send you one of the new boards when they get here.