[Simh] PDP-8 KL8E XON/XOFF

[Johnny Billquist]

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
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>

-- 
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