At 08:54 PM 6/5/2016, 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.
Any documentation that says that about OS/8 is inaccurate.
Many programs simply push character output as
fast as the native baud rate and never checks for
any keyboard input (other than perhaps for control-c.)
If using "screen", it works, but apparently the
XON/XOFF functionality lies somewhere other than in the KL8E handler.
That's probably happening within screen, where
OS/8 never sees the input, with buffering being handled by the native OS.
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.
Assuming you're using something like "TYPE
FILE.TX", which CCL converts to PIP TTY:<FILE.TX.
So, the KL8E handler gets used here.
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.
This sounds like a SIMH defect. KRS should read
the last input character, as there's no buffering on the real hardware.
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?
If the SIMH KRS doesn't read the last input
character, it needs fixing. Changes to the KL8E
handler will only fix TYPE and DIR, and leave
lots of other problems. Seems like a simple SIMH
fix to drain the input buffer every time KRS is executed will fix this.
-Rick
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
