14 May
2009
14 May
'09
11:10 a.m.
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.
Chris
On Thursday (05/14/2009 at 03:04AM +0200), Philipp Hachtmann wrote:
Hi,
--
Chris Elmquist
I completely mis-understood the source of your
troubles.
Oh.
The VT05 terminal operates at speeds from 110 baud to 2400 baud,
selectable with a rotary switch in the back (my unit is currently missing
a counter ic to generate 110baud, but...).
So far so good. The problem is, that when you want to operate the VT05 at
speeds higher than 300 baud, you have to wait a certain amount of time
after a line feed character or cursor positioning command. This is
usually done by inserting zero fill characters (4 at 2400 baud) after the
critical commands. If you don't obey this rule, the VT05 has not
completed changing the line when you send the next character. This is a
bit like a too slow cr on a teletype - funny but true.
So my wish was to modify OS/8 so far that it generates those fill characters.
The TTY: handler is also capable of correctly doing this for me. But many
other programs - as the OS/8 keyboard monitor itself - use direct IO
commands to read from and write to the terminal.
So one would have to patch many programs. In case of the keyboard
monitor, I don't know if there is any room left to put such a code in.
And I don't know how to reassemble and correctly install a new keyboard
monitor from scratch.
So all I can do is to run the VT05 at 300 baud. Or get the advances
serial interface (see other posting).
Did this illustrate the problem?
Best wishes,
Philipp :-)
--
http://www.hachti.de