[Simh] PDP-8 KL8E XON/XOFF

[Clem Cole]

On Mon, Jun 6, 2016 at 12:13 PM, Mark Pizzolato <Mark at infocomm.com> wrote:

> The fundamental issue Bill is seeing is a problem in the simh code and not
> the hardware or the host OS.  There may be a hardware issue, but I doubt it
> and if there is, the simh issue will have to be addressed first.


​Agreed the problem is in simh, although Johnny's right about the
trigger/causing being the buffering on the host OS.

Let's explore what is happening.    Terminal canonicalization is an OS
operation.   Flow control on the other hand is something you >>would<< like
to have as close to the HW as possible.  We have a real TTY here, but
because of the emulation, we have a role reversal in that by the time the
Flow control logic in the simulated host kicks in, it too late.

Simply put..   OS/8's terminal handler is doing the flow control.    On the
original HW, there is an Full/Empty bit in the UART that signals its ok for
the OS (OS/8 here) the put the next character in the output buffer.    On
real HW, "emptying" the transmit buffer in the UART takes the X bits times
at the appropriate baud rate - where X is determined by the 1 START bit +
SIZE of CHAR + [optional PARITY] + 1 STOP BIT [optional second STOP bit].
In this case, its 11 bits at 110 baud or 10 chars per second.

We get "bad behavior" because OS/8 thinks the char has already been printed
because on  >>real<< HW the fastest OS/8 can ever see the Full/Empty bit is
10 cps.    But in the emulated world, the read of the transmit buffer
occurs and start stop etc are removed and the data passed on to the host as
a char with a write system call by simh and then "output" via the real host
serial code.   As Johnny points out, this is going into the UNIX terminal
output queue (and normally UNIX would be doing is on canonicalization plus
any flow control).

So the flow control logic that OS/8 is doing is too late (the chars have
already been written as far as OS/8 is concerned - they already saw
Full/Empty signal it was ok to send).

The trick is some how the emulated Full/Empty state in the simulated HW
(e.g the PDP/8), needs to follow the time that the host actually wrote of
the character (i.e. the UNIX tty driver actually posted the char in this
case) so the simulate OS (OS/8) actually behaves as expected.   That is to
say, their needs to be a way for the simulator to delay setting the
emulated Full/Empty bit until the character really is on its way to the
real UART connected to the real UNIX hosts talking to a real ASR33.

As I see it, there are two possible ways for simh to fix the problem so the
simulated OS's canonicalization and flow logic actually work as designed
for the real HW:

   1. have simh keep reasonably precise time in the emulated HW and not
   post Full/Empty in the emulated UART any faster than the X cps defined by
   the original HW.
   2. If simh can set the output buffering to very few say 1 maybe 2 chars,
   before actually writes another character to UNIX (and this not post
   Full/Empty) as sooner than the physical HW can output it.

If you can pull it off, I think the later actually will work better,
because you are letting the local HW help you and not putting artificial
timing into things any more than needed but it might be hard.   Sadly, when
we designed the POSIX terminal interface (and yes you can blame me, I'm one
1/2 of the original author of that chapter), we took the inverse problem
into account with the MIN/TIM values for reading characters coming into the
tty handler.   We did worried about the output issue, as UNIX will control
the buffering.   I need to think about a portable way in the application
code to make that work right.

That said, I think Mark's right - we need control the timing better in
the simulator.   If we can do that better in the simulator in a host
OS independent way, the problem should be fixed.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160606/7d2ddee8/attachment.html>