Clearly this was not his problem, but you still don't get it. I'm going to try to explain this once again, hope that it makes more sense to you this time, and drop it.

When you have a serial connection, a normal one without a null-modem connection, there is a signal called CTS, or Clear To Send. When this pin is high, it means that the device is ready to receive data. If hardware handshaking is turned on on the terminal, it will wait until CTS is high before it sends data.

When you have two terminals connected together via null-modem cable, things in regards to CTS go haywire. Since the RS232 protocol was written such that the terminal and the device have different functions, you can't just swap CTS with RTS (Ready To Send) and have everything work correctly. In order to get around this problem, null-modem connectors are designed so that CTS is looped back to RTS and is crossed with (I believe) remote DCD (D? Carrier Detect) the notion being that DCD should always be high and will pull up both CTS and RTS, jury rigging the hardware handshake. Similar games are played with DSR and DTR (Data Set/Terminal Ready).

If the empeg's serial port is wired incorrectly, The loopback and short might fail to pull CTS high on the empeg, regardless of what was on the opposite end, thus preventing the hardware handshake from being fooled. This is avoidable if you open the port without hardware handshake on, but it could conceivably cause other problems, depending on a variety of variables.

Again, this obviously wasn't the problem here, but it easily could have been. I'd still like some corroboration as to how the sled's serial port is wired wrong.