fwiw I've had success with the minimalist two-diode type circuit that you linked to. The only difference being that I used the TX pin of the 'sniffer' device as a handy source of -12V to use through a 47K pull-down to make sure the sniffer's own RX didn't float when neither of the snooped-upon devices was transmitting.
Unless you're driving tens of feet of wire, or are running at faster rates like 115.2kbps, the diode & resistor thing shouldn't affect the circuit too much.
If you really want to buffer the signals to TTL and back, there are of course the MAX chips, and even simple old line-driver/line-receiver type chips like the 1488 quad driver and 1489 quad receiver that would do the job.
I don't know how stuck you are on the 16F877A, but that's a poor choice for something like this. Think of the 16 series as being only for special situations, like high volume where a little lower price matters, extra low power, or small physical size. You have none of these issues, and the 16F877A is a old general purpose part anyway.
I would use something like a 18F4580, which has a CAN transceiver built in. Your application is just crying out for CAN. It is a differential bus, so has good noise immunity. Your distances can easily be handled even at the maximum rate of 1 Mbit/s. RS-485 as others have mentioned is differential too, but it stops at the electrical spec. You have to design your own protocol on top of that, considering collisions, retries, arbitration, bit errors, etc. This is of course doable, but there are a lot more little gotchas that aren't probably apparent to you at first glance. There are a lot ways to get this wrong, and most people do, at least the first time.
With CAN, all that is defined in the standard and implemented in the hardware. You send a message, and it just shows up at the other nodes. Multiple nodes trying to transmit at the same time is handled automatically. there is a defined arbitration scheme that the hardware CAN peripherals implement, with automatic retry until the message gets thru. Each message also contains a 16 bit CRC, which is again generated and checked in the hardware.
It will take a little effort to learn CAN and the CAN peripheral, but this will be less than doing your own protocol on RS-485, at least if you do it right. Besides, CAN is a good thing to learn whereas RS-485 is a legacy from a bygone era.
If you can't use a PIC with CAN built in (although there are some with the same footprint as the archaic 16F877A), you can use the external CAN chip that talks to the PIC over SPI. Our free PIC Development Tools release at http://www.embedinc.com/pic/dload.htm includes source code both for driving the external CAN chip and the internal CAN peripheral of a 18F4580.
You will need something that allows the PC to communicate with the CAN bus, but such things are available off the shelf. We have our own USB to CAN adapter which hasn't made it to a product yet, but I'd be willing to publish the design and the source code for it. If I remember right, National Instruments is one of the companies that makes off the shelf CAN adapters for a PC.
Best Answer
The "FTDI friend" is the wrong tool for the job. What you want is a cheaper, off the shelf USB to RS232 converter from a generic computer or office supply store.
As Gustavo points out, the signaling voltage of the FTDI friend is incorrect - about 3.3v unipolar instead of the higher, bipolar RS232 levels used by just about anything of recent vintage that has a 9-pin serial cable.
However, that's not the only issue. The "sense" of the logic is also customarily inverted between logic level and RS232-level serial signaling. So even if there were not a potential damage issue due to the voltage incompatibility, the upside-down data would not be interpretable by a typical receiver.
It might at first seem ironic that a USB-serial chip packed with a a converter to RS232 levels and a 9-pin connector is cheaper than a module with just a chip and the signals broken out at logic level to wires, but not really, when you consider the size of the market for the two products.