AVR Flash Microcontrollers
The best thing since sliced bread.
You can find out all about them from Atmel's website where you can also obtain, for free, an assembler, simulator, the device programmer software, and plenty of library and example code.
You might find this site useful, http://www.dontronics.com/, no endorsement is implied.
Here's my gift to the AVR community:
The DCK AVR pseudo-parallel programmer
David C Keenan, 2-Dec-1998
Matrix board layout
For a while Atmel sold a very inexpensive AVR programmer that connected to a PC serial port on one side and used the in-system serial programming interface (ISP) of the AVR devices on the other. It had 6 wires to the target device and took its power from the target system. It was itself based on an AVR device, the baby of the family, the AT90S1200. Atmel even have the schematic and code for it on their website.
Programming devices serially is slower than parallel, but you can do it in-system, and programmers that only do serial are cheaper. There are two drawbacks of serial programmers that my programmer was designed to solve. (a) Atmel no longer sell these serial programmers and (b) you can't toggle the "fuse" bits by serial programming. The fuse bits include the bit that, in the AT90S1200, lets you enable the internal RC oscillator for a minimum components design.
I have designed and programmed an alternative pseudo-parallel programmer which you can build yourself on matrix board. It has a piggy-back socket on its master AT90S1200, and those capabilities of parallel programmers which serial programmers cannot have. Namely setting the fuse bits and reading both the fuse and lock bits.
It tells the driving software (AvrProg.exe from Atmel) that it is a parallel programmer in order to enable those parts of the user interface relating to fuse and lock bits, but it does everything else serially. Apart from the fuse and lock bits stuff, you can choose whether to program a device in the piggy-back socket (provided it is a 20 pin DIL device with its RC oscillator enabled) or using the ISP interface.
It still only uses a single AT90S1200. There's some pretty sneaky multiple use of pins (described in comments in the source code), and I've used the RC oscillator where Atmel used a crystal. It needs a reasonably accurate 5 volt supply so the serial data rate to the PC doesn't drift too far. 4.95 to 5.05 V should be fine. This can come from the target system when ISPing. It generates its own 12 V parallel programming supply on-board with a bunch of diodes and capacitors.
I'm too lazy to describe how much of it works, but see the schematic, matrix layout and source code above. You may need to consult the schematic to disambiguate some of the matrix layout. I fully acknowledge my debt to Atmel for their source code that I modified.
The discrete P and N-channel MOSFETs could be replaced with PNP and NPN bipolar transistors provided you add a 4k7 resistor in series with the base of the NPN.
If you already have a perfectly good serial AVR programmer, you might just want to build mine as a standalone RC-enable fuse bit toggler. You can make it so that no connection to a PC is required. Just plug in the target chip (slave) and power up the master to toggle the bit. That's how this project started (before I learnt that Atmel were discontinuing their serial programmer). I'll leave it to you to figure out how to modify the code for this purpose and what parts you can leave off the circuit.
Now your only problem is how to program the programmer! I guess you just have to get access to an existing AVR programmer. You need to program the RC-enable bit too or buy an AT90S1200A ("A" suffix has RC enabled). Of course you could add a crystal or ceramic resonator and change the equates for R and N in the source code to maintain the correct data rate (19200 b/s).
If you are programming the master chip in the DCK programmer after you've built it, you need to remember to switch the reset line from the slave to the master (and back when you're finished). Note that the DCK programmer may not be able to program a device in-system if the target device has a low value external pullup on its reset input. Note that this applies to programming one DCK programmer from another. Just leave off the external pullup, it's only for paranoids anyway. There's a perfectly good internal pullup. That way you can reset the system with a damp finger, correctly applied. :-)