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
