The KL8E driver works just fine. If you are having some problem, it is
not in the PDP-8 code.
I would suspect your raspberry pi hardware serial port is detecting and
handling XON/XOFF itself, causing your problems.
Johnny
On 2016-06-06 02:54, William Wuttke wrote:
_Problem:_
_
_
When using a teletype on a serial port, XOFF will stop a directory
listing (and others), but once that happens, the PDP-8/simh will no
longer respond to keyboard input. I’m using a Model 33 ASR on a PiDP-8
(raspberry pi) hardware serial port.
_Investigation:_
_
_
All documentation says XON and XOFF should work from the console. Well,
it does and it doesn't.
If using "screen", it works, but apparently the XON/XOFF functionality
lies somewhere other than in the KL8E handler. The typing stops when
XOFF is sent. Then when XON is sent, you can see some buffered text
appear on the screen fast, then the typing slows down to normal speed.
(I set the tto unit wait value to 20000 to closely approximate real 110
baud serial output. Otherwise, a directory listing gets buffered up an
about 3 seconds, but takes 2-3 minutes or longer to print out on the
teletype. This also allows me to Control-C to quit the listing.) It
looks like "screen" is buffering the text.
If using the teletype, XOFF stops the typing, but XON does nothing - the
machine is locked up in a loop at this point with 7623 in the
accumulator (it works as coded). Looking at the KL8E handler, the tty
check routine uses KRS to read a character, never resetting the keyboard
flag. Apparently, since the KL8E had no buffering, if an incoming
character is not read, it would be overwritten by the next incoming
character, clearing the keyboard flag during the time that the character
was not valid, then setting it after the character was assembled into
the keyboard buffer. It looks like the KL8E handler was written
depending on this behavior. However, it looks like the simh tti is
acting like a modern UART, buffering up the input, and moving through
the buffer as characters are read. The KRS instruction is for all
purposes a "peek" at the next character in the buffer, which is exactly
what the tti is doing. It keeps "peeking" at XOFF (7623 - 7600), which
never really gets removed from the buffer. However, it really needs a
"read", to advance to the next character. At least, that is what it
looks like.
_Fixes?_
I'm going to attempt to mod the KL8E handler to fix this, but might not
have much luck since it already pretty much fills up its allotted two
pages. It is filled with all sorts of assembly language trickery to fit
into two pages. In my way of thinking, the simh KL8E is really
“modified” hardware, and OS/8 can be easily adapted to new hardware. I
think I have a fix, using KRB instead of KRS - I don’t think that using
KRS was a good idea anyway, but on a real PDP-8 it would catch the XON
as soon as it happened.
Or, could a mod to simh do the trick? Could the KRS be modified to act
like a KRB, but just OR’ing the keyboard buffer with the accumulator
instead of clearing the accumulator it first? How would this affect
other PDP-8 software that relies on KRS without subsequently clearing
the keyboard flag? How common is the use of KRS in this way? I guess in
this day and age, trying to eliminate all the buffering going on would
probably be a real pain. And, the buffering on the input actually
eliminates the need use the teletype Reader Control with simh.
Does anyone have any ideas?
Regards,
Bill Wuttke
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
