This Easter weekend I’ve been working on the EEPROM programmer again.

The programmer PCB has been “in production” now for about a week, with a few weeks left.  In the meantime I thought I would brush up on my soldering “skills” and make the circuit up on stripboard.  This turned out to be a slightly crazy thing to do; stripboard does not lend itself to circuits with busses.  There are far too many wire connects.  The result is good though; I now have a nice working EEPROM programmer in a much smaller space then the masses of breadboard.

My extremely dodgy soldering:

I was so used to breaking tracks that a couple of times I broke a track between two components which I could have used.  One day I will try my hand at non tracked protoboard.

Every IC is socketed.  I even socketed the ZIF slot!  I didn’t have a narrow 28pin DIP socket for the ATMega8, so I made one out of two 14 pin sockets.  The 10pin IDC programmer header (top right on the underside picture) involved some awkward track cuts.

The bodges in upload.c to disable page mode for certain locations are now not needed.  They were necessary when the circuit was on breadboard, not for bad memory locations in the EEPROM like I suspected, but for dodgy breadboard wiring.

I’ve also (code on github) improved upload.c such that it can be used for downloading the content of the EEPROM.  You can also set the serialport TTY on the commandline.  The options are:

• -s : set the TTY of the serial port (eg /dev/ttyS0). The rate is still fixed at 9600.
• -f : set the name of the file to upload.
• -r : set the number of bytes to read from (file download mode).
• -o : offset to start reading from, when the -r option is used.

With the -r option, the ROM content will appear on stdout, so redirection is necessary to write the result to a file.

While working on the stripboard version of the circuit I found it useful to quickly write test data into the EEPROM, and then read it back, checking that this was what was written.

To do this automatically, the “testwrites” command within the programmer firmware can now write variable data, by writing the test pattern (which is just the number of bytes into the current page) XOR’d with a negation pattern.  A corresponding “testreads” will read the n pages from the ROM, XORing the result with the pattern and then checking this is what it should be.  By altering the negation pattern on each test, we can ensure that the data checked was written by the previous write, and not from some historical write that happened to write the same data.

So far I’ve been using the same AT28C256 for all my EEPROM programming.  I ordered a couple more from China, but when these arrived I was unable to program them.  The data read always comes back as 0xff.  These chips are datastamped 1996 and 1997, which is much older then the 2012 stamp on the “working” ROM.  It’s possible they’ve stopped working, but then they look unused so this is unlikely.  The alternative is that they were shipped with the software lock in place.  Unlocking them could be difficult.

Now I have a working, and reliable EEPROM programmer my next task is to make the simplest possible 6809 computer, containing just the 6809, EEPROM and some LED to use for output.  I can then write a simple program to drive the LEDs…