Hello everybody,

I hope this is the right place for this topic. In preparation for my own homebrew 6502 system I need a possibility to write data on a 28C64 or eventually the 28C256 EEPROM. I'm quite familiar with the AVR ATMega micro-controllers, especially with the Arduino boards and so I decided to build my own programmer based on the Atmega328 µC.

The 28C64 and 28C256 are 28 pin DIP chips and have up to 14 address lines (28C256). I also need 8 data lines and 3 additional lines for /WE, /OE and /CE. The programmer should be used by a serial connection, so I need 2 more lines for RX and TX.

In sum 27 lines. My preferred µC has only 20 GPIO pins that seems to be too less for my programmer. But for the address-lines I only need output and no input lines so I can use two 74HC595 shift register to get up to 16 address-lines with only 3 GPIOs used on the µC.

To be sure that everything works as expected, I first build up everything on a breadboard. Additionally I created a simple “16 bit line-sniffer” with 16 small LEDs and two ULN2803 darlington drivers to protect the “sniffed” bus from too much current consumption.

The first thing was to test the output of the address-lines. The Arduino IDE provides a simple function to shift out data to a single IO-line, using a second line as clock. But it's important to push the bytes in the right order and also set the right direction for the single bits (MSB or LSB).

While counting up all possible addresses in a loop, I could check that all 16 bits are shifted out in the right order.

The next thing was to set the data on my 8 bit data bus right. My first idea was to use a complete 8bit GPIO port form the Arduino to simplify reading and writing data. But unfortunately the only complete usable 8bit port on the Arduino board includes also the both serial-ports (RX,TX) that I need for the serial communication. So I had to cut my data byte into 8 bit-pieces setting them one by one to the choosen IO lines. To be sure that everything is connected right I used my little sniffer again read and check the data output. All these things were done without the 28C64 connected to the breadboard.

The next step was to play with the EEPROM itself. As a first step I tried to read the data from the EEPROM with the following procedure
* set databus for reading
* first disable output (/OE HIGH)
* enable chip select (/CE LOW)
* disable write (/WE HIGH)
* set address bus
* enable output (/OE LOW)
* read databus
*disable output (/OE HIGH)

Reading the complete EEPROM returns 0xFF for all bytes, as expected.

The next thing was to write data. There are two modes for writing on my AT28C64. Byte-write and page-write. Because page-write is more complex, I first started with writing single bytes by the following procedure
* first disable output,write and chip select (/OE,/WE,/CE HIGH)
* set address bus
* set data bus
* enable chip select (/CE LOW)
* enable write (/WE LOW)
* wait some micro seconds for the
* disable write (/WE HIGH)
* disable chip select (/CE HIGH)
* wait 10ms for the write cycle to finish

To test this procedure I counted a data byte from 0 to 0xff and wrote every step to the addresses from 0x0000 to 0x0100.

After that I used my reading function to check the written data.

Here is the output of my serial monitor:



It takes about 2.6 seconds to write 256 bytes. Over 96% of the writing time is caused by the 10ms write cycle after setting the /WE pulse. In the datasheet these 10ms are only listed for the “page write” mode, but trying to reduce the waiting time for a “byte write” caused wrong written data. So I have to live with that.

So the fist step is done. The next steps are

* moving from the breadboard to a prototype pcb with a zif socket
* replacing the arduino board with a single atmega328 µC
* creating a serial protocol that can be used easily for burning data to a eeprom

I'll keep you updated in this thread for the next things to come in this little project.
And sure, any additional ideas, tips and hints are welcome

_________________
How should I know what I think, until I hear what I've said.

Looks like a good job of bread boarding the programmer. It's been a while since I've programmed an EEPROM or Flash EPROM with code that I've written myself.

I am a bit surprised that you had to wait the full 10ms seconds to program each byte, since it appears that you are starting from a blank EEPROM.

The nominal programming time is generally less than 10ms, and the programming time, if I recall correctly, is directly related to the number of bits that are changing. Thus, when programming the EEPROM a byte at a time, it would be worth your effort to using the data toggle or data polling bits to determine when the programming cycle for each byte has completed. It has been my experience that using the data polling mode by reading bit 7 and/or bit 6, is significantly faster. I would further suggest that the page mode would be altogether much better, even faster, and worth the additional effort.

If I understand your timing values, your approach would require approximately 5 minutes and 30 seconds to program a 28C256 EEPROM. I don't know about you, but waiting five minutes for something is like an eternity in our high-speed world. Perhaps since this is for a retro project, time scales inversely with the target processor speed.

Look forward to reading more about your results with this project.

_________________
Michael A.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Just for reference, it takes about 2 seconds to program an Atmel 28C64B using page mode and polling. In the beginning I used the 10ms wait method and a byte at a time just to get some experience with the chips before I dug into the more efficient methods.

Given the price of commercial EEPROM programmers (seriously, what is wrong with these people), I can't stress enough how grateful I am for this project. I'll be happy to be the Clueless Beta Tester once the design is finished. And five minutes would not be a problem, I have to get more pizza occasionally anyway.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The whole project will be available as open source. I hope that I end up in a proper PCB design so anybody can order a PCB or etch its own and build his own programmer. If somebody wants to join the project, you are welcome. I would be pleased to share the work. Once the serial protocol is finished somebody could work on the PC side to send Data to the programmer.
Mario.

_________________
How should I know what I think, until I hear what I've said.

Hi again,

I attached the first draft of the protocol description that I want to implement for the programmer. Not alle features will be available in the first shots, but this is where I want to end up finally.
Any criticism, additional ideas, even laughing is welcome

Mario.

_________________
How should I know what I think, until I hear what I've said.

Have you considered using counters instead of shift registers to generate the addresses? They could be controlled by two lines (Reset, Clock pulse)

Since you will probably be programming the EEPROM addresses sequentially, outputting the next address would only take 1 clock pulse instead of the 16 you need now.

Admitidly, setting the program starting address if you are not starting from zero would take many more pulses.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

The atmega328 can generate a 10 MHz SPI clock (using 20 MHz crystal), so setting up the address only takes a few microseconds. The programming time is measured in milliseconds, so it's not really worth it to give up the flexibility of the shift registers.

Hey, cool! Found a few typos, and have one question about the ve command:

Typo: Any number bigger the 7fff will cause an error because you should never have a address beyond 0x7ffff. (an "f" too far).
Typo: * 02 - data lenght mismatch

In bw command: In cause that the write cycle need some time to finish, you may need to make some breaks of about 50 ms after each 100 bytes. --> If the write cycle needs some time to finish, you may have to insert some breaks of about 50 ms after each 100 bytes. (BTW, are those 100 hex or 100 decimal?)

In pw command: command is send (sent); returnvalue (space missing)

Could you provide an example for what ve returns? We should probably have a string in a high-level program to compare it with so we know they are speaking the same language.

I'll try to get a primitive Python CLI going in the next few days until a real programmer can put together something with a graphic interface.

Oh, and sooner or later we're going to have to have a name of this thing. I suggest "meepromer", for "Mario's EEPROMer", since you're doing all the work.

Here is a first Python fragment, pretty much only the interface so we can discuss if this is what we'll want to have. (It took me longer than I had thought because optparse is considered obsolete in 2.7, and I had to figure out how to use argparse instead. What will they think of next.) Ignore the single serial port routine, it doesn't do anything yet. Note that the suffix is .txt because the forum will not let me upload .py files, you'll have to change it.

Put briefly, I'd suggest flags for writing (-w, --write), reading (-r, --read), dumping as ascii (-d, --dump), diff writing of those bytes on the EEPROM that are different in the file (-D, --diff), and a verify function (-v, --verify) to make sure that EEPROM and file are the same. You can give the first address to be written to or read (-a, --address, default is 0000), and the number of bytes to be read or read (-b, --bytes, default 1). Supply a filename with -f or --file. There is a bunch of others stuff like --version or --info (gets information from the EEPROM).

Anything else that should go in there, anything we should do differently?

Unfortunately (well, for the project), the Longest Winter Ever seems to be finally over in Germany, and I'm going to be spending time in the garden the next few weeks getting the veggies going, so my projects here are going to slow down a bit, unless it rains a lot .

Hey, this is great. The python script is exactly what I was thinking about. Motivation is high to go further with the hardware and the firmware this weekend. The first things we should get up and running are serial communication and reading, writing binary data.
We should discuss which features should be implemented by the firmware and which features by the controlling software.
My approach was to get as much intelligence into the programmer as possible, so it can be used more flexible.

The "diff" option should be able to get the data either from the EEPROM itself and also from a file to speed up programming. My idea behind that is, that you have an iterative development process. You create your ROM file and write it to the EEPROM and test it. After that you make some changes in you programm and create a new rom-file. with the diff option you can then write only the few bytes that have changed between both rom-files to the EEPROM.
Mario.

_________________
How should I know what I think, until I hear what I've said.

After a long night and only a few hours of sleep I stumbled together a first version of the prototype. At the moment only the 15 address lines are connected to the ZIF socket. I had to use my 40 pin socket, cause my 28 pin ZIF socket are still on the way to me. By using my handy little bus-sniffer I could proof, that all lines are connected to the pins they belong to.

I did not start with a barbeone Atmeg328, because for development it's much easier to have a complete Arduino Nano to work with. It has a USB connector included that appears as a serial interface on the host computer and I can upload new firmware versions directly from the Arduino IDE without an additional programmer.
I think i will completely discard my idea to use a barebone Atmega328 chip. Because if somebody wants to build his own EEPROM programmer, he needs to get the firmware on the chip. This is done normaly be a external progammer. It can also be done by a serial connection based upload, but for that a proper "bootloader" on the chip (running at 8MHz internal clock) is needed.
For connecting the EEPROM programmer with a barebone Atmega328 you would also need some serial-to usb interface or at least a MAX323 converter.
The Arduino Nano starts at 12$ on Ebay, so the cost advantage is minimal by using a single Atmega328, because additional hardware is needed.
It's easy to upload the programmer firmware with the Arduino IDE, that is freely available for any common OS (MacOS, Linux, Windows).
The Arduino Nano I used for my prototype is not soldered on the PCB. It's mounted on a IC socket (formerly a 40 pin 600mil socket, cut down to 30 pins), so it can be removed and used for other purposes. Reinstalling the firmware for the programmer is done in a minute, so this solution is more flexible.

I think I will finish this first prototype within the next days. For today I'll take the chance to celebrate the first warm and sunny Sunday this year with a little barbecue

P.S. I'll attach the last version of the serial protocol that includes the improvements from scotws.

_________________
How should I know what I think, until I hear what I've said.

Watching this with interest!
Cheers
Ed