At 05:17 AM 5/17/2009, Johnny Billquist wrote:
Chris Elmquist <chrise at pobox.com>
wrote:
I may have missed some facts earlier in this
thread-- but does the
system
obey hardware flow control such as CTS? ie, if CTS is low, will it be
blocked from transmitting? If that is obeyed by all of your OS and
software, then it is not hard to build a microcontroller that would sit
between the system and the terminal, adding the delays you need on <cr>
while buffering for and hardware flow controlling back toward the PDP-8.
In
general, when talking about DEC equipment, the answer to that
question is *always* no, for the simple fact that DEC didn't do
hardware flow control. Hardware flow control is actually against the
RS-232 spec, and DEC didn't abuse standards (unlike most other companies).
And, of course, there's a pretty good chance that this VT05 is
connected via 20ma, not RS232.
(Assumption based on the fact that there's an easy fix in the KL8-JA;
given that this hasn't been used to fix the problem, it's probably not
an omnibus computer. Pre-8/E serial devices were often current loop.)
Assumption wrong. :-)
The original posted have a KL8-E, which is software compatible with the
KL8-JA, but don't have the filler fix that the KL8-JA have.
They are both omnibus devices.
The KL8-E is actually kindof cool, since it implements a UART in
discrete logic. One side effect of that implementation is that you can
send a break character, since the transmit shift register is always
loaded immideately, even is a character is currently being transmitted,
and the stop bit is also shifted through the register, thus you can
"overwrite" the stop bit with additional data.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol