I should add, by the way, that I use AVRdude (the free command line AVR tool) in WindowsXP to put  bootloaderd on my Atmega chips, not Arduino.  But once I'm done loading the bootloaders, I flip my 6PDT switch and use the Arduino IDE with my Olimex board.  To make it usable in the world of Arduino, all I had to do was replace the 8MHz crystal with a 16MHz one and hook up two wires to the serial chip.

When programming with AVRdude, these are the three command lines I use:

avrdude -patmega168 -cponyser -Pcom1 -b56000 -u -v  -Uhfuse:w:0xdf:m -Ulfuse:w:0xc7:m -Uefuse:w:0x08:m
(to set the fuses for the world of Arduino)
avrdude -patmega168 -cponyser -Pcom1 -b56000 -u -v  -Uflash:w:a.hex
(a.hex being a copy of the Atmega168 bootloader)
avrdude -patmega168  -b56000 -Pcom1  -cponyser  -V -U lock:w:0xCF:m
(to lock the bootloader part of the Atmega's flash memory)

If you want to build a serial-capable ICSP burner for the Arduino, this is the circuit diagram:
http://www.olimex.com/dev/pdf/avr-pg1b.pdf
I actually bought the programmer from Olimex and it works great
 but I later needed to build a second one myself on this Olimex breadboard:
http://www.olimex.com/dev/avr-p28.html
 so I could flip a 6PDT switch to switch a single serial cable from "standard Arduino serial" to "ICSP burning" and back again.
(In the version of the circuit I built, I replaced whatever NPN transistors Olimex uses with standard 2N2222s and they worked fine.)

Here are some pics of my Olimex Arduino programmer, front and back, afterwards and before:

If you look at the Arduino schematic:
http://www.potemkin.org/uploads/Pid/arduino_usb.jpg
you see that the ICSP port is just a reuse of normal digital lines.  I don't know the choreography that happens on this port when reprogramming with the ICSP, but it seems possible that, if you were really unlucky in a noisy relay/motor-filled environment, one that allowed noise to enter the Atmega8's Reset line, it would be possible to reflash the Atmega8 without intending to, thus damaging the bootloader or any programs loaded onto it. I've had this happen myself - I didn't actually know what had happened until I tried reloading the bootloader onto Atmega8s that I thought were dead - reviving them completely.

Wow, you totally called it!  Sure enough, the Olimex had an 8MHz crystal.  Just to keep things easier when dealing with real Arduino boards, I decided to fix the problem by replacing the 8MHz crystal with a 16 MHz one.  I looked around my cluttered laboratory and found a four pin 16 MHz module (from an old experimental NCUBE multiprocessor ISA board).   (For the record, those modules have osc_out at pin 3, ground at pin 2, and VCC at pin 4.) I desoldered the old 8MHz crystal out of the Olimex and connected the osc_out pin from the module to pin 9 of the Atmega8.  Right away, I noted it booted up in half the time!  And then I could reprogram it over a serial line using the usual Arduino IDE.  This setup makes it possible to develop stand-alone Arduino gear for just the price of the Atmega and the Olimex board, and you get lots of board real estate as a bonus!

I have an Olimex AVR-P28 board ($14 from Sparkfun.com) into which I inserted a spare Atmega8 that I programmed using the parallel port programmer.  Getting this to speak through the Olimex board's Max232 serial chip wasn't easy, since its pins are not connected to the Atmega at all - you have to do that yourself and the labels on the board appear to be reversed (or perhaps we're in weird Null-modem land).  I had to look up the Max232 schematic for guidance.  Pin 3 of the Atmega8 goes to pin 10 of the Max232 and (I think) pin 2 of the Atmega8 goes to pin 12 of the Max232.

With this setup, it is possible to read the serial output of a Atmega8 running a known program that outputs to the serial port.  What is strange, though, is that I have to set my terminal program to half the baud rate of the serial setting in the Arduino program (in other words, a Serial.begin(2400) results in 1200 baud communications).

I have not been able to upload a new program to the Atmega while it's on the Olimex board.  Perhaps the RX wire is going to the wrong pin of the Max232 or the baud-halving issue is throwing a monkey wrench into the process.  Does anyone have any ideas?  I like the Olimex board because of all the board real estate, which is good for a project that has already been completely debugged.

Actually, scratch that about the ferrite toroid.  Something I wasn't paying attention to had fixed that problem and I unscientifically attributed it to the toroid (which I'm keeping just as a good luck charm).  What really fixed my problem was spiffed's idea of soldering pin 5 of the DB-9 connector to its mounting lug.  Now my MaxSerial Freeduino is rock solid across its 100 foot RS-232 connection, performing as reliably as a toaster.  I can even unplug the serial port and plug it back in again without triggering a reset.

My MaxSerial Diecimila has been working nicely now for some weeks, although it occasionally resets spontaneously because of noise coming down that very very long 100 foot RS-232 cable (which is now shielded, by the way).  

I noticed that lots of spontaneous resets seemed to happen under certain conditions the moment I turned on the light in the boiler room (it's a 23 watt compact fluorescent - 100 watt incandescent equivalent). Those who have been following this thread might find my solution to this problem helpful.  I wrapped the 12 volt DC power line (containing a +12volt and Ground pair) around a donut-shaped ferrite toroid approximately seven times. This was totally a cargo-cult science experiment, because electro magnetic inductance is still basically magic to me.  But the spontaneous resets, which had been so common before, are now completely gone.

Good advice on the caps. I still don't know enough about the Diecimila reset protocol to know what combination of levels on the serial cable would result in a reset on the Freeduino end.  Might it be the sort of thing that would crop up frequently in noise?  My question, I guess, boils down to this: does anyone know what exactly causes the RS1 pin (pin 12) to change state on the Max232 chip?

Remember. the problem isn't reliability of communication with this 150 foot RS-232 setup (it uses unshielded CAT3 cable), it's the propensity to randomly trigger the Diecimila autoreboot-before-software-upload routine.  I'm using a Freeduino/MaxSerial, so an actual Arduino might not have this problem.  Then again, an actual Arduino can't communicate this far, because USB over these distances is a mess (believe me, I've been there, tried lots of niche products).  I do see that the MaxSerial reset only looks at the RS1 pin (pin 12 of the Max232) whereas the actual Diecimila's reset looks at two pins on its USB chip (DTR -pin 2, and RTS - pin 3).  And, at least with my particular MaxSerial Freeduino, the propensity to reboot spontaneously exists in either of two situations, only one of which involves long cable:  when there is a long RS-232 cable attached via a USB-to-Serial adapter to a distant computer, or when the there is no cable attached at all. It seems to be reliable when using a short RS-232 cable or when a long RS-232 cable connects directly to a distant computer's RS-232 port.  

Official Arduino Diecimila schematic:
http://www.arduino.cc/en/uploads/Main/Arduino-Diecimila-schematic.pdf

MaxSerial Freeduino schematic:
http://www.freeduino.org/files/duino232/Duino232-2.png

actually the 150 feet of rs-232 was working great until the usb-to-serial adapter blew (lightning??).  still, i'm guessing i should terminate it and perhaps take surge-arresting measures to keep such adapter blowouts to a minimum. also, i'd like to make it so the maxserial doesn't spontaneously reboot when there is no serial cable plugged into it at all. perhaps there's a defect in the way i made that particular board (which i did from a kit), but it seems to require a serial connection to a computer or else it reboots spontaneously every seven or eight seconds.

I've confirmed that the source of my problems is pin 12 on the Max232 chip. With it kept out of the socket, all was well.  
...
Actually, the problem seems to be coming from a USB-to-serial adapter i'm using 150 feet away on the computer end of the serial cable.  Plugged directly into the computer's god-given rs-232 ports, it works fine, but with the serial cable either plugged into the USB-to-serial adapter or removed from the Arduino (technically it's a Freeduino) it spontaneously resets.  perhaps i need to try some sort of termination of the cable on one end or the other.  i've been doing this stuff for 25 years but i've never really understood termination. perhaps someone could break it down for me.

This leads into a question that I have about the Diecimila generally.  Could someone give a concise description of what the Arduino IDE does that causes the USB chip on the Arduino to reset?  Understanding this mechanism a little better would be helpful in fixing problems of this sort.  I know I'm using a slightly off-brand Arduino in this case, though I'm sure the knowledge I seek would be helpful to everyone.

A little background:  When the distance from computer to Arduino reached 150 feet, I had to switch from a USB-based Arduino to a MaxSerial (which uses a Max232 chip to communicate using standard old-skool RS-232 serial).  

Everything worked great for a week or two, but then the board started resetting itself sponatenously after only a few seconds of uptime.  I isolated the problem to the Max232 chip - with it removed from the socket, the Arduino worked perfectly, though (obviously) with no serial communication. With the Max232 back in place, it resumed its spontaneous resetting. I tried different Max232 chips and they all have this problem, so I suspect it is related to noise in the long serial line.  I looked at how the Max232 connects to the Arduino's reset pin (necessary so that the IDE can tell the Arduino to reset prior to uploading new software, the great new Diecimila feature), and I see it goes to pin 12 (RS1) through a 0.1microfarad capacitor and that the reset line is held to 5volts through a 10k resistor. are there any modifications i should attempt to keep spontaneous resets to a minimum?

That's useful information I hadn't seen anywhere else.  I had no idea the Atmega168 had I2C support built in (of course, I never noticed I2C until it was a feature I needed) - I assumed the Wire library was an all-software implementation.  Ok, so I have to use the analog pins.  As you probably have guessed, I'm using those analog pins.  I guess I could replace those pins with an I2C analog-to-digital converter once I got I2C working. The problem with analog pins is you can't exactly multiplex them unless you use a bidirectional switch (which, of course, imposes its only analog effects which would have to be programmatically accounted for).

I have a question for those who know about such things:  is there any particular reason for the Wire (I2C) library to communicate on Analog pins 4 and 5?  The signals in the protocol are all standard TTL-style digital signals, so why can't the library be modified to use some combination of the Arduino's digital pins?  And if this was done, where in the library would it be done?  I looked at Wire.cpp and my eyes began to fog over.  I did a search for "4" and "5" (as well as their binary equivalents) and they didn't come up anywhere.