The software for the programmer is in two parts, the “firmware” that runs on the ATMEGA8, and a program intended to run on a Linux machine which sends a file to the ATMEGA8 which it then writes onto the EEPROM.

Both bits of software are available on my github account.  This is not the nicest code I’ve written, but it does the job.  There are almost certainly buffer overflows….

The baudrate between the PC and the ATMEGA8 is fixed at 9600.  I played with higher rates, but did not have much success, probably because of inaccuracies in the built in RC oscilator.  9600 is fine for the size of files I will writing to the EEPROM anyway.

Programmer Firmware

The command set the ATMEGA8 software understands was designed both for the task of programming the EEPROM and general debugging.  All commands are in lowercase, and the first argument to the command is usually some kind of count value.  If the count value is missing, it will default to 1.  All commands emit “Done” on success, or some kind of error message on error.

• echo N –  Enable (or disable) local echo based on N. Useful for interacting with the programmer via a TTY terminal program.
• debug N – Enable (or disable) debug mode, based on N being 0 or 1.
• reset – Pulse the counter reset line, and clear the counter (address bus) back to zero.
• clock N – “Manually” pulse the counter clock line N times to advance the address by N.
• getcount – Prints the current value of the counter. This value is updated by the reset and clock actions, as it cannot be directly read by the ATMEGA8.
• dumphex N – Prints N bytes from the EEPROM in hex. The output is fairly basic, but serviceable.  Note that the left hand field is the count of bytes read in the current read operation, not a mempry address.
• dumptext N – Like the above, but print only printable ASCII values and translate CR and LF for the terminal.
• dumpraw N – Raw output of N bytes. No translation and every byte is output.
• writemembytes N M – Writes the byte M (in decimal, hex, or any format strtol() understands), N times. Used for testing.
• upblock N M – Writes N “pages”.  M sets weather to use page write mode. See below
• testwrites N M – Writes N “pages”. M sets wether to use page write mode. Here the data is preset instead of coming from the serial port.
• writedelay N – Changes the write delay, in milliseconds. Defaults to 10, which is valid for the 28C256.

Page mode needs some explanation.

The 28C256 needs 10ms for each write operation.  This would render write mode stupidly slow but for the ability to write a 64byte “page” in a single write step.  This is implemented in the EEPROM programmer code by the uplock command.  It will read 64bytes from the serial port and then write out a page containing that data.  With page writes, my EEPROM programmer software can write the EEPROM at near to the maximum speed of 10ms per 64byte page.  Note that page writes need to start at a 64byte boundary.

Although the circuit includes an IO pin for the /CE (Chip Enable) line, the programmer code simply puts this line low for the duration it is running.  This is because there is only one EEPROM to program.  The /WE (Write Enable) and /OE (Output Enable) lines are manipulated in the read and write operations roughly in line with what the datasheet for the 28C256 suggests.

Uploader

The “upload” program is a simple end-user EEPROM writer for pretty much any version of Linux.  It accepts a single argument, the file to write to the EEPROM.  It assumes the ATMEGA8 is attached to a USB TTY port (/dev/ttyUSB0), and will first write the file using the “upblock” command, and then verify the file was written correctly by reading it back again with the “readraw” command.  You should probably ensure the ATMEGA8 has been reset before running “upload”.

Note that my particular 28C256 appears to have some “bad addresses”.  In page write mode, writes would consistently fail at the same address, but only in page write mode.  The upload.c code contains some special code to flip certain write locations back to non page mode to work around these bad areas in my EEPROMs.

Improvements

• It would be nice if upload could be used to dump out the contents of the EEPROM
• All buffer overflows should be eliminated
• The command set should be better documented
• The code (both programs) need more comments

Next Steps

I’m currently waiting for my good friend Richard Gellman
to layout my EEPROM programmer circuit for me so I can make it up on a
PCB. That will then freeup the breadboard for my 6809 efforts.

Until then, I have a lot of reading on 6809 assembly, planning what my 6809 computer will do, and so on….