21 Jan
2014
21 Jan
'14
6:53 p.m.
On Tue, Jan 21, 2014 at 7:36 PM, Mark J. Blair <nf6x at nf6x.net> wrote:
The manuals for the TU58 DECtape II tape drive
controller indicate that
the transmit and receive baud rates can be set independently. Have any
of y'all ever heard of an application that uses different transmit vs.
receive baud rates with a TU58 drive, or is this independent baud rate
capability just a coincidental feature that arose from the way the
controller's UART was implemented?
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.
I'm thinking about a little embedded TU58 emulator
project, and I'm
wondering how important it is to support the independent baud rate feature.
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