On Tue, Jan 21, 2014 at 7:36 PM, Mark J. Blair <nf6x at nf6x.net> wrote: In general, split baud rates were to allow higher transmit speeds from what a CPU could handle in the way of receive speeds, often because of interrupt handler latency. It was semi-common in machines in the 1970s that had to support multiple serial-attached peripherals, like time-sharing systems with many simultaneous user terminals. If, for example, you had a Unibus RSTS box with a fistful of users, it wasn't unusual to see transmit clocks set to 9600 but receive clocks set to 300 or 1200 (since most people can read faster than they can write). A TU58 hung off of that same system might need to be set to 9600/300 or whatever worked to prevent overrun. What targets do you plan to support? If it's meant to work with every DEC machine that ever saw a TU58 back in its day, you might have to set the TX/RX speed low together to keep the TU58 from overflowing the CPU's SLU receive buffer, slowing down reads in favor of all writes being successful. If you mean to use it with hardware than routinely handled 9600bps or faster in both directions, then it's not likely to be as important. -ethan