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
Perhaps the conceptually simplest approach to disconnect the TX line from the modem is with a phototransistor optoisolator:
There's a huge number of such devices available that would be more than adequate. A brief inspection of the selection charts at my favorite suppliers seems to indicate that the Isocom H11AA4X, Isocom TLP521-4, Avago 4N35-000E, Lite-On LTV-816, etc. all seem adequate.
There are many devices that may sound like what you want, but they won't work for your application: