The EEPROM programmer is finished!  I soldered up the PCB, and after fixing a couple of issues it checks out.  My programmer has some very bright LEDs, and to show them off I’ve added a new “debugdelay” option to set how fast the programming should happen.  In the process I’ve removed the old “debug” option because the 8KByte flash in the ATMEGA8 is now full.  It wasn’t really that useful once the code was shown to be working anyway.

Top of the programmer PCB:

Bottom of the programmer PCB:

As you can see a couple of small modifications were needed:

• The 3.5mm jack socket was too far from the edge of the PCB, such that the plug was blocked by the edge.  Cured by hacking out a notch in the board.
• The EEPROM socket had no power pins connected.  This was cured by the addition of some unsightly jump wires. 

Luckily I noticed the missing power connections to the EEPROM before I soldered the decoupling caps.  This meant I could use the holes meant for the capacitors for the jump leads.  The caps are just a “nice to have” really, hopefully.

Anyway, the programmer is done and works just lovely!

I’m now knee deep in learning 6809 assembly.  From a modern perspective, it’s an extremely labour intensive way to write code, but it’s fun.  In comparison to other 8bit MPUs the 6809 was clearly quite a way ahead, with its addressing modes and “massive” selection of registers (9, including 2 general purpose 8bit accumulators).  But it remains far behind it’s 16bit big brothers, such as the 68000, in terms of ease at which it can be programmed in assembly.

Whilst there’s a fair amount of info on this processor online, there’s no substitute for a contemporary book on the subject.  So I bought one: Programming the 6809, by Rodnay Zaks and William Labiak, published in 1982.  As well as a useful technical resource, it’s also got some fascinating insights into programming computers in the early 80s.  Some interesting quotes:

Programming also requires a strict documentation discipline. Well documented programs are understandable to others, as well as to the author.  Documentation must be both internal and external to the program.  Internal program documentation refers to the comments used in the body of a program to explain it’s operation. External documentation refers to the design documents that are separate from the program including, written explanations, manuals, and flowcharts.

 This is as true today as it was in 1982, the fixaction on flowcharts perhaps notwithstanding.

Another gem, illustating the simpler times:

The representation of alphanumeric data, i.e. characters, is completely straightforward: all characters are encoded in an eight-bit code.

 If only that was still true!